プログラミング言語 Scala

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
The Scala Programming Language
ttp://www.scala-lang.org/

チュートリアル日本語訳
ttp://homepage.mac.com/takashi_miyamoto/scala/ScalaTutorial.pdf
どう書く?org Scala
ttp://ja.doukaku.org/lang/scala/
2デフォルトの名無しさん:2008/03/10(月) 23:06:25
不感症になったのか、こーいうのみてもなんも感じなくなってしまった
3デフォルトの名無しさん:2008/03/10(月) 23:08:04
日本語の入門書がでたら買う。
4デフォルトの名無しさん:2008/03/10(月) 23:28:11
Java のライブラリがそのまま使えるってのは
ライブラリ実装の手間を省けるいいやり方だな。
5デフォルトの名無しさん:2008/03/11(火) 11:47:44
Javaのgenericsはそのまま使えないと聞いた気が
6デフォルトの名無しさん:2008/03/11(火) 23:12:02
>>5
http://www.scala-lang.org/downloads/changes.html
Version 2.7.0-final (released on 06-Mar-2008)
# [changed] - Generic Java types are now supported by default (was -Ygenerics).
# [changed] - Target jvm-1.5 is now the default.
7デフォルトの名無しさん:2008/03/12(水) 00:19:52
>>5-6
試してみた

$ scala -version
Scala code runner version 2.7.0-final -- (c) 2002-2008 LAMP/EPFL

$ cat generics.scala
import java.util._
var list = new ArrayList[String]
list add "one"
list add "two"
list add "three"
println( list size )
println( list )

$ scala generics.scala
3
[one, two, three]
8デフォルトの名無しさん:2008/03/12(水) 00:33:29
チュートリアル日本語訳
ttp://homepage.mac.com/takashi_miyamoto/scala/ScalaTutorial.pdf

↑を読んでたんだけど「ケースクラス」っていうのがよくわかんなかった。
多態性みたいなのが簡単に記述できますよってことなのかな
よくわかんないまま読み進めてたらいきなり微分の話が出てきて頭が爆発した。
9デフォルトの名無しさん:2008/03/12(水) 01:27:25
>>8
MLとかHaskellにあるやつで、
要は強力なcase文、なはず

でもcase文だから下手に使うと拡張性を失うわけだよね
10デフォルトの名無しさん:2008/03/12(水) 08:26:14
ものすごい説明でびっくりした。「MLとかHaskellにあるやつで」までしかあってないよ!
119:2008/03/12(水) 12:24:00
>>10
む、そんなに間違ってる?

拡張性と言ったのは、既存のコードを修正せずに型を追加できるかという話で、
型の定義の追加に関してはたいていの関数型言語では構文上無理な気がするが、
Scalaはcase classを別の場所であとから追加すれば可能な気がする。

一方、パターンマッチのコードは一カ所にまとめないといけないから、
拡張しようとしたら修正が必要では?
12デフォルトの名無しさん:2008/03/12(水) 22:00:57
んー、言いたいポイントがよく理解できないんだけど、
まずmatch構文の中で特殊に使える「クラス定義」であって、case「文」じゃないでしょっていうのと、
MLやHaskellを引き合いに出して1行で説明しようとするなら「元々は代数データ型を模すためのもの」とでもいうのが適切では?と思った。

拡張性云々はOCamlのポリモーフィックヴァリアントと比較すると面白いかもしれないけど、
8に対するレスとしては飛びすぎではないかな。
139:2008/03/13(木) 00:02:03
>>12
>>8が多態性と書いていたので拡張性に関する話をふってみた。
代数データ型をといわれてもピンとこないんだが...
MLやHaskellを引き合いに出さない方がよかったか。
148:2008/03/13(木) 01:08:58
まだよくわかってないけど
「関数型言語ではよくあること」ってことね
JVMで動く言語って聞いたのでJavaの知識が役に立つかと思って触れてみたのだけど
Javaしか知らない俺には難しい

よく考えてみたら多態性は継承で実現できるのだから
ケースクラスってのは、多態性とは違う何か得体のしれない概念なのだろうなあ
pdfをもうちょっとよく読んでみるよ
15デフォルトの名無しさん:2008/03/13(木) 01:44:40
16デフォルトの名無しさん:2008/03/14(金) 01:50:55
>>14
case classもクラスの一種なので多態性を実現するのにも使える
ただ、case classで定義したクラスは
・クラス名(引数列)でインスタンスを生成できる
・パターンマッチングに使える
という特徴がある。具体例を示した方が早いと思うので示すと

abstract class Exp
case class Add(lhs :Exp, rhs :Exp) extends Exp
case class Sub(lhs :Exp, rhs :Exp) extends Exp
case class Num(value :Int) extends Exp

という定義があったとして、(5 - 3) + 1という式の構文木は次の
ように表記できる。

val exp :Exp = Add(Sub(Num(5), Num(3)), Num(1))

この式を計算する評価器はパターンマッチングを使って
次のように書くことができる(MLとかHaskell知っている人には
お馴染みだけど)。

def eval(exp :Exp) :Int = exp match {
case Add(l, r) => eval(l) + eval(r)
case Sub(l, r) => eval(l) + eval(r)
case Num(n) => n
}

ここでポイントは、インスタンスのクラスによる分岐と、インスタンスから
フィールドを取り出す操作が同時に行えていること。
17デフォルトの名無しさん:2008/03/14(金) 07:17:08
>>16
なんとなく分かってきた
昔聞いたことのあるインタープリターパターンに似てる

メンバ変数を定義して、コンストラクタで代入っていうのを書かなくても
クラス名(引数列) って書いたら引数列の部分がが勝手にメンバ変数になってくれるのか

Javaで構文木みたいなの作ろうとしたら
http://anond.hatelabo.jp/20080314064942
↑こんな感じになったよ (長い!)
18デフォルトの名無しさん:2008/03/14(金) 07:24:35
eval()を外に出すと

public int eval(Exp exp){
 if(exp instanceof Add){
  return exp.getHidari() + exp.getMigi();
 }else if(exp instanceof Sub){
  return exp.getHidari() + exp.getMigi();
 }else if(exp instanceof Num){
  return exp.getSelf();
 }
}

こんな感じにしないといけなくて
こんなif文をズラズラと書くよりだったら
それぞれのクラスの中でeval()するべきだろうって思っちゃうので
理解するのが難しかったんだ
19デフォルトの名無しさん:2008/03/14(金) 07:28:02
あ、間違えた

 public int eval(Exp exp){
  if(exp instanceof Add){
   return eval(exp.getHidari()) + eval(exp.getMigi());
  }else if(exp instanceof Sub){
   return eval(exp.getHidari()) + eval(exp.getMigi());
  }else if(exp instanceof Num){
   return exp.getSelf();
  }
 }

こうか
20デフォルトの名無しさん:2008/03/14(金) 09:46:06
>>18
>>19
ごめん。Subを計算するときにも足しちゃってた。
正しいのはこう。
def eval(exp :Exp) :Int = exp match {
case Add(l, r) => eval(l) + eval(r)
case Sub(l, r) => eval(l) - eval(r) // Subなのにミスって足してた
case Num(n) => n
}
あと、パターンマッチングは本質的にはif(a instanceof A) ... else if(a instanceof B) ...を
簡潔に書くための仕掛けでしかないけど
・フィールドからの値の取り出しを同時に行える
・パターンをネストできる(後述)
・パターンが網羅されているかを静的にチェック可能(後述)
のがポイント。パターンがネストできるというのは、例えば
exp match {
case Sub(Add(e1, e2), Add(e3, e4)) => println("(e1 + e2) - (e3 + e4)")
case _ => println("failure")
}
のようにすることで、複雑な構造に対してマッチングを行うことができること
を示している
21デフォルトの名無しさん:2008/03/14(金) 09:46:41
続き。
パターンが網羅されているかを静的にチェック可能というのは、
例えば次のようなコードを書いたときに(Numのパターンの書き忘れ)、コンパイラが
warningを出してくれることを指している。
def eval(exp :Exp) :Int = exp match {
case Add(l, r) => eval(l) + eval(r)
case Sub(l, r) => eval(l) + eval(r)
}
ただし、Scalaでこの場合にwarningを出すためには、宣言を
abstract sealed class Exp
case class Add(lhs :Exp, rhs :Exp) extends Exp
case class Sub(lhs :Exp, rhs :Exp) extends Exp
case class Num(value :Int) extends Exp
のように、抽象クラスであるExpをsealedとして宣言しておく必要がある。
22デフォルトの名無しさん:2008/03/15(土) 00:54:41
とりあえず A Scala Tutorial for Java programers を読んだのですが
次は何を読めばいいですか?
どうもプログラミング言語の学習の仕方がいまだによくわからなくて困ってます。
23デフォルトの名無しさん:2008/03/15(土) 01:34:52
>>22
とりあえず、何かネタを決めて適当なプログラムを書いてみるのが
良いと思う。Scalaやってるってことは他の言語は既に知ってるってこと
だろうから、とにかく書いて慣れるのが一番。あと、ScalaReference.pdfは
読むのにやや知識が必要だけど、Scalaにどんな機能があるのかを知るのに
有用だから、暇なときに眺めてみるのも良いかも
24デフォルトの名無しさん:2008/03/15(土) 01:46:48
日本語の入門書がまだないのはしょうがないとして。。。
洋書だったらなんかある?
25デフォルトの名無しさん:2008/03/15(土) 01:53:40
>>20-21
丁寧にありがとう!

sealed(シールド) class なんてのがあるんだ
また守備力があがってしまうな
26デフォルトの名無しさん:2008/03/15(土) 01:55:08
Java 系だから final でいいと思うのに
C# 風の名前付けしてるんだな。
27デフォルトの名無しさん:2008/03/15(土) 02:06:23
>>26
いや、実はfinal classもあるんだけど、sealedとは意味が違うという罠
final classはJavaのそれと同じで、そのクラスから継承することができない
という意味。sealed classは同じコンパイル単位でならそのクラスから継承する
ことができる
28デフォルトの名無しさん:2008/03/15(土) 02:08:49
>>24
洋書では、Programming in Scalaという本が(今年中?)出る予定。
現在は、PrePrint版を購入することができる。
http://www.artima.com/shop/forsale
29デフォルトの名無しさん:2008/03/15(土) 02:09:40
>>27
なるほど。
30デフォルトの名無しさん:2008/03/15(土) 02:11:46
>>27
なるほど
31デフォルトの名無しさん:2008/03/15(土) 02:16:44
ttp://www.scala-lang.org/docu/files/ScalaReference.pdf
を読んでたんだけど(読めないけど)
予約語の一覧に「public」が見当たらない

しかも
AccessModifier ::= (‘private’ | ‘protected’) [AccessQualifier]
って書いてある。

もしかしてScalaには「public」修飾子がない?
クラスもメンバもみんなデフォルトでpublic?
32デフォルトの名無しさん:2008/03/15(土) 02:22:19
>>28
サンクス
今年中か。。
英語の勉強でもしとくか・・・
3331:2008/03/15(土) 02:27:08
試してみればよいのか


scala> var public = 1
public: Int = 1

scala> System.out.println( public )
1


あぁ… 無いんだ
34デフォルトの名無しさん:2008/03/15(土) 02:27:47
>>31
うん。Scalaではアクセス修飾子はデフォルトでpublicなので
用意されてない。
35デフォルトの名無しさん:2008/03/15(土) 12:14:16
>>27
jarのマニフェストに書くSealedと同じようなものか。
36デフォルトの名無しさん:2008/03/15(土) 15:53:01
>>8
case classは、
pattern matchのある
C言語でいうところのunionです。

一つの型にマージしたいところに使います。
例えばポインタがどのケースも指す可能性がある場合。
37デフォルトの名無しさん:2008/03/15(土) 21:42:49
Rubyとどっちが強いの?
38デフォルトの名無しさん:2008/03/15(土) 21:49:33
Scalaです。普及度以外は。
39デフォルトの名無しさん:2008/03/15(土) 22:04:37
Rails相当のものはありますか?
40デフォルトの名無しさん:2008/03/15(土) 22:08:04
Javaの標準ライブラリなら何でも使えるの?
41デフォルトの名無しさん:2008/03/16(日) 01:44:44
traitとabstract classの違いって何ですか?
なんか、同じのような……。

>>40
多分そうです。
42デフォルトの名無しさん:2008/03/16(日) 02:13:39
>>41
abstract class は抽象クラスで trailtはmixin
継承元としての抽象クラスはひとつしか指定できないけど、mixinはなんぼでも指定できる。

abstract class 通信機
trait テレビ
trait おサイフ
class 携帯電話 extends 通信機 with テレビ with おサイフ {
 …
}
43デフォルトの名無しさん:2008/03/16(日) 02:22:25
class A extends B とした場合、
継承だと B に A の実装を追加したものが A になるし、
mixin だと A に B の実装を追加したものが A になる。
継承と mixin の大きな違いはここにある。

>>1 のチュートリアルにある例で言えば、
Ord の実装の中に

 def <=(that: Any): boolean =
  (this < that) || (this == that)

ってのがあるけど、Ord の中には == の実装どころか宣言すらない。
mixin 先に == があれば使えるし、無ければ使えない。
== が既にあるクラスに mixin されることを前提に作られている。
44デフォルトの名無しさん:2008/03/16(日) 02:28:46
つまり、mixin の場合は A にある実装を B で使うことができる。
継承では派生クラスの情報を基底クラスで使うことになるから、
こういうことは基本的にはできない(CRPT は例外だが)。
45デフォルトの名無しさん:2008/03/16(日) 14:55:02
CRPTって何?
46デフォルトの名無しさん:2008/03/16(日) 18:48:17
http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern

要するに親クラスが派生クラスの実装に依存できる。
boostのiterater_facadeで非常にうまく使われてる。
47デフォルトの名無しさん:2008/03/17(月) 08:24:53
mixinがあれば継承はなくてもいいのかな
overrideができないのかも知れないが
48デフォルトの名無しさん:2008/03/17(月) 10:15:18
Scala的に望ましい言語仕様と、JVMのセマンティクスとの軋轢ってないの?

YASVマダーチンチン。
49デフォルトの名無しさん:2008/03/17(月) 10:17:58
>>22
次に読むべきはたぶん、このへん。
http://www.pana-wave.com/news_lr.html
50デフォルトの名無しさん:2008/03/17(月) 11:11:29
「スカラー値」とかの普通名詞じゃなくてなんかの固有名詞で
響きが脳みそのどっかにひっかかってたんだけど

これだったか・・・
51デフォルトの名無しさん:2008/03/17(月) 22:44:57
The Scala Language Specificationとかにさっと手が伸びるような人は
画面で読んでるのでしょうか?
印刷して読んでるのでしょうか?
52デフォルトの名無しさん:2008/03/17(月) 23:06:46
印刷一読、画面参照
53デフォルトの名無しさん:2008/03/19(水) 23:08:23
初ほしゅ・・・って、まだ不要なのか?
54デフォルトの名無しさん:2008/03/22(土) 20:14:39
なぜ素直にJRubyをつかわないのか
55デフォルトの名無しさん:2008/03/22(土) 21:30:09
JRubyってアプレット作れるの?
56デフォルトの名無しさん:2008/03/22(土) 21:33:55
作れるけどなに?
57デフォルトの名無しさん:2008/03/22(土) 21:44:01
Rubyは危険な宗教だから近づきたくない
58デフォルトの名無しさん:2008/03/22(土) 21:46:35
モルモン教か
59デフォルトの名無しさん:2008/03/22(土) 21:48:17
>>54
やっぱスピードじゃない?
60デフォルトの名無しさん:2008/03/23(日) 02:41:29
>>54
型チェックに魅力を感じるからじゃない
61デフォルトの名無しさん:2008/03/23(日) 03:57:02
代入式がUnitを返すのですが、こういう仕様なのですか?
62デフォルトの名無しさん:2008/03/23(日) 05:15:27
うん
63デフォルトの名無しさん:2008/03/23(日) 05:26:08
Scalaは面白いしそこそこ使えそうではあるんだけど
構文を導入せずに見た目の帳尻だけ合わせてる部分が
長い目でみればマイナスに表れるという感がぬぐえない。
丁度C++のような立ち位置だと思うこともあって、将来的な筋の悪さを感じる。
(C/オブジェクト指向/C++ と Java/関数型/Scala という対比。)
64デフォルトの名無しさん:2008/03/23(日) 08:29:46
>>63
C++のような立ち位置といのは言い得て妙だな
65デフォルトの名無しさん:2008/03/23(日) 08:31:24
途中で送信してしまった。
ただ、構文を導入せずに見た目の帳尻だけ合わせてるってのは
どの辺だろう?case class/pattern matchingの辺り?
66デフォルトの名無しさん:2008/03/23(日) 14:54:43
>>63
おいおい、Scalaは設計センスはすごくいいぞ。
ありとあらゆる言語をよく研究した結果作られた言語。
問題は流行るかどうか。

うまく作りすぎてるんで、
perl/python/rubyなんかのなんちゃって言語よりは、
最初のハードルが高いし。
67デフォルトの名無しさん:2008/03/23(日) 14:56:39
ScalaってHaskellかOCaml
強いて言えばどっちに近いですか?
68デフォルトの名無しさん:2008/03/23(日) 16:09:26
OCamlじゃないかな。評価戦略とオブジェクト指向。
69デフォルトの名無しさん:2008/03/23(日) 19:57:06
>>66
> ありとあらゆる言語をよく研究した結果作られた言語。



> おいおい、Scalaは設計センスはすごくいいぞ。

の根拠にはならんだろう。
70デフォルトの名無しさん:2008/03/23(日) 21:07:51
>>67
強いて言えばOCamlだけど
OCamlは関数型言語にOOするための機能を入れた言語
ScalaはOO言語に関数型プログラミングをするための機能を入れた言語
って感じでScalaの方がよりOOよりな感じはするね
71デフォルトの名無しさん:2008/03/23(日) 23:24:09
型システムは、メジャーな言語ではC++0xが一番近いよ。
後はHaskellとかGとか。

JavaとかノーマルなOCamlはクラス指向が非常に強いから似てない。
72デフォルトの名無しさん:2008/03/23(日) 23:29:17
C++0xってメジャーな言語なのか?
73デフォルトの名無しさん:2008/03/23(日) 23:35:25
おお、Scalaのスレができてる
Scala自体はいい言語だけど、Javaのライブラリがうんこだよな
74デフォルトの名無しさん:2008/03/23(日) 23:57:28
ライブラリのどの変がダメ?
75デフォルトの名無しさん:2008/03/24(月) 00:03:13
Scalaのライブラリはどうですか?
76デフォルトの名無しさん:2008/03/24(月) 11:10:28
>>74
粒度が細かすぎて使いづらいというのはよく言われていることだけど、
それをScalaから使うというのがまたしんどい
結局Java使ってるのと大差ない気がしてくる
77デフォルトの名無しさん:2008/03/24(月) 12:57:22
>>76
Scalaから使うときは簡単なラッパーをかましてやるのが良い使い方だと思う
本当のところ、早いところScala独自のライブラリが充実して欲しいんだけど
簡単なラッパー作るくらい大した手間じゃないし自作するのが手っ取り早い
たとえば、IOならこんな感じ

// 定義
def withReader[T](File path)(proc :BufferedReader => T) :T = {
val reader = new BufferedReader(new FileReader(path))
try {
proc(reader)
} finally {
reader.close
}
}

// 使用
withReader(new File("hoge.txt")){reader =>
//readerを使ったコード
}

ちなみにscala.io.Sourceは色々と微妙で、使いづらい
78デフォルトの名無しさん:2008/03/24(月) 22:58:01
それだと使う側のセンスが問われそうだな
俺だと劣化Rubyライブラリになってしまいそうだ
標準ライブラリで言語のポテンシャルを示してほしいところなのだが
つーかこんなラッパーが全世界で何百と作られてんだろうなあ
79デフォルトの名無しさん:2008/03/24(月) 23:01:55
というかラッパーが物凄く簡単に書けて、
再利用性も高いのが言語の売りの一つなので。
80デフォルトの名無しさん:2008/03/25(火) 10:15:09
Lisp方言並に溢れかえるラッパーにwktk
81デフォルトの名無しさん:2008/03/25(火) 12:08:18
>>48に誰も反応してくれなくて寂しい俺が来ましたよ
# あれは正確には、「JVM命令セット群のセマンティクス」と書くべきだった

ライブラリの話も出てるし、言語として完成度上げるには、やっぱそろそろJava依存抜けようか。
って無理か。
82デフォルトの名無しさん:2008/03/25(火) 16:48:04
どうしても隠せないのは実装に近いところ。
例えばboxing/unboxing関係のAnyVal/AnyRef。
83暗黙のthis:2008/03/25(火) 17:24:39
ScalaOverview.pdfの
def + (x: Nat): Nat =
if (x.isZero) this else succ + x.pred
って、
def + (x: Nat): Nat =
if (x.isZero) this else this.succ + x.pred
のことなんだな。ちょっと混乱したので書いとく。
84デフォルトの名無しさん:2008/03/25(火) 17:58:15
>>81
配列周りはScalaの処理系が凄いがんばって他のgenericなクラスと同じように
見せようとしてるなあと思った。JVMでは配列が特別扱いされてるから、
genericなクラスのように見せかけるのはなかなか大変



>>83
暗黙のthisはJavaでもほぼ同じだから、そんなに混乱しないと思ったけど、どうなんだろう。
Java以外の言語からScala入った人?
85暗黙のthis:2008/03/25(火) 18:04:02
operation invocationに()がないから混乱した。
Java以外にも関数型言語も分かるので、
curry化されてるのかな?と思ってしまった。
86デフォルトの名無しさん:2008/03/25(火) 18:04:55
>>82
> boxing/unboxing関係のAnyVal/AnyRef。
なんとなく想像は付くんだが、具体的にはどんな例がある?
87デフォルトの名無しさん:2008/03/25(火) 18:06:59
>>85
ああ、なるほど。invocationの()省略できる辺りは、なんか
構文的にRubyっぽい感じがするね。Scalaは細かいところで、
色々syntax sugarが多いから、慣れない内は混乱の元にも
なるなと思った
88デフォルトの名無しさん:2008/03/25(火) 18:11:19
あ、省略できるってのはちょっと不正確だったのでちょっと補足。
Scalaで0引数のメソッドを定義する方法は二つあって、
一つは

class HelloWorld {
def print :Unit = { println("Hello, World!") }
}

という形。この形の場合、
val hello = new Hello
hello.print
という形でのみ呼び出すことができ、hello.print()という呼び出し形式は
コンパイルエラーになる。もう一つは、

class HelloWorld {
def print() :Unit = { println("Hello, World!") }
}

という形。この形の場合、hello.print()と書いてもhello.printと書いても
OK。
89デフォルトの名無しさん:2008/03/25(火) 18:29:49
>>86
BoxedArrayはあれば便利だけど、なくても何とかなる。
どうしてもArrayの要素をポインタ共有したい時は、
セルクラスに入れてからArrray[セル]にすればいいから。
けどJavaではBoxedArrayがあるから、作っとかないと困る。

>>84のいうようにうまく処理されているとは思う。
Nothingがあるからprimitive = null;問題も起きないし。

90デフォルトの名無しさん:2008/03/26(水) 02:37:56
あんま愚痴っててもしょうがないので、
ありがちなところで、Ruby風文字列、正規表現ラッパーを作ってみた
と言っても、まだ半分も実装できてないけど

http://hexx.sakura.ne.jp/scala/RubyString.scala

使い方は、こんな感じ

import ruby._
import ruby.RubyString._

println("hoge %d %s" % (1, "fuga"))
// → hoge 1 fuga
// Rubyでは
// "hoge %d %s" % [1, "fuga"]

"a\nbbb\nccccc\n".each(l => print(l.length))
// → 246
// Rubyでは
// "a\nbbb\nccccc\n".each {|l| print(l.length)}

println("abcde".sub("(a)b(c)d(e)") { m =>
val lm = RubyRegexp.lastMatch
lm(1).upcase + lm(2).upcase + lm(3).upcase
})
// → ACE
// Rubyでは
// "abcde".sub(/(a)b(c)d(e)/) { $1.upcase + $2.upcase + $3.upcase }

今のところ、Rubyに比べて嬉しいのは、EmacsのFlymakeがよく効くところだな
悪いところは、スクリプトで使うと、やっぱり起動が遅い
91デフォルトの名無しさん:2008/03/26(水) 02:57:01
>>90
遅いよねぇ。

開発をスクリプトでやってデプロイはコンパイルしてって感じになるのかな。
でもあの起動の遅さはリズムが崩れる。
92デフォルトの名無しさん:2008/03/28(金) 00:39:06
NetBeansでScalaが書けるって聞いたんだけど
試してみた人いる?
93デフォルトの名無しさん:2008/03/28(金) 00:42:07
>>90じゃあ開発者の楽しさとしてはやっぱりRubyのほうがいいんだね。実行するたびにモタつくなんてなぁ。
94デフォルトの名無しさん:2008/03/28(金) 01:38:57
>>93
> 開発者の楽しさ

俺はコンパイラに指摘される型エラーをつぶしていくのが楽しい
だからMLも好き
95デフォルトの名無しさん:2008/03/28(金) 06:50:40
同じJVMをつかっているのに、なぜJRubyよりも性能がいいのですか?
Rubyをなんちゃって言語というほど高尚なのですか?Rubyより悪い点はどこですか?
96デフォルトの名無しさん:2008/03/28(金) 07:01:52
>>95
性能がいいのは主に

・静的型付けであり、かつ比較的Javaに型システムが近いこと
(メソッド呼び出し時にinvokevirtualなどVMのメソッド呼び出し命令をそのまま
利用できるし、数値演算もVMの命令を利用できる)

が理由だろうな。他の理由もあるだろうけど、たぶんこれが一番大きい。
97デフォルトの名無しさん:2008/03/28(金) 09:36:07
楽しさって言われてもなあ、スクリプトの起動がそれほど気になるならそうかもしれないけど
対話環境で開発することも多いだろうし、Scalaはスクリプトの方がメインではないだろうし

Rubyとの違いは、やっぱり型が静的か、動的かにつきるんじゃないの?
静的な型でもここまでできると思うか、
やっぱり面倒臭いから静的な型なんていらないと思うか

あとは関数型から引き継いだパターンマッチ、ケースクラスとか
ErlangからパクったActorがどれくらい役に立つか
98デフォルトの名無しさん:2008/03/28(金) 09:39:38
JRubyより性能いいの?
JRubyってJavaのバイトコードをターゲットにしたコンパイラなの?
独自バイトコードインタープリタなら遅くて当たり前だけど…
99デフォルトの名無しさん:2008/03/28(金) 09:42:59
>>97
あと、mixin-compositionがあるのが重要。
100デフォルトの名無しさん:2008/03/28(金) 10:03:23
ああ、そういえばScalaは後からmixinを足せるんだったな
確かに使い方によっては強力な感じはする
101デフォルトの名無しさん:2008/03/28(金) 11:34:23
ぶっちゃけmixinはあんまり要らんなーと個人的には思う
caseクラスとかマッチングあたりはうれしいけど
Actorはまだ触ってないのでなんとも
102デフォルトの名無しさん:2008/03/28(金) 13:53:22
>>92
6.1betaに開発版プラグインの所を参照させて出来たよ。
103デフォルトの名無しさん:2008/03/28(金) 14:52:00
actorやmixinはプログラミングモデルだから、
慣れてない人は有り難みは分からない。
使って慣れるのみ。
104デフォルトの名無しさん:2008/03/28(金) 16:36:28
>>101
mixinはライブラリ書くとき嬉しいよ
例えば、コレクションぽく見せかけたいものに対して、scala.Iterable[T]をmix-inして、
elements :Iterator[T]だけを実装すれば、Iterable[T]にある便利な高階関数やらを
全部使えるとか。たとえば、Reader系のクラスをサブクラス化してIterable[String]
を実装するなどが考えられる。
105デフォルトの名無しさん:2008/03/28(金) 16:38:55
>>98
昔のJRubyは普通のインタプリタだったはず。その頃は凄く遅かった
最近のJRubyは内部でJVMのバイトコードにコンパイルして実行するようになった
ので速くなった。でも、Scalaには性能で遠くおよばない(言語の特性上仕方無い
けど)
106デフォルトの名無しさん:2008/03/28(金) 22:34:26
開発効率ではJRubyに遠く及ばない(言語の仕様上しかたないけど)
107デフォルトの名無しさん:2008/03/28(金) 22:48:31
どうせJRubyもScalaも使ったことないくせに
108デフォルトの名無しさん:2008/03/28(金) 22:58:47
JRubyは使ってるよ。Scalaはこれから試すよ。
仕様が汚ないけど、型があるからRubyより性能は良いってことだろ。
109デフォルトの名無しさん:2008/03/28(金) 23:13:00
マジレスだったのかよ!
で、Scalaの仕様のどの辺が気に食わないのよ
開発効率が遠く及ばないというほどの何かがあるの?
110デフォルトの名無しさん:2008/03/29(土) 03:11:22
rubyの話いらね
111デフォルトの名無しさん:2008/03/29(土) 08:35:05
>>104
多重継承の代用?
多重継承ではなくmix-inが欲しくなる場面の例はありませんか?
112デフォルトの名無しさん:2008/03/29(土) 09:06:23
基本的にmixinは多重継承の代用でしょ
mixinそのものの有用性については
Rubyが先駆者だからRubyの事例を調べた方がいいと思うよ
(またRubyの話になっちゃったけど…)
113デフォルトの名無しさん:2008/03/29(土) 10:23:43
機能的にはリッチ版だよ。
name conflictやmutliple pathを解決するための機構をプログラマに対して与える。

どれもがコンクリートクラスになりがちなクラス指向のプログラミングモデルから、
機能mixinを集めてくっつけて実用クラスを構成する〜モデルになる、というかする。

name conflictやmutliple pathはmixする時に解決できるから、
このクラスとあのクラスはうまく多重継承/結合出来ないというケースがぐんと減る。

代用とかじゃなくて、機能が増えたのがmixin。
元祖はLisp Machine LispのFlovors。
基本フレーバーを調合して、香水を作るって考え。
コンポーネント志向が強い。

もちろんmixinなくても同じことはできるよ。
アセンブラあればなんでもできるという意味では。
114デフォルトの名無しさん:2008/03/29(土) 10:39:13
え、ちょっとよくわからない
どの辺が多重継承よりリッチなの?
115デフォルトの名無しさん:2008/03/29(土) 10:56:30
つ 版
116デフォルトの名無しさん:2008/03/29(土) 11:03:09
版?
117デフォルトの名無しさん:2008/03/30(日) 00:34:31
機能は多いだけじゃだめだとおもう。わかりやすくないと。
Rubyはその辺のバランス感覚に優れているからね。
118デフォルトの名無しさん:2008/03/30(日) 00:53:52
Ruby信者もバランス感覚を覚えて欲しい
119デフォルトの名無しさん:2008/03/30(日) 12:21:15
だからもっと具体的な話しろよ
Scalaの仕様のどこがいいとか悪いとか、mixinの話も>>111に答えてやれよ

と嗾けるだけでもなんだから
俺がScalaで良いと思ったのはカリー化と無名関数だな
Rubyのブロックはへんてこ構文だったけど、Scalaはすっきりしてると思う
120デフォルトの名無しさん:2008/03/30(日) 17:56:01
部分適用はあるが、カリー化なんてあったっけ?
121デフォルトの名無しさん:2008/03/30(日) 18:02:14
カリー化はFunction.curriedでできるが、
ここで俺が言いたいのはカリー化された関数を直接書けるということだな
言葉足らずですまんが
122デフォルトの名無しさん:2008/03/30(日) 18:12:43
これか

def add(a: Int)(b: Int)(c: Int) = a + b + c

add(1)(2)(3) // 6
123デフォルトの名無しさん:2008/03/30(日) 18:18:28
>>119
それならお前が答えればいいのに
124デフォルトの名無しさん:2008/03/30(日) 18:26:14
>>122
うん、それ
Rubyではわざわざブロック構文を導入しているが
Scalaではそれと無名関数を組み合わせて、
同じようなことがすっきりとできるじゃん
というだけの話なんだけど

>>123
いや、俺はmixinは制限付き多重継承だと思ってるから
だから>>113が答えてやれよと
まあ多重継承の定義の問題なんだろうな
125デフォルトの名無しさん:2008/03/30(日) 20:11:51
> 俺はmixinは制限付き多重継承だと思ってるから

kwsk
126デフォルトの名無しさん:2008/03/30(日) 20:25:14
mixin 多重継承でググれば、mixinは多重継承の一種だという説明が多い
Rubyのまつもとさんによれば、mixinは多重継承のサブセットらしい
俺もそう思っていたというだけの話
Scalaのmixinに何か特別な機能があるかどうかは知らない
127デフォルトの名無しさん:2008/03/30(日) 22:16:06
>>126
基本的にそういう認識(mixinは多重継承のサブセット)でいいと思う
Scalaのmixinに何か特別な機能があるかと言えば、たぶん無い
俺がScalaで好きなのは、ExtractorとViews、implicit parameterだな
これらの機能がある言語は、今まで見たことがなかったので新鮮だった
128デフォルトの名無しさん:2008/03/30(日) 22:20:39
開発効率の話について言えばScalaがRubyに遠くおよばないなんて
ことは無いと思う。静的言語ゆえの制約(evalできないとか)はもちろんあるけど、
そもそもそういうのを濫用したプログラミングはそうそうする必要は無いし
for-comprehensionやextractorなどRubyに無い便利な機能もあるし
129デフォルトの名無しさん:2008/03/31(月) 06:33:34
Scalaのmixinは多重継承にならないよう配慮してるね。
別クラスから継承して作ったtraitはmixinできないとか。
130デフォルトの名無しさん:2008/04/02(水) 20:45:51
>>128正論だとはおもうが、そゆ発言はRuby厨を刺激するのでは
131デフォルトの名無しさん:2008/04/03(木) 23:51:57
簡潔にかける!=わかりやすい、というのを体現した言語だなあ。
確かに個々の機能は優れていると思うが、表現の幅がひろすぎて自分とスタイルの違う書き方がほんと馴染まない。
Rubyのほうがコードの一貫性という意味では良いのかもしれないね。
132デフォルトの名無しさん:2008/04/04(金) 00:32:15
文法的にはRubyにforとパターンマッチが入った程度だろうに
ほんとにScala使ったことあるのかよ
133デフォルトの名無しさん:2008/04/04(金) 00:45:09
>>131
Rubyと違って仕様が一貫してそうですが
134デフォルトの名無しさん:2008/04/04(金) 02:23:30
>>132
>文法的にはRubyにforとパターンマッチが入った程度だろうに
あなたもちゃんと使ったことがあるのか疑問があるんだが
どうせ、ちょっとTutorial見ただけで、決め付けただけなんじゃないの?
135デフォルトの名無しさん:2008/04/04(金) 02:29:46
特にScalaの型システム(implicit conversion, higher-kind generics, path-dependent typeなど)
調べてみれば、とてもRubyにforとパターンマッチが入った程度なんて言えない
もちろん、それらがどれくらい使い勝手に影響があるか、という評価は必要だが
136デフォルトの名無しさん:2008/04/04(金) 02:33:36
>>134
ちゃんと使ったことあるというのがどのレベルかはわからないがプログラムはある程度書いたよ
他にRubyよりわかりにくくなるほど簡潔にかけるところあるか?
型絡みは簡潔にはなるという方向じゃないでしょ

>>135
だからViewsやジェネリクスでRubyより簡潔にはならないでしょ
>>131は簡潔に書けすぎたり、表現の幅が広すぎてRubyより一貫性がないって言ってんだから
そういうレベルの話だよ

つーか、なんで俺が文句言われるのがわからん
137デフォルトの名無しさん:2008/04/04(金) 06:45:15
相変わらずRuby厨が無駄に湧くスレだなぁ
138デフォルトの名無しさん:2008/04/04(金) 10:52:07
阿呆は放置推奨
139デフォルトの名無しさん:2008/04/04(金) 22:50:01
逆にRubyやったことがある人に向いてる言語と思うんだけどなあ。
140デフォルトの名無しさん:2008/04/04(金) 23:10:57
Rubyと比較しただけでRuby厨呼ばわりはひどいですね。
Rubyから来た私とJavaからの移行組の同僚のコードがスタイルバラバラになったんで感想を延べただけなんですが。
141デフォルトの名無しさん:2008/04/04(金) 23:27:13
同僚って、もう仕事でしかも共同開発って使ってるの?すごい
142デフォルトの名無しさん:2008/04/05(土) 01:02:21
Scalaで仕事?
143デフォルトの名無しさん:2008/04/05(土) 01:30:16
>>140
コーディングスタイルについては、Rubyだってかなり幅が広くて、
書く人によって全然違うコードになったりすると思うんだが、違う?
というか、○○言語だったらコーディングスタイルを均質化できるというのが
そもそも幻想な気がする
144デフォルトの名無しさん:2008/04/05(土) 01:31:53
馬鹿だから厨と言われてるんであって、Rubyはむしろ被害者。
145デフォルトの名無しさん:2008/04/05(土) 03:14:08
>>139
Rubyなんて触ったことすらない
146デフォルトの名無しさん:2008/04/05(土) 08:32:24
>>143
そのとおり。というか>>131は、
Rubyでしか一貫性のあるコードが書けない(書く気がない)という気がする
147デフォルトの名無しさん:2008/04/05(土) 22:34:48
確かにrubyに似ているんだけど、{}スタイルのブロックは俺には必要だなと再認識した。
haskellでみた変態的コーディング表記も緩和されてわかりやすいスタイルになっている。
一部なんとなく気にくわない所もあるけど仕様上しかたないことなのかな?(arrow回り)
それと変数名が先にくるのは後で何かよいことあるの?
あとdefineじゃなくてdefならさー、objectじゃなくてobjくらいにしてくれたほうがいいなぁ。

と、c++もjavaもrubyもhaskellもMLもlispも全然できないvb6厨の俺が見た目だけで評価。
148デフォルトの名無しさん:2008/04/05(土) 23:04:56
>>147
型宣言が後置で良いことがあるかと言えば、まあ好みの問題なんで
なんとも。ただ、一般論として型宣言が後置の方がパーザ書きやすくなるという
話はある。
149デフォルトの名無しさん:2008/04/05(土) 23:43:18
なんか、配列やマップ(ハッシュ)の参照も()なのが紛らわしい・・・
なんで同じにしたんだろ。
150デフォルトの名無しさん:2008/04/06(日) 00:00:27
リテラルじゃなくてapplyで実装されてるからな
Rubyみたいに大クラス主義ならリテラルと相性が良いと思うが
Scalaの場合、Javaのものと合わせて大量にコレクションクラスがあるから、
リテラルの恩恵があまりないという判断なんだろうな
151デフォルトの名無しさん:2008/04/06(日) 01:07:40
ツアーを読み始めてからjavaのよく分からない
機能(アノテーションとかジェネリック?)とかを調べ始めているうちに
まったく放置していたC#って言語が出てきて、これにも結構近いなぁ。
c# extends c++ interface 関数型言語,vm
に対して、
scala extends ruby,java,変態的言語

C++0xもおもしろそうだがまだvb6の総合的な簡潔さにはかなわない気がする。
152デフォルトの名無しさん:2008/04/06(日) 02:56:08
>>149
genericsのために、既に[]は使っちゃってるからぶつかる
っていうのが主な理由じゃないかと
153デフォルトの名無しさん:2008/04/06(日) 02:58:53
ところで、()使うのがそんなに紛らわしいかな?別に区別が付かない場面なんて
そうそう無いと思うんだが。あと、実用上のご利益として、関数引数を
要求してるとこに、配列やらMapをそのまま突っ込める、というのがある
val f : String => Int = Map("A" -> 1, "B" -> 2, "B" -> 3)
なんてのがOKなわけだ
154デフォルトの名無しさん:2008/04/06(日) 04:06:22
これって知らなかったが、PartialFunctionを先祖で継承しているからなのか?
関数を継承してるコレクションって珍しいな
155デフォルトの名無しさん:2008/04/06(日) 04:39:06
>>154
YES。
確かに、単に関数っぽい、じゃなくて、実際に関数として扱うことができるコレクションという
設計はあまり見かけない気がするね
156デフォルトの名無しさん:2008/04/06(日) 07:38:00
>>149
Fortranと一緒だと思えばいい
157デフォルトの名無しさん:2008/04/06(日) 10:56:18
〜.run()とか〜.invoke()じゃなくて〜()って出来る

こういうのが浸透してきたから、
コレクションの要素取得にも一般化したんでしょ。
158デフォルトの名無しさん:2008/04/07(月) 14:41:16
他に、関数と配列で同じ表記使う言語あったかなと思ったら、
BASICもそうだったなw
159デフォルトの名無しさん:2008/04/07(月) 17:44:31
なんか、型推論があれば、
動的型付けなんかいらないみたいな事が書いてあったけど、
本当にそうなの?
160デフォルトの名無しさん:2008/04/07(月) 18:07:32
>>159
動的型付けや型推論の定義によるけど
動的型と言っても結局実行時には何の型であるかを決めて変換しないと実行できないので
それをコンパイル時にやってるのが型推論ということだとすれば
実行時まで型がわからない状況以外は全部型推論で片付くことになる
ただ実行時まで型がわからない状況ってevalくらいしか思いつかないのだが・・・
161デフォルトの名無しさん:2008/04/07(月) 19:50:51
動的型付けだと、状況によって型が違う関数とかが発生するでしょ。
例えば Lisp 系なんて、何でも入るリストがデータ構造の基本なんで、多くの関数の型は引数とかに依存する。
型を決めて変換するってよりは、型に応じて分岐処理したりするような世界だから、推論は難しいと思うけど。
162デフォルトの名無しさん:2008/04/07(月) 20:09:32
型に応じて分岐処理ってポリモーフィズム?
163デフォルトの名無しさん:2008/04/07(月) 20:11:42
>>161
何でも入るっていっても、本当に実際に何でもつっこむような使い方って
Lisp系でもそんなにしない気がするんだが、どうだろう。Lispのエキスパートじゃないので
自信があるわけじゃないけど。で、もしこれが真ならvariant(VBのじゃなくて、MLとかの
やつね。Scalaで言うとcase class)があれば大体事足りるのではないかと
164デフォルトの名無しさん:2008/04/07(月) 20:40:31
>>159
「型推論」じゃなくて「強い型付け」の間違いですか?
165デフォルトの名無しさん:2008/04/07(月) 20:50:26
Scala at Waves (SaW):
 問題をガリガリ破壊していくフレームワークのような何か。白装束を着ないと自分も破壊される。
166デフォルトの名無しさん:2008/04/07(月) 20:54:14
なんでgenericsに<>使わないの? Foo<Bar<Bazz>> ←ここの問題とかだったりしたら orz

{ブレース}使って見た目の「普通感」があるのはJavaneseに取ってもいいことだと思うんだけど、
それをメリットとして軽く触れられた後で<>が[]です、[]が()です、型は後置です、って言われても
やっぱり見慣れない感が。
理論的・技術的に問題ないのと、今までの目の慣れにやさしいかは別問題。
167デフォルトの名無しさん:2008/04/07(月) 21:01:41
C++はC++0xで>>とくっつけて書いていいようになりました。
要するに文脈依存でlexer頑張れと。
168デフォルトの名無しさん:2008/04/07(月) 21:07:30
>>167
lexerに文脈を表す状態を持たせる必要……この道はいつか来た道。 ←ruby/parse.y orz
169デフォルトの名無しさん:2008/04/07(月) 21:11:48
<>でも[]でもどっちでもいいじゃん
170デフォルトの名無しさん:2008/04/07(月) 21:24:44
{}でもdo..endでも でもどっちでもいいじゃん
171デフォルトの名無しさん:2008/04/07(月) 21:34:19
それは{}でお願いします
172デフォルトの名無しさん:2008/04/07(月) 22:14:10
>>166
Javaのgenericsにその問題はないから別の理由だろ
173デフォルトの名無しさん:2008/04/07(月) 22:25:20
>>166
本当のところ、理由はわからんが、記号がかぶらん方が、パーザにとって
色々都合が良いという話はある。例えば、 A[B] Cという式があったとして、
これがA<B> Cだったら、記号表みないと、A < B > Cという式と区別つかんとか。
174デフォルトの名無しさん:2008/04/07(月) 22:29:23
>>173の例はミス。A[B] Cだとまずかった。書き直すと、

a.b[C](d)という式があったとして、これがa.b<C>(d)だったら、
記号表みないと、a.b < C > dという式と区別つかんとか。
175デフォルトの名無しさん:2008/04/08(火) 00:34:40
>>174は処理系実装と言語仕様の思考分離を(ry
176デフォルトの名無しさん:2008/04/08(火) 01:11:10
>>175
いや、もちろんわかってるよ。ただ、処理系(というかパーザ)の実装のしやすさを
考えて、問題無い程度に構文を変えるというのは普通にあり得る話だと思う
177デフォルトの名無しさん:2008/04/08(火) 01:28:03
D 言語なんかまさにそうだな。
実装しやすいような言語仕様にするってのを1つの柱にしている。
D 言語は構文解析と意味解析が 100% 分離可能。
逆に C++ とかは泥沼。全言語の中で最もパーサが作りづらい。
178デフォルトの名無しさん:2008/04/08(火) 18:22:34
>>176
同意。ただ>>173のような例が「問題がある」程度の実装の難しさを引き起こすかな。
テーブル見る必要があるのはスマートじゃないけど、見慣れた記号の意味が変わらない、というのは
一つのメリットになり得るから、トレードオフとして検討する価値はあるんじゃないかなぁ。

けど、[とか]が単独で演算子として使われたことはないだろうから、それを<と>の代替として選んだ
Scalaの中の人は確かにちゃんと考えてるなーと思う。
179デフォルトの名無しさん:2008/04/08(火) 18:23:45
>>177
C++なぞ問題外 (^^)
180デフォルトの名無しさん:2008/04/08(火) 18:35:02
とりあえず参考資料 っ

> * Features of Ruby
>  + Simple Syntax
(from README)

Pseudo simplicityとか言い張ってるやつだな。どこがpseudoって、parse.yの大きさ見れば分かる。

Rubyの主張は、見た目の良さと実装難易度は直交するということじゃまいか。
たしかにBrainf**kなんか挙げればそれっぽい気もするが、ある程度の複雑さを備えた実用的な
言語仕様でも上記が主張できるかどうかは、意見が分かれるところだろう。
(見た目がシンプルなら実装も簡単になりやすいんじゃないか、等々)
181デフォルトの名無しさん:2008/04/08(火) 18:37:23
>>180
「見た目の良さ」だと曖昧だな。理解のしやすさ、くらいか。まぁその指標自体が曖昧だが。
182デフォルトの名無しさん:2008/04/08(火) 21:54:49
>>174
不等号を連続させられないようにする、という選択肢もあるね。
183デフォルトの名無しさん:2008/04/08(火) 23:21:05
>>180
> Pseudo simplicityとか言い張ってるやつだな。どこがpseudoって、parse.yの大きさ見れば分かる。

それだけだと単にyaccが適切な道具じゃなかったという可能性が否定できないよ。
184デフォルトの名無しさん:2008/04/08(火) 23:25:20
>>183
Rubyの文法は、lexer/parserを分離する事が前提の構文解析アルゴリズム
は向いてない可能性はあるね。
185デフォルトの名無しさん:2008/04/08(火) 23:52:00
Cが駄目だね。> 分離
186デフォルトの名無しさん:2008/04/10(木) 23:23:22
>>183
LALR(1)が、なら同意だけど、単にyacc(bison)が、ならあんまり同意できないかも。
parse.y覗いたことある? あんなことやってたら他のパーザジェネレータ使ってもコードが太りそう。
結局は>>184のが本質ついてるのかも。
187デフォルトの名無しさん:2008/04/10(木) 23:34:41
とりあえず誰か、Scalaの超絶技巧を使って[Type]を<Type>と書けるようにするライブラリの実装ヨロスコ
// TypeじゃなくてKlassか?
188デフォルトの名無しさん:2008/04/11(金) 00:03:10
>>187
さすがにそりゃ無理があるw
Camlp4みたいに標準的な構文拡張のための方法が用意されてるならともかく
Scalaではそういうのは無いはずだし
189デフォルトの名無しさん:2008/04/11(金) 00:15:09
>>186Rubyをわかってねーな。プログラマのためにあえてあーなってんだろうが。
190186:2008/04/11(金) 01:55:57
>>189
んと、言語として「プログラマのためにあーなって」るのは否定も嫌悪もしてないっす。
ただ、とりあえず現状の(というか「lexer/parserを分離する事が前提…」であると?)
実装は、大変そうだな、と。lex_stateとかlex_stateとか。

だからといって、プログラミング言語の文法に置ける、人にとってのsimplicityの定義:
  LALR(1)に収まること。
っていうのは違うよなぁ。

おぉっと、Scalaな話からそれてしまう。いいかみんな、共産ゲリラたちが発する電磁波は……
191デフォルトの名無しさん:2008/04/12(土) 00:27:00
>>189
Ruby書きづらいし遅くて使い物にならないけど
192 :2008/04/12(土) 01:23:41
Scalaの日本語版Wikipediaには影響を受けた言語にRubyが入ってるけど、英語版にはない。
193デフォルトの名無しさん:2008/04/12(土) 01:48:56
>>192
それはひどいな
捏造かよ
194デフォルトの名無しさん:2008/04/12(土) 03:18:59
もうRubyはいいって。
内容のある比較もないし。
195デフォルトの名無しさん:2008/04/12(土) 08:57:01
>>191
負け惜しみ乙。どこがどう書きづらいんだよw
196デフォルトの名無しさん:2008/04/12(土) 12:30:55
てかscalaとrubyってユーザそんなに被らないと思うけどなあ
RoRとかが出てきてから流行に乗っかるような「現実的な」ユーザにとっては
今のscalaはまだ使う価値がないと思うし
197デフォルトの名無しさん:2008/04/12(土) 12:59:55
Ruby信者はRubyより優れている所があると言われる言語にでていく習性があってだな…
格下認定(HSP,PHP,LISP,VBあたり)されるか、信者(HaskellとかErlang?)が突撃してくるかくらいしか選択肢がない。
198デフォルトの名無しさん:2008/04/12(土) 16:37:37
>>195
うわぁ・・・Ruby信者いいかげんにしろ
199デフォルトの名無しさん:2008/04/12(土) 17:42:28
こたえられないんですね。

完膚なきまでに論破。
200デフォルトの名無しさん:2008/04/12(土) 17:47:39
信者なのかアンチの嫌がらせなのかの区別がつかない。
どちらにしてもScalaの絡まないRubyの話は
Ruby関連のスレかLLスレでやってほしい。
201デフォルトの名無しさん:2008/04/12(土) 21:26:20
Railsにブチ切れた外人がフレームワーク作った模様

InfoQ: David Pollak氏 lift と Scala を語る
http://www.infoq.com/jp/news/2008/03/liftweb
202デフォルトの名無しさん:2008/04/12(土) 22:17:14
>>189,191,198,199あたりはRubyを貶めようとする輩の自作自演の可能性が高い。
本当のRuby信者がRubyの心証が悪くなるような行動をするわけがない。
203デフォルトの名無しさん:2008/04/12(土) 22:23:48
まつもとゆきひろが率先してやってる件について
204デフォルトの名無しさん:2008/04/12(土) 22:25:39
>>202
>>195が抜けてるけど>>195ですか?
205デフォルトの名無しさん:2008/04/12(土) 22:29:16
すまん、訂正する。>>189,191,195,198,199あたりはRubyを貶めようとする輩の自作自演だろ。
206デフォルトの名無しさん:2008/04/12(土) 22:56:28
なんでもかんでもアンチのせいにしてごまかそうとしてるな酷すぎる
207デフォルトの名無しさん:2008/04/12(土) 23:21:34
>>202-206
>200
>どちらにしてもScalaの絡まないRubyの話は
>Ruby関連のスレかLLスレでやってほしい。

どうでもいいけどRubyスレのほうが盛りあがっててワロタ
良く釣れる連中だから遊んでもらえるんだな
208デフォルトの名無しさん:2008/04/12(土) 23:26:34
そんなことより2.7.1RC1が出てるぞ
バグフィックス中心だけど、簡単な正規表現ライブラリも追加されている
209デフォルトの名無しさん:2008/04/12(土) 23:30:28
正規表現だってー!!
210デフォルトの名無しさん:2008/04/13(日) 10:26:23
java.util.regex.*でいいじゃん...
211デフォルトの名無しさん:2008/04/13(日) 12:18:10
鬼車キボン
212デフォルトの名無しさん:2008/04/13(日) 13:23:47
またRuby厨が沸きそうなネタを…
213デフォルトの名無しさん:2008/04/13(日) 14:12:42
PEGの方がいいじゃん
214デフォルトの名無しさん:2008/04/13(日) 14:45:28
>>210
いや簡単なjava.util.regexのラッパー
215デフォルトの名無しさん:2008/04/13(日) 15:19:47
自前LL作るときにJVM利用する価値があるのは同意する。
しかしライブラリまでラッパでおk、ってのはいかがなものか。
たしかにJavaの豊富かつ実績のあるライブラリが使えるのはすげーメリットだが、
自前言語に合った、使いやすい物をもっと作れるはずだろ。インタフェース的な意味で。

藻前らが独自言語を設計してもJVMの命令列に落とすのと同じだ。
独自インタフェースのライブラリを設計して、標準ライブラリを利用しろよ。
Java標準パッケージ脳乙。

ということを繰り返し書いている漏れは……うー。
もしこれ以上雑多な拡張が必要になる将来が来るなら、それよかPEGにしたらいいと思う。 >regex
216デフォルトの名無しさん:2008/04/13(日) 16:23:42
なんだregexリテラルくらい作ってくれればいいのに
217デフォルトの名無しさん:2008/04/13(日) 17:42:33
>>216がフラグ立てた。(リテラルっぽい表記をライブラリで実現する的な意味で
218デフォルトの名無しさん:2008/04/13(日) 18:00:15
まあ、"abc".r で正規表現オブジェクトができるから短かくは書けるけど
219216:2008/04/13(日) 19:53:32
>>217
Scala触ったこともないんだけどだいぶ待ってもらっていい?
……と書こうとしたら>>218でオワタ
220デフォルトの名無しさん:2008/04/13(日) 20:12:23
/abc/と書けないのは中途半端だな。
221デフォルトの名無しさん:2008/04/14(月) 00:17:16
>>213
scalaにPEGライブラリってあったっけ?
222デフォルトの名無しさん:2008/04/14(月) 00:35:08
>>221
無いけど、Parser Combinatorがそれに近い
223デフォルトの名無しさん:2008/04/14(月) 07:24:37
PEGとParser Combinatorってどうちがうの
224デフォルトの名無しさん:2008/04/14(月) 16:41:54
>>218
いっそのこと、文字列から正規表現への暗黙の変換を定義するというのはどうだろう
以下のような感じで(2.7.1.RC1じゃないと動かないので注意)

import scala.util.matching.Regex
implicit def string2Regex(s :String) :Regex = new Regex(s)
for(r <- "[0-9]+" findAllIn "123 456 789") println(r)
225デフォルトの名無しさん:2008/04/14(月) 20:45:38
> 文字列から正規表現への暗黙の変換

実にPerlish……けど型が保証されるから問題無しか。すげ
226デフォルトの名無しさん:2008/04/14(月) 22:06:50
毎回やるのは嫌すぎるぞ。Emacsのようにキャッシュ利かせるとかしないと。
227デフォルトの名無しさん:2008/04/14(月) 22:09:35
個人的にはこのくらいで変換はしない方がいいと思うが
じゃあどういう基準で変換すべきかというのがわからんな
新技術はこういうところが困る
228デフォルトの名無しさん:2008/04/14(月) 22:17:09
キャッシュねえ…こんな感じ?

import scala.util.matching.Regex
import scala.collection.mutable.HashMap

object RegexConversion {
private val cache = new HashMap[String, Regex]
implicit def string2Regex(key :String) :Regex = {
cache.synchronized {
cache get key match {
case Some(regex) => regex
case None =>
val regex = new Regex(key)
cache(key) = regex
regex
}
}
}
}
import RegexConversion._
for(r <- "[0-9]+" findAllIn "123 456 789") println(r)
229デフォルトの名無しさん:2008/04/14(月) 22:18:34
>>227
まあ、自分で書いといてなんだが、俺もこういうケースで
implicit conversion使うのが良いかっていうのはちと疑問ではある
ただまあ、実害があまり無い使い方ではあると思う
230デフォルトの名無しさん:2008/04/15(火) 00:16:55
これはひどい
231デフォルトの名無しさん:2008/04/15(火) 01:06:52
>223
PEG: 文法の記法
Parser Combinator: パーザの実装方法の一つ(ちょっと違うけどそんなもん)
232デフォルトの名無しさん:2008/04/15(火) 07:34:18
パーザコンビネータつうのは文法とか文法解析のアルゴリズムとは独立してるもんなの?
233デフォルトの名無しさん:2008/04/15(火) 11:00:07
>>232
実際に使えるパーザコンビネータはほとんど再帰下降型(+バックトラック)だと思う
ただ、LRなどのボトムアップ型も作れないことは無い、はず
234デフォルトの名無しさん:2008/04/17(木) 23:59:23
ScalaってWindowsでまともなプログラム書けますか?
サーバーサイドじゃなくって
Scala.netって止まってるような気がするけど・・・
235デフォルトの名無しさん:2008/04/18(金) 00:04:09
うぜぇ。文句があるならRubyでも使ってろ。
236デフォルトの名無しさん:2008/04/18(金) 00:19:33
WindowsユーザはScala使うな
237デフォルトの名無しさん:2008/04/18(金) 00:23:10
知的水準の低い人はScalaを使わなくて結構です
238デフォルトの名無しさん:2008/04/18(金) 00:34:56
なんだ。関数型言語ってやっぱり学者しか使わないか・・・
239デフォルトの名無しさん:2008/04/18(金) 00:51:52
ごめん、嘘です。気を悪くしたらスマソ。

「自分がやられて嫌なことは、他人にしたらいけない」って死んだ猫いってたのを思い出した・・・
240デフォルトの名無しさん:2008/04/18(金) 14:23:55
何この流れw
241デフォルトの名無しさん:2008/04/18(金) 19:13:35
>>234
ScalaでWindowsのGUIプログラム書けるかって話なら
Swing/AWT使うか、SWT使うくらいしか選択肢は無いんじゃない?
242デフォルトの名無しさん:2008/04/18(金) 19:26:24
「まとも」=「GUI」!
243デフォルトの名無しさん:2008/04/18(金) 19:55:27
>>241
.NET対応がちゃんとしてくれるんなら、それでいいっす^^
244デフォルトの名無しさん:2008/04/18(金) 20:04:12
>>242
234の文章から、234の考える「Windowsのまともなプログラム」を推測すると、
俺もそうなる。
245デフォルトの名無しさん:2008/04/18(金) 20:18:19
>>242
>>244の書いてる通り、234の文章から、234が考える「Windowsのまともなプログラム」
=GUIプログラムのことと推測したまで。俺自身が「Windowsのまともなプログラム」=
GUIプログラムのことだと考えてるわけじゃない
246デフォルトの名無しさん:2008/04/18(金) 20:27:57
SWT使えば見栄えも問題ないよ
247デフォルトの名無しさん:2008/04/19(土) 09:26:39
あんな低レベルのGUIに満足してるの?
248デフォルトの名無しさん:2008/04/19(土) 09:44:53
俺はGUI全く使わない。
249デフォルトの名無しさん:2008/04/19(土) 10:36:08
GUIも使えるけどあえて使わないってこと?今だにキャラクタベースのUIのほうが玄人っぽいとか、そんな発想?
あなたのような人には文字ベースで十分なのかもしれないけれど、一般的な用途にはGUIが必要とされる時代なんです。いい加減わかってください。
250デフォルトの名無しさん:2008/04/19(土) 10:59:27
お前のことはお前が決めろ。
251デフォルトの名無しさん:2008/04/19(土) 11:10:36
>>247
世の中はOSと違うインターフェースは敬遠されるらしい
252デフォルトの名無しさん:2008/04/19(土) 11:13:56
必要なものを自分で作る能力のないプログラマが飛び付く言語じゃない。
253デフォルトの名無しさん:2008/04/19(土) 12:20:38
>>242>>244
おそらく、>>234=>>243なので、さらにその内容を合わせると
>>234の考えるまともなプログラム
 =「.NET Framework を使ったGUIプログラム」
というように読める。
254デフォルトの名無しさん:2008/04/20(日) 17:51:36
どちらかというと言語がプログラマの要求についてこれれてない部分があるっつーことでしょ。
その辺を他言語と比較されるとすぐファビョりはじめる奴がいるのが困りものだね。
255デフォルトの名無しさん:2008/04/20(日) 21:28:40
.NET対応ってそんなに要求あるのかな?
Java VMで十分な気がするけど
256デフォルトの名無しさん:2008/04/22(火) 21:33:18
257デフォルトの名無しさん:2008/04/23(水) 00:55:30
Emacsにも補完つけてほしい
258デフォルトの名無しさん:2008/04/23(水) 01:33:45
Stream.const がはじかれるんですが、これっていつからの関数ですか?
259デフォルトの名無しさん:2008/04/23(水) 01:54:41
Stream.consのことか?
260デフォルトの名無しさん:2008/04/24(木) 02:41:40
>>259
いや。実際にStream.constというメソッドがある。
たとえば、Stream.const(1)とすると、1のみを含む無限Streamが生成できる。
261デフォルトの名無しさん:2008/04/27(日) 11:00:01
ふと聞きたいのですが、Scala以外にどんな言語に興味ありますか?

Scalaを使ってらっしゃる方が普段どんな言語つかっているのか知りたいです。
262デフォルトの名無しさん:2008/04/27(日) 11:42:13
JavaとRuby
263デフォルトの名無しさん:2008/04/27(日) 12:39:15
JavaとRubyかな。最近はErlangに手を出し始めてる
264デフォルトの名無しさん:2008/04/29(火) 15:46:25
>>193
small talkも知らない馬鹿が書いているんだろwww
無視しろ。
265デフォルトの名無しさん:2008/04/29(火) 20:12:31
ScalaはRubyの影響をうけているよ。
266デフォルトの名無しさん:2008/04/29(火) 21:23:18
>>265
まあ、受けてる可能性は否定できないけど、明らかに影響を受けてる
という程じゃないなあ。Groovyくらいそっくりだったら、話は別だけど。
267デフォルトの名無しさん:2008/04/30(水) 02:42:57
>>264
他人を罵る前にだ。

Smalltalkを区切るな、ボケw
268デフォルトの名無しさん:2008/04/30(水) 22:17:30
>>264
くだらない釣りはヤメロよ
269デフォルトの名無しさん:2008/04/30(水) 23:05:54
JJUG Cross Community Conference の Scala のセッション、えらい盛況でワロタ:-)
270デフォルトの名無しさん:2008/04/30(水) 23:14:43
271デフォルトの名無しさん:2008/05/04(日) 19:50:05
既出かもしれんけどscalaの動画が紹介されてた。
関数型言語mlのすれ
272デフォルトの名無しさん:2008/05/06(火) 16:48:05
273デフォルトの名無しさん:2008/05/07(水) 19:49:29
>>271
Scalaの動画ってこれか

http://www.youtube.com/watch?v=SCl0pkrQn1A
274デフォルトの名無しさん:2008/05/09(金) 23:39:00
>>271
ニコニコ動画で見つけました。
関数型言語Scalaの動画もう一つ
http://www.nicovideo.jp/watch/sm2902315
275デフォルトの名無しさん:2008/05/10(土) 14:28:21
>>274
>>1乙wwww
276デフォルトの名無しさん:2008/05/10(土) 14:33:51
>>1 なのかwww
277デフォルトの名無しさん:2008/05/10(土) 14:34:18
Rubyの人とけんかしてるので仲良くして欲しいwww
278 :2008/05/10(土) 18:50:55
記法が柔軟性あるみたいだけど、そのためIDEのインテリセンスつくるの大変そうだね。
EclipseのJavaエディタ並みの賢い開発環境があればJavaから乗り換えたいけど。
279デフォルトの名無しさん:2008/05/10(土) 20:20:11
>>274
「スレを立てる」クソワロタ
その結果がこのスレかwww
280デフォルトの名無しさん:2008/05/11(日) 03:07:41
emacsで充分
281デフォルトの名無しさん:2008/05/11(日) 12:09:33
>>278
開発中のEclipse用プラグインが割と頑張ってる感じ
282 :2008/05/12(月) 07:55:41
>>281
そうなのか、使ってみる。
283デフォルトの名無しさん:2008/05/12(月) 13:55:30
Eclipse で実行のたびに Run Configuration が増殖するのは仕様ですか?
284 :2008/05/14(水) 04:39:03
Scalaって文の区切りに;が必要ないの?
なんか怖いです。
285デフォルトの名無しさん:2008/05/15(木) 14:44:24
誰でもはじめては怖いもんだ
286デフォルトの名無しさん:2008/05/15(木) 21:35:10
>>284
関数型言語などでは ; が必要ない方が普通。
HaskellやOCamlなんかでも;は必要ない。
287デフォルトの名無しさん:2008/05/15(木) 21:49:16
ありますよ。
288デフォルトの名無しさん:2008/05/15(木) 23:52:14
必要だけど必要じゃない。
289デフォルトの名無しさん:2008/05/16(金) 03:05:20
Lispだとセミコロンはコメントアウトだな。
290デフォルトの名無しさん:2008/05/17(土) 08:43:04
JavaとRubyとScalaの比較
http://codezine.jp/a/article/aid/2464.aspx
291デフォルトの名無しさん:2008/05/17(土) 15:35:15
Scalaの文法でDみたいなネイティブコンパイラって作れないかな。
292デフォルトの名無しさん:2008/05/17(土) 18:38:06
単にネイティブバイナリがほしいだけだったらgcjであれこれ挑戦してみたら委員では
293デフォルトの名無しさん:2008/05/20(火) 10:25:32
inforno :: Scalaでスタック指向言語をサクッと実装する
http://inforno.net/articles/2008/05/17/simple-stack-oriented-language-implemented-using-scala
294デフォルトの名無しさん:2008/05/21(水) 23:03:40
scalaって遅延評価あるんだな。
最初からそれ言ってくれたら切り捨てたりしなかったのに。
295デフォルトの名無しさん:2008/05/21(水) 23:11:11
お前の方が切り捨てられたんだよ。
296デフォルトの名無しさん:2008/05/22(木) 18:11:38
煽られたら乗るよ?
scalaに意志はないから切り捨てるも切り捨てないも人の意志にゆだねられる。
scalaと人を混同しないでくださいね。
それとも、scalaたんとかいって擬人化してるキモオタくんですか?
297デフォルトの名無しさん:2008/05/22(木) 20:11:14
scalaたんの擬人化マダー?
298デフォルトの名無しさん:2008/05/23(金) 05:02:26
>>296
君、さぞ国語の成績が悪かったろうな。
299デフォルトの名無しさん:2008/05/23(金) 05:38:47
>>296
乗るにしてもその乗り方はないだろ。
>scalaに意志はないから切り捨てるも切り捨てないも人の意志にゆだねられる。
って、どんな返しだよ。

というか、返しにすらなってないか・・・。
300デフォルトの名無しさん:2008/05/23(金) 05:48:16
>>296
煽られたら乗るよ?
> scalaに意志はない(後略)
まず、議論の前に、どのような哲学的立場をもとにしているのかをハッキリしてもらおうか。
301デフォルトの名無しさん:2008/05/23(金) 05:48:24
>>296
scalaにはMartin Oderskyの意思が宿っている

と返して欲しかったんですね。
わかります。
302デフォルトの名無しさん:2008/05/23(金) 05:54:40
キモオタとか言って煽ってる本人が
なんか凄くオタクに詳しいっぽいのがたまらんね

沸いた頭で煽りを書き殴ったら、自分が普段言われてるモノが出てきました、みたいな
303デフォルトの名無しさん:2008/05/23(金) 07:50:20
どんな言い方してみても>>294が付いて行けなかった事にかわりはない。
304デフォルトの名無しさん:2008/05/23(金) 08:44:58
>>294の書いたscalaたんが観たかった…
305デフォルトの名無しさん:2008/05/23(金) 09:27:29
codezineのメルマガのタイトルに scala が出てきて吹いた

◆【Web】私がScalaを選んだ理由
最近自分の中でScalaという言語が熱い。RubyやPython等のスクリプト言語や、
JavaやC#等現在のエンタープライズ領域を支える言語、HaskellやErlangといった
関数型言語もある。そんなにいっぱいいい言語がある中で,なぜ今Scala
なんだろう?そんな理由を解説してみたいと思います。
http://codezine.jp/a/article/aid/2464.aspx
306デフォルトの名無しさん:2008/05/23(金) 11:33:17
>>303
scalaを一見したらどう見えるかというと、
・JAVAのクラスファイルはくの?つまり所詮はJAVAの亜種ってこと?JAVAにはウンザリなんだよなぁ
・クラス?なんだ、またオブジェクト指向言語か。ツマンネ。
・アルジェブライックデータタイプなし?キモ。おいおい、どこが関数型言語だよ。
・しかも見た目は完全手続き型言語っぽい。

遅延評価以外これといった特徴無いですよね。
307デフォルトの名無しさん:2008/05/23(金) 17:23:39
>>306

英語docの読めない香具師はScalaに手を出すなw
308デフォルトの名無しさん:2008/05/23(金) 17:35:11
>>307
既存のプログラミング言語が多すぎて新しい言語が出てきても大して興味もでないのに、
ドキュメントまで見ようと思うわけがないだろ?w
ブログを見ていて、たまたま言語の紹介があったら読む程度。
言語に興味を持つか持たないかが決まるのはせいぜい5分程度だ。
まぁ、言語の特徴を説明しきれていない糞ブロガーが全部悪いわけだがwww
309デフォルトの名無しさん:2008/05/23(金) 17:39:56
そうやってすぐ雑草を生やす
310デフォルトの名無しさん:2008/05/23(金) 17:58:10
まぁ、小物アプリ作者の俺としてはネイティブ吐いてくれない時点でアウト
311デフォルトの名無しさん:2008/05/23(金) 18:04:47
遅延評価以外これといった特徴無い言語に興味を抱いて、ここに来たの?
312デフォルトの名無しさん:2008/05/23(金) 18:06:31
>>311
遅延評価が実装されている言語を挙げてみろ。
思いつく限りでは片手に収まる。
313デフォルトの名無しさん:2008/05/23(金) 20:16:42
>>312
Haskell
Scala
Clean
UnLambda
314デフォルトの名無しさん:2008/05/23(金) 21:21:34
>・JAVAのクラスファイルはくの?つまり所詮はJAVAの亜種ってこと?JAVAにはウンザリなんだよなぁ
>・クラス?なんだ、またオブジェクト指向言語か。ツマンネ。
さすがにこの釣り餌は、おいしそうじゃないな。
315デフォルトの名無しさん:2008/05/23(金) 21:27:18
じゃあ食いつくなよw
316デフォルトの名無しさん:2008/05/23(金) 21:29:16
ごめw
317デフォルトの名無しさん:2008/05/24(土) 01:10:13
自分が食いついた餌の低質さをいくら口にしたところで、相手のレベルじゃなく
「そんなのに食いついた自分のレベル」の低さをアピールするだけなのにね(相手には1ポイント入る)。
318デフォルトの名無しさん:2008/05/24(土) 01:17:48
ごめん、わるかったって
319デフォルトの名無しさん:2008/05/24(土) 01:45:38
>>312
OCaml
pypy
320デフォルトの名無しさん:2008/05/24(土) 03:59:21
>>306
頭悪そうだね
321デフォルトの名無しさん:2008/05/24(土) 04:00:25
>>312
> 思いつく限りでは片手に収まる。

なんて無知な…
322デフォルトの名無しさん:2008/05/24(土) 12:58:25
なんだここの奴ら・・・
まだHaskellスレの方が「できた」人間が多いぞ・・・
323デフォルトの名無しさん:2008/05/24(土) 12:59:02
スレ住人の人間性を見てもわかる。
この言語はJavaの系列なんだな。
324デフォルトの名無しさん:2008/05/24(土) 14:11:12
Javaじゃないのが最大の利点。
325デフォルトの名無しさん:2008/05/24(土) 15:03:27
JVMに縛られたローカル言語
326デフォルトの名無しさん:2008/05/24(土) 15:08:52
>>322-324
Haskellの名前だけ挙げてPD.Martin Oderskyに直接何も言えないのって恥ずかしいよな
327デフォルトの名無しさん:2008/05/24(土) 15:09:00
もうJVMを次期windowsに埋め込めばいいんじゃね?
328デフォルトの名無しさん:2008/05/24(土) 15:11:55
>>326
俺はscalaのこと何もしらねーもん^^
俺が批判してるのが言語scalaだと思っていたら大間違いだぜ。
お前らを含めたコミュニティと広報活動全般についてなんだよ。
「外」の人間がどう感じるか感想を言ったまでさ。
お前ら被害妄想ひどすぎwww
329デフォルトの名無しさん:2008/05/24(土) 15:25:30
>>328
> 俺はscalaのこと何もしらねーもん^^
( ´,_ゝ`)プッ
330デフォルトの名無しさん:2008/05/24(土) 15:42:11
>>329
頭の可哀想な子に触るの禁止ーーー!!
331デフォルトの名無しさん:2008/05/24(土) 15:46:29
俺が思うに、コミュニティが健全であるためには、Javaとのつながりを完全に切った方がいいと思うんですよ。
>>329-330のような奴らをJavaに隔離すべきだと思うんです。
332デフォルトの名無しさん:2008/05/24(土) 15:47:06
っていうかさ、数学出来ないやつが関数型言語さわるなよ^^^
333デフォルトの名無しさん:2008/05/24(土) 15:47:46
「このマスにとまったら、ム板のScalaスレを荒らしてくる」
とかいうゲームなんだよ。
334デフォルトの名無しさん:2008/05/24(土) 15:49:36
>>328
> お前らを含めたコミュニティ

2chをコミュニティ認定しないでくれ
335デフォルトの名無しさん:2008/05/24(土) 16:49:54
>>334
馬鹿にそんなこと言っても始まらないだろ。
336デフォルトの名無しさん:2008/05/24(土) 16:57:08
>>334
妄想がどうのと言い出す人が、むしろ自分こそ激しい妄想を前提としているのはよくある話。
つまり、自分が言われると致命的な指摘を、先に相手になすりつけておく手法。
337デフォルトの名無しさん:2008/05/24(土) 17:01:32
自己投影化ですねわかります
338デフォルトの名無しさん:2008/05/24(土) 18:38:40
>>328
人間やコミニティまで批判するのはやめような。
フレームにしかならないよ
339デフォルトの名無しさん:2008/05/24(土) 18:53:07
>>338
ああ悪かったな。
「活動」を批判すべきだったなw
340デフォルトの名無しさん:2008/05/25(日) 04:52:14
もう引くに引けなくなってるのねw
341デフォルトの名無しさん:2008/05/25(日) 06:57:59
>>332
関数型さわって慣れてから、数学勉強するのでいいと思う。
342デフォルトの名無しさん:2008/05/25(日) 22:50:07
興味持てないのにいちいち荒らしにくる>ツンデレ
343デフォルトの名無しさん:2008/05/26(月) 02:18:42
というか、このところのScalaの取り上げられ方を見て
「なんか落ち着かない気分になった」Ruby信者では。
344デフォルトの名無しさん:2008/05/26(月) 06:35:01
序盤に遅延評価を連呼していたあたり、遅延評価で切り捨ての子じゃないのか?
345デフォルトの名無しさん:2008/05/26(月) 18:19:49
C#並にIDEの支援が充実してくれるといいんだが・・・・

;が省略可なんて仕様はIDEにとって厄介者にならないのだろうか?
346デフォルトの名無しさん:2008/05/26(月) 21:27:38
;を書かなくていい言語が変に思うヤツは、プログラミング言語知らなさすぎ。
他の言語も知っといた方がいい。勉強しろ。
347デフォルトの名無しさん:2008/05/26(月) 21:42:27
勉強の問題じゃないが。
348デフォルトの名無しさん:2008/05/26(月) 21:49:59
アホが勉強しろとか言ってるの見ると滑稽でたまらん
349デフォルトの名無しさん:2008/05/26(月) 21:50:08
そういや、VBのインテリセンスは完璧だったな
350デフォルトの名無しさん:2008/05/26(月) 22:11:23
Haskell知ってるヤツと、Javaしか知らないヤツのコードを見ると、同じScalaでも全然違う。
あたりまえだが。
351デフォルトの名無しさん:2008/05/27(火) 20:28:26
荒れてるなあ
とりあえず、Algebraic data type相当の機能はScalaにもあるよ
あと、Scalaの特徴と言ったらやっぱりimplicit conversion/parameterとか
Extractorとかじゃないかと個人的には思う
352デフォルトの名無しさん:2008/05/27(火) 20:29:35
>>345
Visual StudioとかEclipse並にはまだ程遠いけど、Scalaで書き直された
新Scala Eclipse Pluginは結構補完頑張ってるよ。implicit conversionで
追加されたメソッドとかも補完してくれる。
353デフォルトの名無しさん:2008/05/27(火) 20:48:15
>>343言い得て妙だな。まさにそんなのが身近にいるのでツボった。
354デフォルトの名無しさん:2008/05/27(火) 22:15:41
またいつもの浮気癖か>Ruby信者
浮気するくせに浮気相手にRubyを求めるからなあ。
355デフォルトの名無しさん:2008/05/27(火) 22:27:06
;と{ばかりの言語しかやったことない俺涙目
そんな人は何からやればいいですか?やっぱりHASKELLとかですか?
356デフォルトの名無しさん:2008/05/27(火) 23:15:50
あと、SmalltalkとSchemeかな。
357デフォルトの名無しさん:2008/05/27(火) 23:20:30
>>354信者のふりしたアンチに騙されてるんだよ。Rubyistは向上心のある人格者が多い。
358デフォルトの名無しさん:2008/05/27(火) 23:42:38
間を取って、Ruby信者とRubyistは違うということでこの話はお開き。
359デフォルトの名無しさん:2008/06/02(月) 18:18:44
>355
ここは forth で
360デフォルトの名無しさん:2008/06/10(火) 10:17:32
本家ホムペ落ちてる!><;

・・・

大幅リニューアルということか?
361デフォルトの名無しさん:2008/06/10(火) 20:53:23
>>360
いつまで落ちてたのか知らんが、もう復旧してるよ
Webページのデザインは以前と特に変化無し
362デフォルトの名無しさん:2008/06/10(火) 21:15:06
1つだけ、def という適当な予約語が気に入らない
363デフォルトの名無しさん:2008/06/11(水) 01:07:42
じゃあdefunで…
364デフォルトの名無しさん:2008/06/11(水) 02:02:47
>>362
じゃあ、defineだったら良かった?予約語って特に頻繁に
使用するものは、省略形を使ってでも短くした方が良いと思う
どうせ予約語の数なんて知れてるし、覚えることの労力よりも、
短くすることのメリットの方が大きいと思う
365デフォルトの名無しさん:2008/06/11(水) 02:05:03
あと、defって予約語自体は結構メジャーなものだと思う。俺が知ってる言語では
Ruby,Python,Groovy,Scala,Nemerle,が採用してるな。Nemerleはかなりマイナーだと
思うが
366デフォルトの名無しさん:2008/06/12(木) 00:27:39
クラスの宣言がclassなんだから、
メソッドの宣言はmethodでいいじゃん。
367デフォルトの名無しさん:2008/06/12(木) 03:41:56
def か fun がいいな
368デフォルトの名無しさん:2008/06/13(金) 20:31:18
ユニットテストフレームワークは何を使っていますか?

JUnit、TestNG、SUnit、ScalaTest、と色々な選択肢があるので迷っています。
369デフォルトの名無しさん:2008/06/15(日) 09:50:53
def, fun は飽きた。df, fn とかしてほしい。
370デフォルトの名無しさん:2008/06/15(日) 10:54:52
ディスク残量の表示をファンクションキーに割り当てたいんですね。わかります。
371デフォルトの名無しさん:2008/06/15(日) 10:58:37
Scala の関数プログラミングが理解できません。

ScalaTutorial.pdf を読んでみました。Martin Odersky は scala で OOP
language と functional programming を統合して compose program を目指
していると理解しています。

でも tunctional programming は状態を持たないこと、変更できるデータが
存在しないことが特徴です。関数呼び出しに side effect がないことが特徴
です。 Python は、既存の関数に side effect があることから本格的な
functinal programming には踏み込もうとしません。Scala では関数の
side effect をどうやって防いでいるのでしょうか?

私には Scala の関数プログラミングは side effect を許しているとしか思
えません。もしそうだとすると、scala の関数プログラミングは偽関数プロ
グラミングだとも言えると思います。
372デフォルトの名無しさん:2008/06/15(日) 11:07:44
tunctional programmingと言われても…

Scalaは関数型言語じゃないよ。
373デフォルトの名無しさん:2008/06/15(日) 11:34:45
機能として見た場合、参照透明自体はそんなに重要じゃないでしょ
並列処理とか遅延評価のときに都合がいいだけで
それに純粋な関数型言語っていわゆる関数型言語の中でも一部分であって
純粋じゃなかったら偽というのも極端な気がするけど
374デフォルトの名無しさん:2008/06/15(日) 13:27:32
371 です。

>純粋じゃなかったら偽というのも極端な気がするけど
同意します。

でも、side effect 使いまくりの pattern match: match .. case ... を書
いていたら、それは偽関数プログラミングと言っても良いでしょう。そして
scala は、それを許しているように思えます。Stateless, immutable にす
るのはユーザーの努力に委ねられているように思えます。違いますでしょう
か。
375デフォルトの名無しさん:2008/06/15(日) 13:59:00
それはプログラミングスタイルの話で、言語がどうかって話とはちょっと違う気がする。
376デフォルトの名無しさん:2008/06/15(日) 13:59:56
ん?よくわからん
パターンマッチと副作用がどう関係してるんだ?
377デフォルトの名無しさん:2008/06/15(日) 14:16:17
>>374
>それは偽関数プログラミングと言っても良いでしょう。

誰にも会わずに一人で呼ぶ分には別に良いんじゃない?

>Stateless, immutable にするのはユーザーの努力に委ねられているように思えます。

という言語は別にScalaが最初という訳じゃないというか歴史に何度も登場したものに思われ。

ttp://user.ecc.u-tokyo.ac.jp/~tt076524/onlispjhtml/functionalProgramming.html

>関数的プログラミングとは,副作用ではなく,値を返すことで動作するプログラムを書くことだ.
>副作用とはオブジェクトの破壊的な変更(rplacaの使用等)や変数への代入(setqの使用等)を含む.
>副作用を使う数が少なく,その影響範囲もローカルなものであれば,
>プログラムの読み取り,テスト,デバッグは簡単になる.
>Lispのプログラムが必ずこの方法で書かれてきた訳ではないが,
>時を追ってLispと関数的プログラミングは次第に分かち難いものになってきた.
378デフォルトの名無しさん:2008/06/15(日) 14:20:10
371 です
>パターンマッチと副作用がどう関係してるんだ?

Pattern match は functional programming の機能だと思います。ここで書
かれるコードは副作用のないものに限定されるべきだと思います。クラス・
データ・メンバーを設けて、それを操作するなんてしてはならないと思いま
す。そうでなかったら、compose program なんて実現できないでしょう。
379デフォルトの名無しさん:2008/06/15(日) 14:22:31
>>378
> Pattern match は functional programming の機能だと思います

なこたーない
380デフォルトの名無しさん:2008/06/15(日) 14:22:50
>>378
マッチングのときに副作用が起きるのがいけないということ?
それともマッチングの後の話?
compose programというのもよくわからんな
381デフォルトの名無しさん:2008/06/15(日) 14:24:26
>>379
パターンマッチって関数型由来じゃないんだっけ?
382デフォルトの名無しさん:2008/06/15(日) 14:28:51
>>378
要するにMartin Oderskyの謳い文句が煽りっぽくて気に入らないなら本人に言った方が良いよ。

副作用なしでプログラミングを行うという意味論的なテーマと、
単なるシンタックス(Pattern match)の議論がごっちゃになってる気がする。
「条件分岐の意味論」と「条件分岐が楽に書けるか」は全然別の話。

意味論の定義については偉い人に任せる。
ttp://d.hatena.ne.jp/soutaro/20080530/1212163155
383デフォルトの名無しさん:2008/06/15(日) 14:35:32
>>369
そこで defun ですよ。Lisp 的に。
384デフォルトの名無しさん:2008/06/15(日) 14:50:53
join計算では破壊的変数操作は許されるのですか?
385デフォルトの名無しさん:2008/06/15(日) 15:09:24
>>381
由来は知らんがPrologとかにもあるだろ
だいたいパターンマッチングで副作用を否定したらawkの立場はどうなるんだよw
386デフォルトの名無しさん:2008/06/15(日) 15:15:20
371 です

>マッチングのときに副作用が起きるのがいけないということ?
>それともマッチングの後の話?
cast ... ==> の後に書かれるコードで副作用があるものを呼び出さないの意味です。

>compose programというのもよくわからんな
下の Martin Odersky 自身の説明から持ってきました。彼はプログラムの部
品化を本気で可能にしようとしています。
http://video.google.com/videoplay?docid=553859542692229789
http://lampwww.epfl.ch/~odersky/talks/google06.pdf

>パターンマッチって関数型由来じゃないんだっけ?
関数型由来由来でしょう。switch case 文で置き換えられる代物ではないでしょう。
387デフォルトの名無しさん:2008/06/15(日) 15:24:02
Pattern match は functional programming の機能

Pattern match は functional programming に由来
は別物だぞ
関数型言語以外でもパターンマッチングが見られるから前者は間違い
wikipediaによるとKen Thompson(Unixの作者)が作ったエディタや
SNOBOLが由来だから後者も間違い
388デフォルトの名無しさん:2008/06/15(日) 16:01:39
なんちゃって知識を抱えて、新規言語に刃向かいに来たボクちゃんってことで決着ですか?
389デフォルトの名無しさん:2008/06/15(日) 16:24:50
>381
『由来』と『機能』は別物。
Lispみたいにパターンマッチ前提にしていない関数型言語は普通にあるよ。
逆にC++のオーバーロードとかだって一種のパターンマッチだし。

>378
そんなつまらん理由で『べき』なんて断定するもんじゃないよ。

・Pattern Matchに失敗したときの挙動が複雑すぎて制御不能
・追加したパターンマッチの影響が他の関数に波及するリスクがある。
  状態の管理が困難になる
とか具体的な理由ぐらい書いたら?

状態(副作用)の本質についてはガウディ本が詳しいので、一回読んでみたら。
390デフォルトの名無しさん:2008/06/15(日) 16:24:56
>>386
だったら、通常のifとパターンマッチを区別して、パターンマッチを特別視する理由は?
パターンマッチって便利なifみたいなもんだと思っているんだけど
391デフォルトの名無しさん:2008/06/15(日) 16:50:12
なんか不毛な議論になっとるなー
>>374の言っているのに合致するのって、HaskellとCleanくらいじゃね?
あと、パターンマッチについては強力なif文という認識くらいで良いと思うなー
392デフォルトの名無しさん:2008/06/15(日) 18:18:32
パターンマッチ>判定にパターンのみ使用可>判定に副作用無し

Scalaのクラスフィールドは暗黙のゲッタ・セッタ呼び出し>
ゲッタ・セッタの明示定義でもフィールド名のみで呼び出し>
意図せざる副作用はそれらで相殺可
393デフォルトの名無しさん:2008/06/15(日) 19:56:33
OCamlだとパターンマッチ使って、
let (x,y) = mouse_point in
 printf "%dだお, %dだお" x y

とかできるけど、scalaだとどんななんだろ。
394デフォルトの名無しさん:2008/06/15(日) 20:01:40
scala> val (a, b) = (1, 2)
a: Int = 1
b: Int = 2

こんなのなら動くよ
395デフォルトの名無しさん:2008/06/16(月) 00:39:39
Tuple以外でも使えるけど、なんか違和感があるな

case class TypeA(val a:Int,val b:Int)

val TypeA(a,b)=TypeA(10,20)

println(a)
println(b)
396デフォルトの名無しさん:2008/06/16(月) 01:48:47
>>395
違和感あるってのは単にパターンマッチ自体に慣れていないという
事じゃないかなあ。Scalaに限らず、SML,OCaml,Haskellなどでも同様の
事はできるわけだし
397デフォルトの名無しさん:2008/06/16(月) 02:36:04
ちなみに1行目caseつけるならvalは要らない。
398デフォルトの名無しさん:2008/06/16(月) 03:02:29
case関係なくval要らなくね?
399デフォルトの名無しさん:2008/06/16(月) 10:28:28
>>398
いや、要るでしょ。case classにしなきゃパターンマッチの
対象にできない。もちろん、別途unapply定義したobjectを
定義すれば別だけど
400デフォルトの名無しさん:2008/06/16(月) 10:50:05
あ、ごめん、意図を取り違えていた。case classじゃなきゃ、そもそも
valのあるなしに関わらずパターンマッチできないわけで、確かに
必要ないわな。
401デフォルトの名無しさん:2008/06/16(月) 11:37:31
細かいことだが、unapplySeqでもおk

val s = "([0-9]*)(.*)".r

val s(x,y) = "123いちにさん"

println(x) // 123
println(y) // いちにさん
402デフォルトの名無しさん:2008/06/16(月) 20:00:45
case classでは暗黙にvalだが、case以外でもvalやvarで
コンストラクタ引数もメンバ化できるのだだだだだだ
403デフォルトの名無しさん:2008/06/18(水) 03:44:07
Javaでは

String.class

のように書くと、対象のクラスのインスタンスを作成せずに
Class型のオブジェクトを取得することができますが、
scalaで同様のことをするにはどのように書けばよいのでしょうか?
404デフォルトの名無しさん:2008/06/18(水) 04:35:06
つ type
405デフォルトの名無しさん:2008/06/18(水) 05:15:02
つ classOf[String]
406デフォルトの名無しさん:2008/06/18(水) 06:13:01
>>405
ありがとうございます。探していたのは正にこれでした。

>>404
type a = b で型の別名が作れるんですね。
今回探していたものとは違いましたが、参考になりました。
407デフォルトの名無しさん:2008/06/19(木) 12:55:22
def getFunc(fun:Option[String => _ <: AnyRef]) = {
fun match {
case None => null
case Some(f) => (i:String) => f(i).notify()
}
}

上記のコードをコンパイルすると notify() の部分でエラーになりました。

fがStringを引数に取る関数であるというところまでは推論できているのに、
fの戻り値がAnyRefを継承した型である事を推論できないのはなぜなのでしょうか?
408デフォルトの名無しさん:2008/06/19(木) 16:08:45
Existential Type周りの推論の仕組みは正直よくわかっていないので
確定的な事は言えないのですが、推論できていないというより、どうもバグな気がします
たとえば、上記のコードを

def getFunc(fun:Option[String => _ <: AnyRef]) = {
fun match {
case None => null
case Some(f) => (i:String) =>
val a: AnyRef = f(i); a.notify()
}
}

とすると、コンパイルが通ることから、少なくともf(i)の返り値が
AnyRefのサブタイプであることは(コンパイラによって)認識されている
ように見えます。色々試してみたところ、以下のようなコードの場合

val fun: Option[String => _ <: AnyRef] = Some((s: String) => s)
val Some(f) = fun

コンパイラが
error: fatal error: bad type: ?(class scala.tools.nsc.symtab.Types$WildcardType$)
というメッセージを吐いて落ちるようです。この辺の事から推測すると、
Existential Typeとパターンマッチを組み合わせたときのバグのような気がしますが、
本当のところはわからないので、本家ScalaのMLで聞いてみるのが良い気がします
409デフォルトの名無しさん:2008/06/19(木) 16:10:42
回避策ですが、Function Typeは、返り値についてcovariant
annotationが付加されているので、わざわざExistential Typeを使わずに、単純に

def getFunc(fun:Option[String => AnyRef]) = {
fun match {
case None => null
case Some(f) => (i:String) => f(i).notify()
}
}

とすれば良いです。これで、ちゃんと
getFunc(Some((s: String) => s))
などのコードをコンパイルできます
410デフォルトの名無しさん:2008/06/19(木) 23:16:10
>>408-409
いろいろと試して頂き、ありがとうございました。
Existential Typeを使わないようにすることで、無事、動くようになりました。

英語は苦手なのですが、
そのうち、本家ScalaのMLでの質問にも挑戦してみようと思います。
411デフォルトの名無しさん:2008/07/09(水) 08:47:29
ScalaのEclipsePluginは、Eclipseのどのバージョンで動きますか?
412デフォルトの名無しさん:2008/07/09(水) 23:33:30
413デフォルトの名無しさん:2008/07/31(木) 19:30:46
プログラミングしりとり
http://game14.2ch.net/test/read.cgi/575/1010948472/l50
414デフォルトの名無しさん:2008/08/21(木) 01:19:30
Webサイトが変わった
415デフォルトの名無しさん:2008/08/21(木) 09:21:03
Renewal ですな
NetBeans 用プラグインも追加されてる > ヘルプも含めて IDE 本体のオール
日本語化は NetBeans の方がダンゼン速いので日本人にとっては良い知ら
せか
ただし 6.5 以上だけど (現在日本語はまだ GUI のみか日本語開発版のみ)
416デフォルトの名無しさん:2008/08/22(金) 02:27:02
Scala本5月には出版っていってたのにまだプレプリントか。
417デフォルトの名無しさん:2008/08/22(金) 14:10:17
Scala本待てない人は、単なる個条的抜き書き程度のしろものですが
それまではこちらをどーぞ
ttp://www.h7.dion.ne.jp/%7Esamwyn/Scala/scalaindex.htm
418デフォルトの名無しさん:2008/08/22(金) 15:00:49
うはw こういうのうれしい。
英語のリファレンス読むのメンドくさくて、いまいちちゃんと理解できてなかったんで、
すげーうれしい。
419デフォルトの名無しさん:2008/08/22(金) 21:31:43
>>417
これ、ただの機械翻訳じゃないの?
420デフォルトの名無しさん:2008/08/22(金) 21:51:13
>>416
http://www.artima.com/shop/programming_in_scala
そろそろ出るんじゃないの?
421デフォルトの名無しさん:2008/08/22(金) 21:51:42
機械翻訳はこういう文章を吐かないと思う
なんていうか、プログラマというよりは人文系の方が書いたような文章
422417:2008/08/22(金) 23:32:47
プログラマ向け、でなくJavaとJavaScriptならわかる、という人を想定したら
こんな文章に。
Scalaは、そんな人たちの(関数型言語)入門学習用に向く言語仕様である
ように思われたので。
(つーか私自身にとっても最新の関数型言語の入門学習目的で言語仕様
原文から外せない部分を抜き出す形でまとめました(直訳はおろか意訳で
すらねぃです、でも原文読む参考程度にはなるはず)。ちなみにコンカレント
云々はまだわからない程度のレベルな私)
423417:2008/08/22(金) 23:37:07
あーあといちばん最初に訳した言語仕様要約は直すべき部分が最多ですが
今はいろいろあって直すヒマがないのであしからず(私自身によるコメント部分
に集中してるので、そこの変なのは無視してくだされ。要約でない解説諸ペー
ジの方のが正しいです)。
424デフォルトの名無しさん:2008/08/22(金) 23:42:12
>If you purchase just the PDF eBook for $27.50, you will be entitled to receive periodic updates as the authors
>complete the book, as well as the final PDF when the book is finished, for no additional charge. If you purchase PDF
>+ Paper Book combo for $59.99, you will be entitled to the PDF eBook updates, and we'll ship you the paper book
>when it is published, on or around August 30, 2008. (Once the book has been printed, you'll be able to purchase just
>the paper book here for $49.99.)

すいません。これ訳してください。
425デフォルトの名無しさん:2008/08/22(金) 23:55:28
こんな感じか?

$27.50でPDF買ったら、本が完成するまで
追加料金なしでPDFのアップデート受けられるよ。
$59.99でPDFと紙の本買ったら、PDFのアップデートできるし、
10月30日くらいに出版されたら紙の本も送るよ。
出版後は$49.99で紙の本買えるよ。
426デフォルトの名無しさん:2008/08/22(金) 23:57:21
August 30
8月30日、ですね
427デフォルトの名無しさん:2008/08/23(土) 00:05:59
>>425-426
ありがとうございます!
もうすぐ発売日じゃないですか!
428デフォルトの名無しさん:2008/08/23(土) 15:41:22
>>417
ひさびさに電波ぽい文章を見た
429デフォルトの名無しさん:2008/08/23(土) 16:48:38
>>428
だなw

頑張ってくれたのに悪いが、行間びっちりな上にろくに段落を区切ってないから、
文章ではなくなんかの模様に見えてしまう。そんなだから最初の一文すら読む気が起きない。
430デフォルトの名無しさん:2008/08/23(土) 17:34:52
>417
むむむ……典型的な『頭の良い人が書いた難しい文章』だな。
・文が長すぎ/意味詰め込みすぎ
・読者に必要な前提知識が多過ぎ
・話が発散しすぎ
ということでおいらもムリ。

自分も素人なんであんまり偉そうなことは言えないけど、
・一文の意味/意図が一つになるように文を解体する。
 - ()の解説は多用しない。注釈で飛ばした方が良い。
 - 直前の文までに出てきた言葉だけで文章を組む。新規の言葉は解説する。
・段落の基本構造(序破急)を意識して文章を構築する
・文章の基本構造(起承転結)を意識して段落や章を構成する
あたりだけでも注意すればずいぶん違うんじゃない?
431417:2008/08/23(土) 20:41:20
いちばん最初のページの水平線から下は「言語哲学的意味論」なのでいわゆる
リファレンスとしては読む必要はまったくないです (つまり、この水平線は、ここから
下は「Scalaという言語に対する(個人的)注解」である、という意味です)
水平線から上の部分にザッと目を通したあとはそのまま「1階受付」へとお進みく
ださい (そこからはいくらかでもマシになってるかと)
432417:2008/08/23(土) 20:47:00
あと行間は、私は逆に空いてると読みづらい方なので、直すかどうかは微妙です
Firefoxなら「スタイルシートを利用しない」すればほんの少しだけ行間が空いて字
ももう少しだけ大きくなるよーですが ...
433デフォルトの名無しさん:2008/08/23(土) 21:11:55
行間以前の問題だろ>読みづらさ
434デフォルトの名無しさん:2008/08/23(土) 21:27:38
>>417
論文ではなく、仕様書を書くようになればみんなの気持ちが分かるようになるよ。
435デフォルトの名無しさん:2008/08/23(土) 21:47:37
>>430
頭がよいのとおかしいのと狭間くらいだと思う
436デフォルトの名無しさん:2008/08/23(土) 21:59:18
これで難しいって、どれだけ土方なんだよ。

スタイルシートは変更したけど。
437417:2008/08/23(土) 21:59:54
読みづらさについては申し訳ないですが、いずれこのScalaページは6月頃に
書いたもので (必要な人はググって自力で見つけるだろうと思いこちらでとく
には宣伝しませんでした; まだいろいろと不完全であるためもありますが)、今
はほかにやるべきことができてしまって当分私自身による修正は無理っす

ぬか喜びさせてしまって申し訳なひ、おのおの方
438デフォルトの名無しさん:2008/08/24(日) 00:56:07
スタイルは俺も無効にしたw
これぐらい特殊な文体でもいいんじゃないかな。もちろんわかりやすいほうがいいが、
クセがあって読みにくいぐらいの文章でも、Scalaの雰囲気としてはあってるような気がする。
439デフォルトの名無しさん:2008/08/24(日) 06:34:46
>>430
序破急! うーーーーん。
440デフォルトの名無しさん:2008/08/24(日) 10:14:48
序破急 > 導入・展開・参考
起承転結 > 理由・これまでの過程・話者の新しい意見・新旧の比較

とゆーことではないかな?
ちなみに序破急は能の作劇論、起承転結は漢詩の構成論が由来
441not 439:2008/08/24(日) 10:33:48
技術文書の段落に序破急はおかしいだろw
>>440の頓珍漢さに苦笑
442430:2008/08/24(日) 12:35:13
>441
じゃあ導入->展開->結び で良いや。
さすがに段落ごとに全部この構成にするのはムリがあるけど、意識しないで
破綻するよりはマシですな。

>440
起承転結は序章の話になりますな。
各階の説明は概要->詳細の二段構成でも十分かな。

活用例は>440みたいな感じだけど、起の部分は『文章の全体像・説明範囲を規定する』という内容になるかと。
読者にまず「この文章は何について言及するのか?」というスコープを提示するわけですな。

ちなみに、序破急は能じゃなくて雅楽から来た言葉らしいよ(Wikipedia)
443デフォルトの名無しさん:2008/08/24(日) 13:25:36
>>434
それは論文に対して失礼だw
>>417には悪いが、少なくとも、コンピュータサイエンス系の論文で>>417くらい読みづらい
文章は見た覚えがないよ
444デフォルトの名無しさん:2008/08/24(日) 13:34:09
417のサイトは他のページの方が電波ゆんゆんでいい感じだ
445デフォルトの名無しさん:2008/08/24(日) 15:15:12
Programming in Scalaって本当に8月30日くらいに発売されるの?
アマゾンとかに全然来てないんだけど・・・
446デフォルトの名無しさん:2008/08/24(日) 15:47:49
417は括弧部分をごっそり削ると、ちょっとだけ読みやすくなるぞ。
ちょっとだけ、だけどな。
447デフォルトの名無しさん:2008/08/24(日) 22:04:48
Amazonとかの普通の流通に乗るのかなあって気も。
448デフォルトの名無しさん:2008/08/25(月) 00:06:02
え!?そんな立ち位置なの・・・
Scalaのサイトでしか発売されないのかなあ・・・
449デフォルトの名無しさん:2008/08/25(月) 19:44:46
>>417とか人によませるブログとか一度書いてみた方がいいと思うよ
450デフォルトの名無しさん:2008/08/25(月) 21:29:39
ところでProgramming in Scalaってどんな内容なの?
PDF読んだ人いますか?
451デフォルトの名無しさん:2008/08/25(月) 22:45:57
pdf読める携帯買ったんで突っ込んでみたが、読みにくくて読んでないな
452デフォルトの名無しさん:2008/08/26(火) 08:18:39
>>450
> どんな内容なの?

読め
453デフォルトの名無しさん:2008/09/02(火) 12:51:20
Programming in Scalaって結局出版されたんですか?
454デフォルトの名無しさん:2008/09/02(火) 14:36:35
日曜に本屋で見た。
455デフォルトの名無しさん:2008/09/02(火) 21:47:42
マジで?
日本の本屋?
456 :2008/09/02(火) 22:14:25
うそだろ。ホームページ見たら
when it is published, on or around September 30, 2008.
ってなってた。また延期です。
457デフォルトの名無しさん:2008/09/07(日) 10:06:41
この言語、groovy, jython, jrubyなどに対する利点は?
458デフォルトの名無しさん:2008/09/07(日) 11:10:24
>>457
一つは速度
459デフォルトの名無しさん:2008/09/07(日) 12:02:40
おお、それは凄い!
残りの二つ目以下26項目も挙げてくだされ。
460デフォルトの名無しさん:2008/09/07(日) 12:04:16
jython > 本家にかなり遅れている
jruby > 元来 Rails と Java の共用が目的で、それ以外にあえて使う理由がない
groovy > Java 版 Rails のための言語だが失敗。Rails 利用者は Java を要せず、
Java 利用者は Rails を要せず
scala > 関数型パラダイムを Java に持ち込むための言語で、上 3 つとの類似は
あくまでその結果 (Python と Ruby が関数型パラダイムの影響を非常に
強く受けているため)
つーわけで利点云々以前に、もともとの存在理由がまったく異なります
461デフォルトの名無しさん:2008/09/07(日) 12:40:59

その逃げはないっしょ
462デフォルトの名無しさん:2008/09/07(日) 12:52:26
都合の悪い展開になったから逃げ呼ばわりするという逃げは
どうかと思います。
463デフォルトの名無しさん:2008/09/07(日) 13:04:26
は?俺に都合のいい展開って何?各言語信者の醜い貶しあい?
464デフォルトの名無しさん:2008/09/07(日) 14:11:14
結局Scalaのアドバンテージは特に無い、という展開。
465デフォルトの名無しさん:2008/09/07(日) 14:45:10
Scalaの利点ねえ。
あえて挙げるならきちんとした型システムがあるとことかかな。
466デフォルトの名無しさん:2008/09/07(日) 15:21:49
>>464
Javaで書くより100倍楽だけど、性能はJavaと同等。
でもEclipseのScalaプラグインはもうちょっとがんばって欲しい。
今だとまだEmacsのscala-modeの方が使い易い。
467デフォルトの名無しさん:2008/09/08(月) 11:36:23
メッセージ駆動並行なコード書くのに
JMSとJMXでMDBと、ScalaのActorどっちが楽?

俺は断然Actor派
468デフォルトの名無しさん:2008/09/08(月) 22:20:42
Erlang派
469デフォルトの名無しさん:2008/09/13(土) 08:13:33
470デフォルトの名無しさん:2008/09/13(土) 16:16:58
Computer Language Benchmarks Game
ttp://shootout.alioth.debian.org/u64q/index.php

Javaは何だかんだで早いよなぁ。
やっぱり俺の本命はErlangじゃなくてScalaだ。
次世代ゲーム機もScalaWithJavaAPIでいいと思う。
471デフォルトの名無しさん:2008/09/13(土) 17:23:11
>>988
古い規格だと、ISO 9899:1990 セクション 3.4 で "byte" が定義されている。
同 セクション6.3.3.4 に The sizeof operator yields the size (in bytes) of its operand.
とある。
sizeof(char)は1で単位はバイト。

終了。
 
472デフォルトの名無しさん:2008/09/13(土) 17:25:46
>>988
古い規格だと、ISO 9899:1990 セクション 3.4 で "byte" が定義されている。
同 セクション6.3.3.4 に The sizeof operator yields the size (in bytes) of its operand.
とある。
sizeof(char)は1で単位はバイト。

終了。
473デフォルトの名無しさん:2008/09/13(土) 17:26:50
誤爆しかも連投ごめんなさい。
474デフォルトの名無しさん:2008/10/03(金) 21:43:26
C99なんてもう誰も知らんぞ・・・
475デフォルトの名無しさん:2008/10/03(金) 22:22:20
今度こそProgramming in Scalaって出版されましたか?
476デフォルトの名無しさん:2008/10/05(日) 01:00:30
いいえ
477デフォルトの名無しさん:2008/10/05(日) 14:34:55
10月30日以降にまた延期でっす!!
478デフォルトの名無しさん:2008/10/05(日) 19:18:20
またかよ!
完成してから発売日発表しろよ!!
479デフォルトの名無しさん:2008/10/05(日) 19:24:51
>>478
商売の基本は、発売前にマーケティング開始することだからなあ・・・
売れないのがわかったら出ないもんだし

ぁゃしぃebookだってそうだろ?
最初にまず、市場調査→セールス文を書く→マーケティングをしかける→商品作る→売れそうなら発売
が基本ってしってた?
480デフォルトの名無しさん:2008/10/05(日) 19:25:23
> 商売の基本は、発売前にマーケティング開始することだからなあ・・
商売の基本は、商品完成前、発売前にマーケティング開始することだからなあ・・
481デフォルトの名無しさん:2008/10/06(月) 00:30:08
執筆はどの時点で終わってるの?
482デフォルトの名無しさん:2008/10/11(土) 01:14:30
ScalaByExampleのサンプルで動かなかったので質問
9.3章の最後
val intSort = msort((x: Int, y: Int) => x < y)
val reverseSort = msort((x: Int, y: Int) => x > y)
最後に'_'がない

10.3章
for { i <range(1, n)
   j <range(1, i)
   if isPrime(i+j)
} yield {i, j}
List.range()になってない
最後が(i,j)じゃない
これってサンプルのミスってことでいいの?
483デフォルトの名無しさん:2008/10/11(土) 19:31:52
昔のバージョンではメソッドから関数への変換は _ つけてなかったし、タプルリテラルも中括弧だった(不評のためすぐに小括弧になった)。rangeは覚えてないけどそうだったんだろうね。
484デフォルトの名無しさん:2008/10/11(土) 19:42:07
rangeは単にミスか省略か前提があるのかも。
485デフォルトの名無しさん:2008/10/11(土) 22:59:16
ただのミスでしょう。ScalaLanguageSpecificationやScalaByExampleには新版ではエラーに
なる旧版のままの例のほかにもひと目でわかるタイプミスもときどきあります
486デフォルトの名無しさん:2008/10/12(日) 00:07:59
解答サンクス
仕様変更にリファレンスが追いついてない状態なのね
本の出版が遅れるのも納得だわ
487デフォルトの名無しさん:2008/10/12(日) 12:48:50
見つけたScala Language SpecificationやScala By Exampleのミスは、
MLで報告してあげると良いかも。英語で質問するのは敷居高いと思うかも
しれんが、適当な英語でもそれなりに意味を汲み取ってくれるので、大丈夫
488デフォルトの名無しさん:2008/10/13(月) 22:26:54
2.7.2 RC3でた
489デフォルトの名無しさん:2008/10/18(土) 12:49:41
490デフォルトの名無しさん:2008/10/18(土) 13:20:09
>>489
> March 30, 2009.
orz
491デフォルトの名無しさん:2008/10/18(土) 13:53:15
あー489はOdersky本とは別ですよ。タイトル同じだけど。

これも別ね。
http://blog.aspectprogramming.com/2008/10/6/writing-a-book-on-scala
492デフォルトの名無しさん:2008/10/19(日) 00:22:05
タイトル、微妙に違うくね?
493デフォルトの名無しさん:2008/10/22(水) 07:54:12
Programming in Scala is at the Printer
http://www.nabble.com/-scala--Programming-in-Scala-is-at-the-Printer-td20098100.html#a20098100
> most likely we'll be shipping printed copies to all those who bought them the second and third week of November.

まだ先かー。
494デフォルトの名無しさん:2008/10/23(木) 10:03:02
今日は、Scala勉強会@東北の日。東北と言っても、開催するのはネット上。夜の8時から。
495デフォルトの名無しさん:2008/10/24(金) 20:23:54
エロい人ならScalaでグラフ構造ってどうつくるんだろう?
自分でつくると、JAVAで作ったのと変わらない物ができてしまう・・・
caseクラスとか駆使して、もっと、かっちょよく作れないもんかな。
496デフォルトの名無しさん:2008/10/24(金) 22:16:36
そんなメタな構造なら、どんな言語で作っても基本は同じになるんじゃない?
それにメタであるだけに、応用によって実装のしかたは変わるし。
「アルゴリズムがJavaならオブジェクト指向に!」みたいな違和感がある。
497デフォルトの名無しさん:2008/10/25(土) 07:07:55
Scalaって下がJavaだから仕方ないんだろうけど、
他の関数型言語だと構文で解決するようなものを
動的な仕組で無理矢理そう見せてる部分が筋がよくなくてどうにも気持ち悪い。
498デフォルトの名無しさん:2008/10/25(土) 12:34:48
tatoeba?
499デフォルトの名無しさん:2008/10/25(土) 15:26:47
>>497
んなこたあ無いと思うが、具体例は?
500デフォルトの名無しさん:2008/10/25(土) 16:42:48
>>497
え?動的な仕組で無理やり解決?それってむしろ他の関数型言語でしょ。
Scalaは静的な仕組みで無理やり解決だよ。
501デフォルトの名無しさん:2008/10/25(土) 16:49:35
リストの構築子も :: なんてそれっぽいものを用意してはあっても
所詮はメソッドのお化粧なのでパタンに書けないとか。

パタンマッチするのにケースクラスなんてものを導入せざるを得なかったのが
そもそもそうだと思うし。
502デフォルトの名無しさん:2008/10/25(土) 17:29:45
ポイントがよくわからんので具体的なコードで他言語と比較してほしいなあ。
503デフォルトの名無しさん:2008/10/25(土) 18:01:52
>>501
なんとなくわかった。
ちょっと違うが、JavaのGenericsのような無理や不自由さがあるということか。
504デフォルトの名無しさん:2008/10/25(土) 18:04:49
余計わかんねー。Javaのジェネリクスって動的な仕組みなの?
505デフォルトの名無しさん:2008/10/25(土) 18:10:26
>>501
えーと、::はListクラスのメソッドであり、かつcase classだからパタンに書けるんだが…
それはともかく、ケースクラスを導入せざるを得なかったってのは違うと思うな
パターンマッチングという機能をプリミティブで拡張性の無いものでなく、ユーザが
後付けでパタンを定義できて拡張性のあるものにするためにどうすればいいのか
という問題に対する解の一つがケースクラスなりExtractorであるってことだと思う
MLとかのパターンマッチに関する有名な問題の一つとして、抽象データ型に
対してパターンマッチできん、というのがあるけど、Scalaではこの点はそもそも
問題にすらならない
506デフォルトの名無しさん:2008/10/25(土) 22:00:06
>>504
仕組みや目的はまったく違うけど、VMの仕様が言語に影響して無理があって不自由なところが一緒かと
507デフォルトの名無しさん:2008/10/26(日) 11:17:41
JVM 上の Scheme とか普通にあるし、VM の仕様より、既存の Java ライブラリとの親和性を
重視してるかどうか、の違いでわ?
508デフォルトの名無しさん:2008/10/26(日) 19:05:01
なんつーか、JVMの仕様からくる言語使用上の制約は実際あって思いつくけれども、
最初に動的とか非関数型的とかって書いたのはテキトーでしょ?
いずれにせよもうちょっと具体的に語ってくれればその通りだねとかいやそれは違うとかいえるんだけどさ。
509デフォルトの名無しさん:2008/10/26(日) 23:59:56
>> 507
動的な型の言語と比較するのはあまり意味がないと思われる。
510デフォルトの名無しさん:2008/10/27(月) 00:37:34
>>506
Javaからも呼び出せるように class としてバイナリを作成するがために、言語仕様に制約が出ているんじゃないかってことと考えて良い?
511デフォルトの名無しさん:2008/10/27(月) 09:19:20
>>501
そりゃ構文の話で、動的とか静的とか関係ないだろ。
512デフォルトの名無しさん:2008/10/27(月) 09:27:01
>>505
case classを使ったパターンマッチを、
クラス上のデザインパターンにするって主旨の設計だからねえ。
データ構造に依る分岐構造を、
データ構造上のcase classにまとめて整理しようって考え。
Scalaは型大好きだから。

パターンマッチ作法が強制されるけど、
整理の仕方としては面白いわね。
513デフォルトの名無しさん:2008/10/27(月) 11:52:41
オカマっぽい
514デフォルトの名無しさん:2008/10/28(火) 20:20:27
>>513
すまん。女です。
515デフォルトの名無しさん:2008/10/29(水) 10:13:26
ワロタ
516デフォルトの名無しさん:2008/10/30(木) 02:43:53
2.7.2 RC4でた
517デフォルトの名無しさん:2008/11/02(日) 01:52:02
RC5でた
518デフォルトの名無しさん:2008/11/02(日) 10:54:35
RC6でた
519デフォルトの名無しさん:2008/11/02(日) 21:36:53
RC7でた
520デフォルトの名無しさん:2008/11/02(日) 23:10:55
いや、マジで 今 RC6
521デフォルトの名無しさん:2008/11/03(月) 00:43:24
RC8来たよ
522デフォルトの名無しさん:2008/11/03(月) 01:14:09
マジかと思って見てみたらRC9が出てるし
523デフォルトの名無しさん:2008/11/03(月) 01:35:29
Programming in ScalaってAmazonとかで買えるようになるんですかね?
524デフォルトの名無しさん:2008/11/03(月) 19:27:53
そうして RC365 まで毎日でるわけですね
525デフォルトの名無しさん:2008/11/03(月) 21:02:39
>>524
そこまでRubyの真似をしなくていいよwww
526デフォルトの名無しさん:2008/11/04(火) 01:01:21
>>525
Vimのまねだったらやだな。
527デフォルトの名無しさん:2008/11/04(火) 10:30:07
D言語みたいに、0.99から0.100になるよりは期待感なくてよいじゃないの
528デフォルトの名無しさん:2008/11/05(水) 11:49:46
scala・・・この言語イマイチだねえ
529デフォルトの名無しさん:2008/11/05(水) 11:50:38
とにかく中途半端な印象しかない
530デフォルトの名無しさん:2008/11/05(水) 16:26:21
とにかくイマイチ絶対に例を挙げない
531デフォルトの名無しさん:2008/11/05(水) 17:36:06
あくまで実用本位で言語オタク受けは眼中にないからな
532デフォルトの名無しさん:2008/11/05(水) 17:46:01
えっ!?
533デフォルトの名無しさん:2008/11/05(水) 19:06:39
rubyの気持ち悪さ異常
534デフォルトの名無しさん:2008/11/05(水) 22:11:20
ruby や groovy は、いいときはミラクルなまでにサクサク進むけど
バグるとプロでもさじを投げるぐらいデバッグが超絶困難なようだね
535デフォルトの名無しさん:2008/11/05(水) 22:42:12
コミュニティの性格に似てるかもな。
好きなスタイルで気分良くモノを進めている時は非常に良い顔を見せるが、
好まないスタイルとの出会いや不機嫌に耐性が無く、そういう時は非常に排他的で非生産的になる。
536デフォルトの名無しさん:2008/11/07(金) 23:54:23
>>534
普段、静的型付け言語とRubyつかっているけど、たまに頭のモード切替が不十分で
静的みたいに書いちゃって、なかなか気づかないバグ残したことがあるよ。

この前ハマったのは、クラスのプロパティをattr_accessorだかで定義して、
自クラス内でプロパティ名そのままでアクセスしようとして、上手くいってなくて、
1日悩んだ挙句、self.プロパティ名、でアクセスしないといけないことに気づいたことかなw
アホか俺は、と思ったけどw
537デフォルトの名無しさん:2008/11/08(土) 00:07:25
スレ違い
538デフォルトの名無しさん:2008/11/08(土) 10:22:16
Actor の link って何に使うのか良くわからん・・・・
539デフォルトの名無しさん:2008/11/08(土) 12:25:48
別のアクターが終了したのを検知する(あるいは一緒に死ぬ)ため。
540デフォルトの名無しさん:2008/11/08(土) 15:06:14
ありがとうー。
Exit メッセージが来るってことですね。

てっきり、複数のアクタをグループ化して、メッセージのマルチキャストみたいなことができるのかと勘違いした。
541デフォルトの名無しさん:2008/11/08(土) 15:08:13
あぁ、そうか。プロセスと同じように考えればいいのか。
親プロセスが死んだら、子プロセスも死なすって考えればいいのか。
542デフォルトの名無しさん:2008/11/08(土) 15:51:32
メッセージのマルチキャストは、仲介役のアクタを用意して、自前でやるってことか・・・
http://www.nabble.com/Scala-actors-and-message-broadcasting-td19442504.html#a19442504
543デフォルトの名無しさん:2008/11/10(月) 12:20:05
Scala 2.7.2 final キタ!
544デフォルトの名無しさん:2008/11/10(月) 21:13:27
次は final2 がリリースされるんですね、わかります。
545デフォルトの名無しさん:2008/11/15(土) 08:39:33
Programming in Scalaって出版されましたか?
546デフォルトの名無しさん:2008/11/15(土) 21:33:35
11月25日前後を刮目して待て!
547デフォルトの名無しさん:2008/11/15(土) 22:09:54
刮目して待ちます!
548デフォルトの名無しさん:2008/11/19(水) 00:11:34
Programming in Scala 出版age
549デフォルトの名無しさん:2008/11/19(水) 12:03:23
紙の本はまだだな
550デフォルトの名無しさん:2008/11/20(木) 22:06:48
紙のほうは日本で買えるんですか?
551デフォルトの名無しさん:2008/11/21(金) 08:26:36
アマゾンで買えるようになんじゃね
552デフォルトの名無しさん:2008/11/25(火) 11:07:31
下は公式サイト(確か・・)で取ったサンプルコードなんだが、
作成アクター数(nActors)が500くらいからエラー吐きまくり・・

2.7.1の頃は、nActors = 1000でもちゃんと動いたんだが、
なんか知ってるエロい人いない?

import scala.actors._
import scala.actors.Actor._

object Message {
def main(args: Array[String]) {
val n = try {
Integer.parseInt(args(1))
} catch {
case _ =>
println("Usage: examples.actors.Message <n-actors> <n-times>")
Predef.exit }
val nActors = 1000
val finalSum = n * nActors
Scheduler.impl = new SingleThreadedScheduler
553デフォルトの名無しさん:2008/11/25(火) 11:08:50
// 続き1
def beh(next: Actor, sum: Int) {
react {
case value: Int =>
val j = value + 1; val nsum = sum + j
if (next == null && nsum >= finalSum) {
//println(sender)
println(nsum)
System.exit(0)
} else {
if (next != null) next ! j
//println(sender)
beh(next, nsum) }}}
554デフォルトの名無しさん:2008/11/25(火) 11:13:52
// 続き2
def actorChain(i: Int, a: Actor): Actor =
if (i > 0) actorChain(i-1, actor(beh(a, 0))) else a

val firstActor = actorChain(nActors, null)
var i = n
while (i > 0) {
firstActor ! 0
//if (i % 100 == 0) println(i)
i -= 1 }}}
555デフォルトの名無しさん:2008/11/25(火) 11:20:20
nActors >= 473 で
以下を延々吐くみたい

at Message$$anonfun$beh$1$1.apply(message.scala:34)
at Message$$anonfun$beh$1$1.apply(message.scala:25)
at scala.actors.Reaction.run(Reaction.scala:78)
at scala.actors.SingleThreadedScheduler.execute(Scheduler.scala:174)
at scala.actors.Scheduler$.execute(Scheduler.scala:80)
at scala.actors.Actor$class.send(Actor.scala:411)
at scala.actors.Actor$$anon$1.send(Actor.scala:93)
at scala.actors.Actor$class.$bang(Actor.scala:583)
at scala.actors.Actor$$anon$1.$bang(Actor.scala:93)
556デフォルトの名無しさん:2008/11/25(火) 17:50:27
StackOverflow が出てるんだけど、-Xmsをいくら増やしても改善しない。これはバグかもわからんね・・・
557デフォルトの名無しさん:2008/11/25(火) 18:51:51
Programing in Scala v6(PDFと紙で買える奴な)
で、p73に

val greetStrings = new Array[String](3)

って言うコードがあるんだけどさ
2.7.2 final でインタプリタモード立ち上げて打ったら

scala> val greetStrings = new Array[String](3)
java.lang.NullPointerException
at scala.runtime.BoxedArray._deepToString$1(BoxedArray.scala:134)
at scala.runtime.BoxedArray.deepMkString(BoxedArray.scala:139)
at scala.runtime.BoxedArray.deepToString(BoxedArray.scala:127)
at scala.runtime.ScalaRunTime$.stringOf(ScalaRunTime.scala:163)
at RequestResult$.<init>(<console>:4)
at RequestResult$.<clinit>(<console>)
at RequestResult$...

だってさ \(^o^)/

2.7.1は全く問題なし \(^o^)/

とってもBuggyです本当ny
558デフォルトの名無しさん:2008/11/25(火) 20:01:50
何気にインタプリタでArrayを内容表示する方式が変わったんだな。
昔は [L 方式で、新しいのは中身も表示してあげようとして要素のtoString呼んじゃってるようだ。
ArrayのtoString自体には問題ないようなのでインタプリタ固有の表示ルーチン持ってるんかな。
559デフォルトの名無しさん:2008/11/25(火) 21:14:09
昔は単純にオブジェクトのtoStringを呼んでたんだけど、
新し目の版ではScalaRuntime#stringOfってメソッドを追加してそっちを使っているようだ。
stringOfはval a = null みたいなのについて例外を出さなくしてくれるのだが、
ArrayについてはtoStringじゃなくdeepToStringを呼ぶようにしていて、
このdeepToStringは要素のnullには(たぶん昔から)対応していないんだな。
560デフォルトの名無しさん:2008/11/25(火) 21:33:26
val greetStrings = Array.make[String](3, "")
でとりあえず回避可
561デフォルトの名無しさん:2008/11/25(火) 22:57:29
>>556
-Xss でかくするとか
562556:2008/11/25(火) 23:29:14
>561
スマソ、556は-Xssのtypoでした。
Xmx,Xssとも増やしてもだめだった。><

ちょっとソース眺めてみたが、Actorまわりは結構手が入っている模様。
(スケジューラはインターフェースも変わっている)
もしかしたら、SingleThreadedSchedulerはそれらに対応できていないのかもしれない。

http://lampsvn.epfl.ch/trac/scala/changeset?old_path=%2Fscala%2Ftrunk%2Fsrc%2Factors%2Fscala%2Factors%2FScheduler.scala&old=13978&new_path=%2Fscala%2Ftrunk%2Fsrc%2Factors%2Fscala%2Factors%2FScheduler.scala&new=16207

ちなみに、上記のソースも
Scheduler.impl = new SingleThreadedScheduler
をしなければ、動くはず。
563561:2008/11/26(水) 12:57:09
java -Xss64M -cp scala-library.jarのパス:. Message 1000 1000
こちらではこれで動きますた
564561:2008/11/26(水) 13:16:35
ちなみに
Scheduler.impl = new SingleThreadedScheduler
をしてる方
あと、デフォらしい -Xss512K では StackOverFlow しましたが
-Xss1024K なら大丈夫でした
565556:2008/11/26(水) 13:43:32
>563
むむっ・・・本当ですね・・・
当方、環境変数JAVA_OPTSで設定していたつもりが、
なにか間違っていて設定が効いてなかったみたいです。orz

結局、単純に2.7.2でスタックの消費量が増えてたってことっすね・・・
566デフォルトの名無しさん:2008/11/27(木) 23:58:25
>>551
本当にアマゾンで買えるのかなあ?
いまだに上がってない・・・
3月発売予定の達人のほうは上がっているのに・・・
567デフォルトの名無しさん:2008/11/28(金) 00:55:36
まだみたいだね
http://www.amazon.com/dp/0981531601/
568デフォルトの名無しさん:2008/12/01(月) 10:45:13
買えるようになったな
569デフォルトの名無しさん:2008/12/08(月) 07:09:25
今日、やっと pattern matching の凄さを、下にある OCaml の 加減乗除算式を変形する
コード例で理解できました。

 http://www.ocaml-tutorial.org/ja/data_types_and_matching

pattern matching だけならば python でも近いことが実装できそうな気がしますが、「
Warning: this pattern-matching is not exhaustive.」と警告を出すことは不可能とし
か思えません。

でも OCaml ではライブラリの蓄積に限りがあります。本格的に OCaml をやるのは躊躇わ
れます。Scala の pattern matching でも OCaml と同等の「this pattern-matching
is not exhaustive.」警告を出してくれるのならば OCaml ではなく Scala に挑戦してみ
たいと思います。

Scala の pattern matching でも 「this pattern-matching is not exhaustive.」警告
を出してくれるのでしょうか? 少し google しても、下のようなことも書かれています。

 http://lampsvn.epfl.ch/trac/scala/ticket/335

Scala の 「pattern-matching is not exhaustive.」警告について教えてくださいませ。
570デフォルトの名無しさん:2008/12/08(月) 09:07:06
>>21を読めばいい
571デフォルトの名無しさん:2008/12/08(月) 13:01:16
>>570 >>21を読めばいい

御指摘、ありがとうございます。

若干のバギーな面があるにしても OCaml に近い pattern matching 処理を scala でも書
けそうですね。

Scala に喰らい尽きたくて涎が出ています。ただ、scala に移ってくる programmer の割
合が心配です。Java programmer の殆どは scala には移ってこないだろうと思っていま
す。Python から scala に来る programmer の方が多そうに思えます。
572デフォルトの名無しさん:2008/12/08(月) 22:57:13
>>571
誰がどこから移ってくるとかどうでもいい
573デフォルトの名無しさん:2008/12/09(火) 09:15:41
どうでもいいと思ってるなら書かなきゃいいのに。
いちいち自分の興味ない話題に「どうでもいい」なんてレスしてたらキリないぞ。
574デフォルトの名無しさん:2008/12/09(火) 09:44:20
「どうでもいい」厨にレスしなくていいよ。
どこにでもいるから。
専用ブラウザのあぼーんに設定しておけばそれで済む話
575デフォルトの名無しさん:2008/12/09(火) 17:12:50
自意識が分相応なところに落ち着く前の年齢なんでしょ。

「この俺が、他ならぬこの俺が、どうでもいいと思った!
この話題自体はどうでもいいことだが、この俺がどうでもいいと思ったことは
なんとしても書き込まれねばならない重大ニュースだ!」
576デフォルトの名無しさん:2008/12/09(火) 17:15:20
なんて中身の無いスレだ
577デフォルトの名無しさん:2008/12/09(火) 21:27:15
Scalaでスカラ
578デフォルトの名無しさん:2008/12/10(水) 00:15:14
珍しく書き込みが続いたと思ったらこれかよ
579デフォルトの名無しさん:2008/12/10(水) 01:05:02
3っつもレスがつくなんて>>572も書き込んだかいがあったな
580デフォルトの名無しさん:2008/12/11(木) 08:47:42
>>569 です。scala へ飛び込むための背中押しをお願いします。また Java は殆ど使って
いないので誤解があったら指摘してやってください。

Java の generics は C++ generics/python duck typing とは別物だと思います。実質
的には、collection に対する cast を省略するために導入された構文だと極論しても許
されると思います。

本来の generics programming は、method 構造の共用を利用したプログラムの共用だと
思います。例えば __add__ method と __len__ method が共用されている全てのインスタ
ンスについて、下のような平均ルーチンを共用できることが generics programming だと
思います

T mean(listOfT):
  T tAt = 0
  for elm in listOfT: # sum up loop
    tAt = elm.__add__(tAt)

  return tAt/len(listOfT)

この意味で C++ template と python duck typing は似ています。必要があれば boost
library をpython に移植できます。一方で boost library を Java に移植するなんて無
理だと思います。

------------------------------
ここで質問です。 scala の generics は Java と同じ/別物どちらでしょうか。
boost library などの C++ template program を scala に移植することは可能でしょう
か。

これが可能ならば scala に飛び込みます。よろしく教えてやってくださいませ。
581デフォルトの名無しさん:2008/12/11(木) 09:49:16
Scalaやらないでいいよ。
582デフォルトの名無しさん:2008/12/11(木) 11:30:04
>>580
書き方を見るに、C++ templateすらろくに理解してなさそうだけど
(boostをpythonに移植できるなんて簡単に言う辺りがそう。boostはC++
templateのメタプログラミング機能を利用した部分も多くあって、duck typing
があれば大丈夫程度の代物じゃないよ)
あえて言うと、ScalaのgenericsはJavaのgenericsのシステムがベースに
なっていて、かなり似てはいる。もちろん、Javaのgenericsには無い特徴も
多くあるけど。
583デフォルトの名無しさん:2008/12/11(木) 13:33:44
>>569 です。ご意見ありがとうございます。

>書き方を見るに、C++ templateすらろくに理解してなさそうだけど
>(boostをpythonに移植できるなんて簡単に言う辺りがそう。boostはC++
>templateのメタプログラミング機能を利用した部分も多くあって、duck typing
>があれば大丈夫程度の代物じゃないよ)

同意します。boost は必要に迫られた範囲でしか追っていません。私の環境では、
boost に積極的に関わったら、周囲から浮き上がってしまうだけだからです。

「C++ のSTLを使ったプログラムを scala に移植できますでしょうか?」と話を狭めます。
STL を使っただけのプログラムなら、大部分は duck typing で対応させられます。でも
Java の generics では無理でしょう。


>もちろん、Javaのgenericsには無い特徴も多くあるけど

580 さんは、私よりずっと知っていそうです。できたら「Javaのgenericsには無い特徴」
で主要だと思われる数点をあげてもらえますでしょうか。
584582:2008/12/11(木) 19:16:55
>>583
>>582では、筆が滑って偉そうな書き方になってしまった。申し訳無い。

>「C++ のSTLを使ったプログラムを scala に移植できますでしょうか?」と話を狭めます。
>STL を使っただけのプログラムなら、大部分は duck typing で対応させられます。でも
>Java の generics では無理でしょう。

現在のJavaの標準ライブラリだと苦しいと思いますが、JavaでもSTL風のライブラリを
組めば近いことはできると思います(実際、STLを意識した設計のJavaコレクション
ライブラリがありました)。もちろん、STLの使われ方によっては難しい場合もあると
思いますが、一般的なケースでは十分可能ではないかと思います。

>580 さんは、私よりずっと知っていそうです。できたら「Javaのgenericsには無い特徴」
>で主要だと思われる数点をあげてもらえますでしょうか。

・genericsの共変/反変
詳しい説明は省きますが、Genericな型T[A]とT[B]があったときに、
A <: B(AがBのサブタイプである、と読む)ならばT[A] <: T[B]であるとき、
genericな型Tは共変である、といいます。その逆に、A <: BならばT[A] >: T[B]
であるとき、Tは反変である、といいます。具体例を出すと、ScalaのList型は
共変になっていて、List[Any]型の変数にList[String]やList[Int]を入れたり
することができます。このような機能はJava(やC++)にはありません(C++なら
templateを駆使した技巧によってあるいはできるかもしれないけど、素の
機能としては無いです)。
585582:2008/12/11(木) 19:17:48
レスが長くなったので分割しました。

・structural type
いわば静的に型チェック可能なダックタイピングのようなもので、
例えば、
type A = { def hello: Unit }
とすると、A型は、Unitを返すhelloメソッドを持つ全ての型に適合するようになります。
この機能自体はgenericsに直接関係するわけじゃないですが、genericな型の
制約として、structural typeを使うことができるため、型パラメータTがhelloメソッド
を持っているべき、などの制約を表現することができます(いくつか実装上の
制約がありますが)。

・型パラメータのlower bound指定
Javaのgenericsでは、型パラメータTがある型のサブタイプであるべき、という制約は
表現できますが、Tがある型のスーパータイプであるべき、という制約は表現できません。
これは、上で書いた共変/反変の機能とセットで使うことで威力を発揮します。

他にもありますが、とりあえずこの辺で。
586デフォルトの名無しさん:2008/12/11(木) 22:18:27
えー、Javaでも反変あるでしょ?
Scala特有なのはvariance annotationで自動的に共変なり反変なりになるところだと思う。
587デフォルトの名無しさん:2008/12/11(木) 23:17:31
$ scala helloWorld.scala
/work/helloWorld.scala:1 error: not found: value println
println("hello, world!")
^
one error found
588デフォルトの名無しさん:2008/12/11(木) 23:27:20
それからScalaのジェネリクスがC++とJavaのどちらと多くを共有しているかっていったら問答無用でJavaのほうだよ。
それでScalaやらないでC++やるっていうんだったら好きにすればいいと思う。
「C++にできてJavaにできない○○があるが、Scalaではどうか?」って聞いてくれればがんばって答えてみるかも。
589582:2008/12/11(木) 23:38:37
>>586
ワイルドカードの下限境界の事言ってる?あれは「型を使う側」で明示的に指定しない
といけないという点で違うし、制限も強い。ワイルドカードに相当するのは、Scalaだと
Existential Typeだね。
590デフォルトの名無しさん:2008/12/11(木) 23:42:16
いや、だから反変がJavaにはないっていうのは違うでしょ?
591582:2008/12/11(木) 23:54:19
いや、A <: B => T[A] <: T[B]であるような、厳密な意味での反変はやはり無いと
言って良いと思う。Javaの場合、A <: B => T[A] <: T[? extends B]なわけだし。
ただまあ、誤解を招く書き方ではあったかもしれんとは思うけど。
592582:2008/12/11(木) 23:58:46
すまん。共変と反変が逆になっとる。正しくは、以下。

いや、A <: B => T[B] <: T[A]であるような、厳密な意味での反変はやはり無いと
言って良いと思う。Javaの場合、A <: B => T[B] <: T[? super A]なわけだし。
ただまあ、誤解を招く書き方ではあったかもしれんとは思うけど。
593デフォルトの名無しさん:2008/12/12(金) 08:35:32
>>569 です。582 さん、詳細に答えて下さり感謝します。

「Java の generics では、下のように extends を使う。デフォルトでは Object を継承
する」との説明を読んで、これは制限が強すぎると感じました。List, Vector, Map など
の素直なコレクション・ライブラリを記述するには型チェックが有効に働くでしょう。で
も使いもしないメソッドにまで型チェックが利いてしまうのでは、generic なライブラリ
を作るほうが大変だろうと推測していました。

  public static <T extends Comparable<T>> boolean greater(T t1, T t2) {
    return t1.compareTo(t2) > 0;
  }

だからこそ、List(Any) と書けるようにしたのだと思います。


反変/共変は理解できていませんが、皆様の議論を見ていると scala では型チェックを
重視・活用しているように思えます。OCaml でのようにコンパイル段階でエラーを検出・
指摘することに拘っているのだろうと推測します。

Python duck typing のように、実行時にエラーを吐き出していたのでは、ビジネス用途
で使い物にならないのだと思います。C++ template でのように、大量の意味を掴みにく
いエラーメッセージを吐き出すことは、scala ではないのだと思います。

もうすこし調べてみます。ありがとうございました。
594デフォルトの名無しさん:2008/12/12(金) 18:54:30
相対論スレかと思った
595デフォルトの名無しさん:2008/12/13(土) 00:12:24
scalaを使うと並列処理がとても上手く書けると聞いた
そのメカニズムを教えてくれないか?
596デフォルトの名無しさん:2008/12/13(土) 00:15:40
関数型だから??
597デフォルトの名無しさん:2008/12/13(土) 00:19:00
598デフォルトの名無しさん:2008/12/13(土) 12:45:16
>>587
あえて print1n にしてエラーメッセージ出させるとうちの 2.7.2 final では
(fragment of HelloWorld.scala):1: error: not found: value print1n
print1n("Hello, world!")
^
one error found
!!!
discarding <script preamble>
となる
エラーメッセージ冒頭が違うのは何故?
599デフォルトの名無しさん:2008/12/13(土) 15:09:29
なんか結局Java7にクロージャ入らないらしいので
結構本当にScalaの時代が到来するのではないか。
600デフォルトの名無しさん:2008/12/13(土) 16:38:09
ないないw
エッジな人達はとっくに関数型に行ってるし
そうでない人にScalaは無理
下級兵士はこれからもJavaだよ
601デフォルトの名無しさん:2008/12/13(土) 17:03:06
俺もScalaの時代が来るかについては否定的だけど
Javaな人に関数型の考え方を知ってもらう教材としてScalaは悪く無いと思う
適切なドキュメントさえあればScalaを学ぶのはそう難しいことではない
602デフォルトの名無しさん:2008/12/13(土) 19:49:40
エッヂな人達って関数型に行ってもやっぱり実際に物作るのはC++とかスクリプトとかじゃないの?
603デフォルトの名無しさん:2008/12/13(土) 20:37:13
エッチな人なので関数型言語でWEBクローラつくりました
604デフォルトの名無しさん:2008/12/13(土) 22:32:32
>>599
RubyでいうRuby on Railsのようなキラーライブラリの爆発のようなもの必要だな

Liftはあるが、採用実績はまだこれからだ
Lift Web Framework: Home
http://demo.liftweb.net/

↓後はLiftのようなものを流行らせるなら、こういう記事がもっと増えて、
InfoQ: David Pollak氏 lift と Scala を語る
http://www.infoq.com/jp/news/2008/03/liftweb

さらにこういう本まで出版しないと
Amazon.co.jp: JavaからRubyへ ―マネージャのための実践移行ガイド: Bruce A. Tate, 角谷 信太郎: 本
http://www.amazon.co.jp/dp/4873113202
http://images-jp.amazon.com/images/P/4873113202.09.MZZZZZZZZZ.jpg

おれ自身はRuby好きだけど、静的の魅力も知っているとScalaにすごく期待したくなるわけだよ
605デフォルトの名無しさん:2008/12/13(土) 22:38:38
liftよりWeb Flavorに期待してる。あと、WicketはJavaよりScalaの方が書き易そうな気がするんだ。
606デフォルトの名無しさん:2008/12/13(土) 22:46:11
昔はEJBが駄目すぎたけど今や
生産性なんて言語やフレームワークでそんなに違うかって思う
それより絶対性能の高さや簡単に数十台規模のシステムを開発できる
フレームワークでも作ってくれた方がありがたい
607デフォルトの名無しさん:2008/12/14(日) 00:54:45
>>601
Javaな人に関数型を知ってもらうなら、Groovyでどうよ?
608デフォルトの名無しさん:2008/12/14(日) 01:56:17
>>606
実際は大して違わないんですよ。

それよりも大事なのは
10分でブログが作れます、的なアトラクションや
コードが少なくてすみます、的な表向きな利点(実際はテストコードてんこもりで大して変わらん)

他に・・・

何がいると思いますか?
609デフォルトの名無しさん:2008/12/14(日) 05:05:36
>>607
Groovyは関数型の要素が少な過ぎると思う。無名関数くらいじゃない?
しかも、そのくらいなら今どきの言語のほとんどが持っている機能だし
それにGroovyは関数型的な(immutableな)データ構造を作成するのを助けてくれないよね
Scalaは関数型的なデータ構造を作りやすい構文になってるので、その点でもScalaの
方が良いと思う
610デフォルトの名無しさん:2008/12/14(日) 09:48:57
「関数型的なデータ構造」なんて曖昧な言葉は使わずに、
「代数的データ構造」と言いましょう。
611デフォルトの名無しさん:2008/12/14(日) 11:17:44
>>610
代数的データ構造と言っちゃうとかなり範囲を限定しちゃうでしょ
immutableなデータ構造全般を指すつもりで関数型的なデータ構造と書いた
612デフォルトの名無しさん:2008/12/14(日) 11:29:23
コンストくらいしかないような
613デフォルトの名無しさん:2008/12/14(日) 23:07:17
>>598
Ubuntuでsynapticから入れたんですけど、
エラーになるんです。

$ scala -version
Scala code runner version unknown version -- (c) 2002-2006 LAMP/EPFL

こんなになるんです。
614デフォルトの名無しさん:2008/12/15(月) 00:37:57
2.3.0 のようです
ttp://ubuntuforums.org/showthread.php?t=662629
ちなみに Debian の Etch も 2.3.0

Java 系はプラットフォームを汚すことはめったにないので、
Scala ホームサイトから直落としでも良いかと
Debian の Java は GNU 系に力を入れてるんで、 Sun 系の
方はまだまだです
615デフォルトの名無しさん:2008/12/15(月) 20:28:40
>>614
アドバイスありがとうございます。
tar落としてきてやってみたらうまくいきました。
616デフォルトの名無しさん:2008/12/17(水) 13:37:24
617デフォルトの名無しさん:2008/12/17(水) 21:15:12
>>616
最初の学習曲線が厳しいようだ
私は Odersky の文章のまずさ (英語ネイティブでないのでしかたないのだが)
が最初にして最大の壁になるだろうな、と言語仕様を読んでて思ったが
618デフォルトの名無しさん:2008/12/17(水) 23:58:38
>>617
俺は英語能力あまり無いのでOderskyの文章のどの辺がまずいのかあまり
よくわからんかったのだが、たとえば言語仕様のどの辺の文章?
619デフォルトの名無しさん:2008/12/18(木) 20:26:02
どの辺というか、全体的に大ざっぱすぎたり専門的すぎたり、てか
書きぶりなどからして文章書いてる時間的余裕がなさげな感じ
明白なミスはほとんどないんだけど (616 紹介中の文章で can learning と
かあってわらたw)、肝心なところで何十回も読まないと何が言いたい
のか的を得なかったり、もっと簡単に言えるところを妙にまわりくどく
表現したり
まあさすがに数十回も読み直すうちに慣れましたが
(だから、例の本も当人が書くと知ってちょっと不安に思いますた、買う
予定ないけど)
620デフォルトの名無しさん:2008/12/18(木) 22:55:36
私は、どうしてこういう機能や文法が必要なのか、
その説明が少ないんじゃないかなと思いました。
特に代数データタイプに通じてない人は
何が何やらさっぱり分からないんじゃないかと。
どうしてこういう形式を採用したのかが。
621デフォルトの名無しさん:2008/12/19(金) 07:48:40
仕様書はどこでも大体そんなもんでしょう。By Exampleは読んだ?
622620:2008/12/19(金) 11:19:41
http://www.scala-lang.org/node/143
も結構よんでいるから俺は全然問題ない。
ただこういうのを読まずに始めたい人、
代数データタイプの知識のない人、
そういう人への「解説」がない。
623デフォルトの名無しさん:2008/12/19(金) 19:32:43
英語に文句を言う前に
「的を得ない」という間違った日本語を使わないようにしようぜ。
624デフォルトの名無しさん:2008/12/19(金) 20:04:29
scalaの公式サイトに雪が降ってるじゃないか!
625デフォルトの名無しさん:2008/12/19(金) 20:06:17
凄い!!
626619:2008/12/20(土) 12:41:14
>621
てか、英語日本語ともネット上で読めるものはすべて読みました、でも結局、
622 さんの言うように、OCaml、Haskell さらにジョイン計算理論まで目を通した
上で読み返してはじめて得心しました
ちなみにそんな私の Scala 評価は、
増築しまくりな OCaml よりはすっきり
原理原則にこだわって常時遅延評価を意識する必要が (少なくとも使用初
期には) ある Haskell よりは気が楽
オブジェクト指向はジョイン計算の具現と知って納得
といった感じス
627デフォルトの名無しさん:2008/12/20(土) 13:02:53
>>626
他の言語の仕様書(英語)は読んでみたことある?
俺はScalaの言語仕様の文章が特にわかりにくいとは感じなかったな。
628619:2008/12/20(土) 13:05:01
>623
古来中国では「的を射ない」ことを「失鵠」とも表現していました (鵠 はこの場合的の
中心の黒丸のこと; 正鵠など)
だから「失う = 得ない」で「漢字の用法」としては必ずしも間違っておらず、事実厳密
な議論では「どちらも可」となっているようです
ただなるほど国語辞典などでは「的を射る」の方しか載ってないので、「普通の日本
語」としては「的を得ない」は非推奨、ということになるようです
実際には「的を得ない」の方がはるかに広く使われてるようですが
629619:2008/12/20(土) 13:08:52
>>627
Java、ECMAScript と E4X をざっと
ほかは Scheme や Haskell などは日本語訳でだけス
てか、これらの文章が良すぎだったのかな?
630デフォルトの名無しさん:2008/12/20(土) 13:34:20
>>629
PrologのISO規格書が面白いのではないか。スタックモデルで説明している。
BNFも併記されてたと思うけど。
631619:2008/12/20(土) 13:44:50
Prolog は、MSX のころに 98 用 BASIC で記述されたミニマム Prolog を移植して
ちょっと遊んで以来
ちなみに自分初の処理系移植実装な経験 (懐
もしかして誤解されてるかもですが、別に言語仕様マニアではなく、Scala では
チュートリアルでも ByExample でも「全体像」がさっぱり会得できなくてしかたな
く言語仕様にトライするしかなかっただけなのでス
632デフォルトの名無しさん:2008/12/20(土) 14:58:39
まあ少しずつやっていきなよ。
633デフォルトの名無しさん:2008/12/20(土) 15:34:12
>>628
漱石枕流乙
634デフォルトの名無しさん:2008/12/20(土) 18:45:34
ジョイン計算理論って何よ
635デフォルトの名無しさん:2008/12/20(土) 19:33:44
>>634
たぶんJoin-calculus
http://en.wikipedia.org/wiki/Join-calculus
のことだと思う。全然知らないけど、分散計算の形式的な計算モデルの一つらしい
636デフォルトの名無しさん:2008/12/20(土) 19:57:19
>>634
ラムダ計算を並行性の観点から鍛え直したのがパイ計算
ttp://web.yl.is.s.u-tokyo.ac.jp/kobalab/kadai99/picalc.html
で、それにさらに場所階層性を導入したのがジョイン計算
ttp://jijixi.azito.com/cgi-bin/diary/index.rb?date=20070531
(すごい分かりやすい pdf があったけどパスワード封鎖されたようで、
現状で日本語での記事はこの程度しか見あたらず、2 項目の JoCaml
の部分)
ちなみに OCaml から JoCaml を作る過程で練り上げられた理論っぽい
637デフォルトの名無しさん:2008/12/20(土) 20:38:54
なるほど
Scalaのどの辺がそれに基づいてるの
638デフォルトの名無しさん:2008/12/21(日) 00:30:03
「Scala開眼」を書いた人がこの中にいるな
639620:2008/12/21(日) 00:58:28
>>637
Scala.Actorsとか。
こういうのは仕様書やライブラリのAPI見れば分かる話じゃないよ。
知っているのと知らないのでは理解の速度が全然違うし、
モデルの把握もしやすくなる。

>>626の言うようにScalaはいろいろといいところがあるんだけど、
解説文が少なくてあまり理解されてないと思う。
まあ>>622にある論文読めばいいんだけどw

640636:2008/12/21(日) 11:12:25
Scala のオブジェクト指向導入は ML 系からのアバウトな逸脱ではなく、ジョイン
計算の場所階層性 (プロセスは「場所」に属し、チャネルはその場所階層を上
位へとさかのぼりつつ目的のプロセスを検索する) をクラス階層と解釈しての
きちんとした理論を背景とするものである、ということ
これで何がうれしいかというと、プログラムの実行時エラー皆無性が計算で事
前に証明可能になる、つまり静的型のエラー回避性が動的結合にも延長でき
るようになる
ということらしい
641デフォルトの名無しさん:2008/12/21(日) 19:37:52
> つまり静的型のエラー回避性が動的結合にも延長できるようになる

面白そうですが、今の型システムで回避できなくて、join計算で回避できる
ようなエラーってどういうもの?
642640:2008/12/21(日) 20:19:02
先の今は見れない pdf では純粋にプロセス間通信に限ればそこにおける
予期せぬエラーが理論上ゼロとなることを証明してました 、たしか
むろん、ハードのエラーとかプロセス間通信以外に起因するエラーは回避
不能なはずですが
ちなみに、パイ計算の方はたしか理論上どうしても無限回帰になってしま
う場合があったはず (非理論的なメタ制約を与えれば回避できるようですが)
643デフォルトの名無しさん:2008/12/22(月) 13:02:43
>>639
Actorとπは別もんだろー。
644デフォルトの名無しさん:2008/12/22(月) 18:35:11
Scalaのpattern matchingは、
Join calculusとの関係が深いです。例えば、
ALGEBRAIC PATTERN MATCHING IN JOIN CALCULUS
http://arxiv.org/pdf/0802.4018
そのpattern matchingを使えば、
多くの並列計算モデルが、
「ライブラリとして」実装できるというのが、
Scalaの核の一つです。
Scala.Actorsはその実装の一つで、
ライブラリのソースも公開されています。
ちなみにお父さん言語のFunnelでは、
もっとJoin calculus丸出しの文法でした。
645デフォルトの名無しさん:2008/12/23(火) 01:09:04
【Programing in Scala】ついに届いた(笑)

自主学習進みすぎて、最早入門書は要らないんだがな・・
646デフォルトの名無しさん:2008/12/23(火) 11:24:49
ついに購入者が!!
どこで注文したの?
647デフォルトの名無しさん:2008/12/23(火) 17:24:59
>>646
Artimaのサイトで9月くらいから予約済
648556:2008/12/23(火) 23:14:15
649デフォルトの名無しさん:2008/12/23(火) 23:33:16
ちゃんと日本にも発送してくれるんだ
かなり待たされたね

で、結局Amazon.co.jpではいつまでたっても買えないんだろうか??
650デフォルトの名無しさん:2008/12/24(水) 07:02:59
Scalaで実行時にScalaのソースファイルをコンパイルして
出来たクラスのメソッドをリフレクションで実行したい時ってどんな風に書く?
651デフォルトの名無しさん:2008/12/24(水) 09:08:48
>>624
ほっとくとめっちゃCPU食うよ
職場着いたら部屋が微妙に暖かかった…
652デフォルトの名無しさん:2008/12/24(水) 16:46:47
653デフォルトの名無しさん:2008/12/24(水) 21:57:01
>>650
Scala コンパイラソースの
scala/tools/nsc/Interpreter.java interpret メソッド (475 - 520 行)
427 - 432 には compileSources、437 - 438 には compileString なんてメソッドも
ただし当然 scala-compiler.jar もクラスパス組み込みのこと
654653:2008/12/24(水) 22:00:54
あと、883 - 898 の loadAndRun: メソッドで名前どおりリフレクションロード & 実行
655デフォルトの名無しさん:2008/12/24(水) 22:11:43
>>653-654
thx!
656デフォルトの名無しさん:2008/12/25(木) 10:19:00
http://www.ibm.com/developerworks/jp/java/library/j-scala04298.html
>trait が実際にクラスの一部として組み込まれるまで
>trait の振る舞いの定義はチェックされません。
>あるいは別の言い方をすれば、trait を使用するクラス定義の中に
>組み込まれるまで適切さをチェックされないメソッドを定義することができます。

これはどういう意味か教えてください

あとclassに出来てtraitに出来ないことってnewだけで、
他は何でも出来るという理解でいいのでしょうか
657デフォルトの名無しさん:2008/12/25(木) 11:07:52
「late binding」ってことだけど。
C++0xだとtemplate/conceptで使うlate_checkってキーワードが増えてます。
これがないと、

> あとclassに出来てtraitに出来ないことってnewだけで、
> 他は何でも出来るという理解でいいのでしょうか

となって全く使えない。
658657:2008/12/25(木) 11:49:07
ibm.comが調子悪かったからみれなかったけど、
具体例でちゃんと説明書いてあるじゃん。
良く読みこなそう!

C++はブロックごとに指定。

template <Semigroup T>
T add(T lhs, T rhs)
{
return x + y; // Semigroup<T>::operator+
}

template <Semigroup T>
T add(T lhs, T rhs)
{
late_check {
return x + y; // class Tのoperator+
}
}

659デフォルトの名無しさん:2008/12/25(木) 11:53:12
C++ 0xのlate_checkはコンセプトじゃなくて
生成したソースコードで判断するというものですよね
traitはそれに近いようなことをやってるということですか?

具体的にどういうコードを書けば遅延バインディングされるんですか?
660デフォルトの名無しさん:2008/12/25(木) 13:05:13
661デフォルトの名無しさん:2008/12/25(木) 13:10:45
>>660
>trait が実際にクラスの一部として組み込まれるまで
>trait の振る舞いの定義はチェックされません。
>あるいは別の言い方をすれば、trait を使用するクラス定義の中に
>組み込まれるまで適切さをチェックされないメソッドを定義することができます。

この文章以外は分かりました
traitのメソッドでも定義されていない変数なんかを使えば普通にコンパイルエラーになるので
適切さをチェックされないメソッドというのがどんなものなのかが分からないのです
662デフォルトの名無しさん:2008/12/26(金) 16:30:05
trait 中の定義は、実際にはそれを実装するクラスか、あるいはスーパークラス
内のプライベートメンバとしてその本体は別名定義され、trait 中のシグネチャが
それにアクセスするゲッタセッタの形になります
また、trait からはそれが指定される位置以前のほかの trait などの名前が見え
るようになっています。このため、指定順を入れ替えると動作が変わることもあ
りえます
663アク禁解禁:2008/12/27(土) 16:40:54
>>661
Orderd[A]の例だと
def compare(that: A): Int
の定義の存在はチェックされずに、Ordered[A]をコンパイルできます。
Object withするまで定義の存在はチェックされないわけです。
宣言の正当性はチェックされているのですが。
664デフォルトの名無しさん:2008/12/27(土) 22:36:35
scala.xml.NodeSeqの\\メソッドでXPath式っぽいのをかけるけど
これXPathにしなかったのはなんでだろう。
素直にXPathが使えればもっと簡潔にかけるのに。
あと属性のパターンマッチできないのも中途半端。これは属性定義が順序をもたないからだろうか?
665デフォルトの名無しさん:2008/12/27(土) 22:38:44
>>662-663
なるほどありがとうございます
666デフォルトの名無しさん:2008/12/28(日) 10:58:57
XPathを完全に実装しようとおもったらノードの構造をZipperとかにしないといけなくなる。
667デフォルトの名無しさん:2008/12/28(日) 20:52:47
本家サイトで XML の鉄人の参加を募集してることからして、そっちの方は
まだ十分にカバーできてないっぽい感じ
668デフォルトの名無しさん:2008/12/28(日) 21:23:08
>>666はよく考えたら違うな。
XPathをフル実装してかつ不変な構造にしたかったら、だな。
なんか関数型言語脳になってきたのかもしれん。
669デフォルトの名無しさん:2009/01/12(月) 12:58:59
Scala 2.7.3 RC2 キタ!
670デフォルトの名無しさん:2009/01/14(水) 22:12:08
2.7.3 finalキタ
671デフォルトの名無しさん:2009/01/21(水) 21:09:51
なんかliftのMLでもmartin oderskyがXMLライブラリメンテナの勧誘活動してたけどそんなに深刻なんかいな。
ScalaチームでXMLの研究してた人1人しかいなかったの?
672デフォルトの名無しさん:2009/01/22(木) 00:07:58
XMLまわりは下手に言語仕様に組み込むより、XSLをDSLとして扱えるとかでよくね?
今の仕様がいけてるとは思えん。中途半端な独自仕様はかんべん。
673672:2009/01/22(木) 00:10:30
「言語仕様」と書いたのは誤解をうけそうだけど、そのへんニュアンスで。
674デフォルトの名無しさん:2009/01/23(金) 13:18:43
>>671
最近、YAMLやJSONに人が流れてませんかね。
下手すりゃXMLはSGML, ASN.1の後を追うことになっちゃう。
XHTML→HTML5って流れもあるし。
675デフォルトの名無しさん:2009/01/23(金) 13:20:36
無知乙。HTML5はXHTMLでもある
676デフォルトの名無しさん:2009/01/23(金) 14:53:30
XMLでないHTMLは4で打ち止めでXHTMLオンリーのはず(by w3c)だったのに、
WHATWGが立ち上がって、W3Cの方向性を変えたんだよ。
詳しくは↓あたりを読んでね。
http://www.html5.jp/trans/whatwg_html5faq.html#What_is_the_WHATWG.3F

well-formedでないHTML排除は延期された。永遠に延期かもしれない。
677デフォルトの名無しさん:2009/01/23(金) 20:46:11
XMLって立ち上がりの時期はいけすかない感じだったけど
なんだかんだでスキーマとか数学的基礎とか処理効率とかについて
頭のいい人たちの研究が蓄積されてるんじゃないの?
それが流行でYAMLやJSONに置き換わるっていうとなんかもったいないなあ。
678デフォルトの名無しさん:2009/01/23(金) 21:07:01
XMLが苦もなく扱える人なら、Lispで事足りるんじゃないだろうか。
679デフォルトの名無しさん:2009/01/23(金) 23:45:11
>>676
そのドキュメントにもXHTMLシリアライゼーションのこと書いてあるだろ
HTML5でXHTMLが消える訳じゃない。XHTMLの未来もHTML5なんだよ
残念ながらXHTML2.0に希望はない
680デフォルトの名無しさん:2009/01/24(土) 00:14:40
span.xxsmall {font-size: xx-small; }
<span class="xxsmall">XHTMLの将来</span>
681デフォルトの名無しさん:2009/01/25(日) 22:28:26
Programming Scalaってサブタイトルにマルチコア云々って書いてある割にページ数は少なそう
682 :2009/01/25(日) 22:42:31
amazon.co.jpでProgramming in Scalaが注文できるようになってるね。
在庫切れになってるけどカートには入れられる。
683デフォルトの名無しさん:2009/01/30(金) 19:24:22
すから↑
スカ↑ラ(ドラクエ風)

アクセントはどこよ
684デフォルトの名無しさん:2009/01/30(金) 19:40:34
どうでも良いことだが、俺にとってのドラクエ風はス↑カ↓ラ↓
685デフォルトの名無しさん:2009/01/30(金) 22:09:27
ス↓カ↑ラ↑といえばラ・スカーラ。
まだ「ディスコ」と言われていた時代だ。
686デフォルトの名無しさん:2009/01/31(土) 12:35:08
Odersky 氏が「スケイラでも可」のようなことを言ってたビデオがあったから、
スカ↑ラの方かと
687デフォルトの名無しさん:2009/01/31(土) 13:14:41
スカラはイギリス的
スケイラはアメリカ的
スカイラはオーストラリア的
688,,・´∀`・,,)っ-○◎●:2009/01/31(土) 21:24:08
scアァは日本的
689 :2009/02/04(水) 10:00:11
Scala初心者なんですけど
val a = List(1,2,3,4)

とした後

a.foreach( println( _ ) )
a.foreach( x => println( x + 3) )

はエラーにならないのに

a.foreach( println( _ + 3 ))

はエラーになります。どうしてですか?
690デフォルトの名無しさん:2009/02/04(水) 13:01:34
a.foreach( println( x => x + 3 ) ) 
と展開さえてエラーになってるみたいだね。
理由や原理は分からないけど。
691 :2009/02/04(水) 17:25:00
expanded functionなんたらっていうエラーメッセージはそういう意味なんですか。
この略記法みたいのは、展開のしくみがよくわからないから複雑なのには自重しときますか。
ありがとうございました。
692 :2009/02/04(水) 17:40:31
 _ を使った式ががprintlnに対して展開されてるってことですね。foreachではなく。
そう考えるとa.foreach(println(_))はよくforeachに対して展開されてますね。
693デフォルトの名無しさん:2009/02/04(水) 21:19:14
どう展開されるかはコンパイラの気分次第ってことか?
694デフォルトの名無しさん:2009/02/04(水) 21:30:45
println( _ + 3 ) は「+ 3」を解決するために _ を評価しなければならなくなる
からでわ?
println( _ ) だと println を評価するまで _ の評価を遅延できるのに対して
695デフォルトの名無しさん:2009/02/04(水) 21:42:00
_が予約語ってどうなの?
困らない?
696デフォルトの名無しさん:2009/02/04(水) 21:51:03
_ 単独で変数名とかクラス名にするやつがいるとは思えないんだが。
697デフォルトの名無しさん:2009/02/04(水) 21:57:14
_の正確な意味を知るにはScala言語仕様の6.23 Anonymous Functionの
Placeholder Syntaxを読むのが良いと思う。特に英語圏のブログでScala
やってる人が多用してる気がするけど、正確な意味を解説した記事ってないんだよな。

不正確だけどおおざっぱな説明としては、_を囲む最も内側の式が無名関数化される。
だから、println(_)だと、(x) => println(x)になるけど(_を囲む一番内側の式がprintln(_)
だから)、println(_ + 3)はprintln((x) => x + 3)になる(_を囲む一番内側の式が_ + 3だから)
あと、無名関数化される式はsyntactic category(文法定義上の非終端記号みたいなもの)が
Exprである必要がある。

基本的に、_がどう展開されるかは純粋に構文的に決まり、型とかは一切関係しない。
698デフォルトの名無しさん:2009/02/04(水) 23:17:55
println((_)) とかやると内側の括弧で阻害できるのか?
699デフォルトの名無しさん:2009/02/04(水) 23:34:42
>>698
試してみるとわかるけど、それはできない。
仕様書にはproperly containsという文言があるんだけど
単に式を囲む(_)は構文解析で_と同じになっちゃって、
(_) properly contains _とはみなされないということだと思う。
700 :2009/02/05(木) 00:11:19
>>697
おお、わかりやすい説明ありがとう。
それでちっとまた実験してみた。

val a = List(1,2,3,4);

a.map( x => x)
はエラーにならないけど

a.map( _ )
はエラーになった。

この場合は
a.map( _ + 3)
にするとエラーにならない。
なるほど。
701デフォルトの名無しさん:2009/02/05(木) 00:23:42
酔っぱらっているので一つだけ。(>>697の括弧が構文解析できないレベル)
Scalaの_は、C++のboost/bind.hppの_1, _2, _3から来ているんだと思う。
>>697が解説してくれているけどそっくり。おやすみ
702 :2009/02/05(木) 00:32:11
しかし算術式はなにかとくべつなのかな?

a.filter( 2 < 1 + _ )

はエラーにならない。
1 + _ が最も内側の式ではなく 2 < 1 + _を最も内側の式と見てくれる。

でも
a.filter( (2).<( 1 + _ )  )

だと1 + _ を最も内側の式と見てエラーになる。

2 < 3 は (2).<(3)と同じことだと読んだような気がするけど 、上の場合は挙動が違う。
703 :2009/02/05(木) 00:35:41
あ、でも

a.filter( 2 < 1 + _ )
はエラーにならないけど

a.filter( 2 < (1 + _ ) )
はエラーになる。
この場合は ( 1 + _ )が最も内側の式とみなされるから。
704 :2009/02/05(木) 00:42:17
明示的にかっこでくくちゃうと、そこでもっとも内側の式とみなされるけど
演算子の優先順位のためにかっこがいらなければセーフなのか。
705 :2009/02/05(木) 00:58:57
ただし明示的な括弧といっても ( _ )は意味がないl。 _ とおなじ。
それ以外の場合は括弧の段階で一番内側の式とみなされる。
706697:2009/02/05(木) 01:01:19
>>701
>>702
その辺の挙動は、>>697で最後にさらっと書いたsyntactic categoryというのが絡んでくる。
>>697では最も内側の式という風に書いたけど、実はもうちょっと正確に言うと、もっとも内側で、
syntactic categoryがExprの式が無名関数化される。

まず、
a.filter(2 < 1 + _)
についてだが、1 + _の部分だけではInfixExprとみなされる。その外側の
2 < 1 + _も同じくInfixExprだが、メソッド呼び出しの引数の位置に来ることによって
Exprに昇格(適当にでっち上げた用語だが)し、結果として、2 < 1 + _が(x) => (2 < 1 + _)
のように無名関数化される。

a.filter( (2).<( 1 + _ )  )

については、1 + _は同様にInfixExprだが、メソッド呼び出し引数の括弧の位置に
現れたことによって、Exprに昇格してしまう。そのため、1 + _が無名関数化される。

a.filter( 2 < (1 + _ ) )

でも、やはり1 + _はInfixExprだが、式をグルーピングする括弧があることによって、
Exprに昇格してしまう。そのため、1 + _が無名関数化される。
707デフォルトの名無しさん:2009/02/05(木) 01:01:43
_はどのくらい強いの?
括弧以外は突き抜けられるぐらい強いの?
708697:2009/02/05(木) 01:04:40
>>707
基本的にはメソッド呼び出しの引数の括弧 or 式のグルーピングの括弧が区切りになっているという
認識で良いと思う。あとは、使っているとなんとなくわかるようになってくる感じ。上では言語仕様の
記述を元に挙動を説明したけど、そこまで知っていなくてもまあだいじょうぶだと思う。
709 :2009/02/05(木) 01:11:54
>>706
697さん、詳しくわかりやすくどうもありがとう!
すっきりして寝れます。
710 :2009/02/05(木) 12:18:40
amazon.co.jpの洋書でScala本、ただいま在庫切れだけど注文できるようになってて人気がすごいぞ。

http://www.amazon.co.jp/Programming-Scala-Comprehensive-Step-step/dp/0981531601/ref=sr_1_2?ie=UTF8&s=english-books&qid=1233803774&sr=1-2

Amazon.co.jp ランキング: 洋書 - 455位 (洋書のベストセラーを見る)
各カテゴリー内でのランキング:

1位 ─ 洋書 > Computers & Internet > Programming > Java
2位 ─ 洋書 > Computers & Internet > Programming > Software Design, Testing & Engineering > Object-Oriented Design
2位 ─ 洋書 > Computers & Internet > Programming > Languages & Tools

すげー!
711デフォルトの名無しさん:2009/02/05(木) 12:33:07
>>710
米国での期待の大きさが現れてる。同時に、
Haskellの棺桶の釘を打つ音でもある。
712デフォルトの名無しさん:2009/02/05(木) 15:54:30
そういう二者選択は馬鹿げてると思うよ。
713デフォルトの名無しさん:2009/02/05(木) 15:58:15
>>712
あくまで、米国のソフトウェア界のはなし。
714デフォルトの名無しさん:2009/02/05(木) 16:55:08
> 米国のソフトウェア界



715デフォルトの名無しさん:2009/02/05(木) 23:21:10
>>712
洋書を買うのは物好きだけだろjk

現在のランク:
6位 ─ 洋書 > Computers & Internet > Programming > Software Design, Testing & Engineering > Object-Oriented Design
8位 ─ 洋書 > Computers & Internet > Programming > Java
28位 ─ 洋書 > Computers & Internet > Programming > Languages & Tools
716デフォルトの名無しさん:2009/02/06(金) 06:46:27
日本での順位に米国の話をレスとしたのがまちがい。>>711は撤回します。
717 :2009/02/07(土) 15:09:56
ScalaにJavaみたいなenumないのですか?

Enumerationってのがあるみたいなのですが

object Main extends Application {

   object WeekDays extends Enumeration {
    val Mon, Tue, Wed, Thu, Fri, Sat, Sun = Value
  }

  def isWorkingDay(d: WeekDays.Value) =
     ! (d == WeekDays.Sat || d == WeekDays.Sun)

   WeekDays filter (isWorkingDay) foreach { d => Console.println(d) }
}



printlnでの出力もMain$WeekDays(4)という形式です。
JavaのenumだったらFriとかよみやすい値です。メンバを加えたりもできました。

Javaのenum使えないのですか?
718デフォルトの名無しさん:2009/02/07(土) 15:51:00
多少コード量が増えるけど、

http://blogtrader.net/page/dcaoyuan/entry/erlang_plugin_for_netbeans_in
を参考にして、Weekdaysにメンバを追加するか、

abstract sealed class Weekdays
object Weekdays {
case object Mon extends Weekdays
case object Tue extends Weekdays
case object Wed extends Weekdays
case object Thu extends Weekdays
case object Fri extends Weekdays
case object Sat extends Weekdays
case object Sun extends Weekdays
}
val x: Weekdays = Weekdays.Mon
println(x) //Mon
のようにして、case objectを使う手段がある。
719 :2009/02/07(土) 16:05:59
>>718

ブログのよりあなたのやり方のほうがJavaのenumっぽいですよね。
実質、個々のenum値が独自クラスのシングルトンになってるあたり。
でもJavaの場合はコンパイラが自動的にやってくれるので短く書けるけどScalaだとちょっと面倒ですね。
使いようによってはcase classのぶん便利なこともあるのかな。
ちょっと気になって質問したので、具体的にどう使うか目的があって質問したわけじゃないけど。

詳しくどうもありがとうございました。
720デフォルトの名無しさん:2009/02/07(土) 22:16:19
enumにメソッド追加ってかなりJava独自じゃないですか?
必要ない気がするんですけどJavaラーは活用してるんですかね。
721 :2009/02/08(日) 20:04:19
2版のEffective Javaに活用した例があっておもしらかった記憶があるけど
自分自身はつかったことない。
722デフォルトの名無しさん:2009/02/08(日) 22:10:21
enumのメソッド追加は便利。
ステートパターンが書きやすい。
723デフォルトの名無しさん:2009/02/08(日) 22:45:31
メモリ効率を重視する必要がある時に使ってる。
自分でナンバリングして整数型で扱うよりずっと型は強い。
724デフォルトの名無しさん:2009/02/08(日) 23:51:01
Scalaって実際どんな時に使うもんなんでしょ。
Javaだとサーバーサイドでしか使えないイメージがあるけど・・・
みんな基幹とか、webサービスのサーバー側に使ってたりするのかな?
webフレームワークはleftくらいしか見かけないけど
725デフォルトの名無しさん:2009/02/09(月) 00:04:57
>>724
先入観で凝り固まりたいように見える
726デフォルトの名無しさん:2009/02/09(月) 00:47:57
>>725
うーん、実際の話をしているんですが、どうなんでしょうか?
727デフォルトの名無しさん:2009/02/09(月) 00:52:19
>>724
> Javaだとサーバーサイドでしか使えないイメージがあるけど・・・

こういう人に答えても仕方ないしね。
728デフォルトの名無しさん:2009/02/09(月) 01:44:45
煽りを聞きたいのではないのですが・・・
729デフォルトの名無しさん:2009/02/09(月) 02:12:43
そもそもScalaがJavaで書かれているのに、
サーバーサイドしか使えないってw
730デフォルトの名無しさん:2009/02/10(火) 01:12:49
>>724

スレの上の方でも議論があるけど、π計算の延長上にある言語だから
SOAとかメチャ無茶やりやすいぞ。

デスクトップクライアントが作りたいならSwingでやればいい
SwingがPoorで嫌だと言うのであれば、3月まで待って、Qt4.5(LGPL)を使いなさん
731デフォルトの名無しさん:2009/02/10(火) 01:19:46
>>729
>そもそもScalaがJavaで書かれているのに、
あんまりいい表現じゃないな・・・
732デフォルトの名無しさん:2009/02/10(火) 02:38:38
>>724
liftだろ
733デフォルトの名無しさん:2009/02/10(火) 10:45:22
というかソース見ればわかるけど、今のScalaはScalaで書かれてる。
1.XのときはJavaで書かれてたらしいけどね。
734デフォルトの名無しさん:2009/02/10(火) 20:20:42
Scala をコンパイルするための Scala をコンパイルするための・・・
735デフォルトの名無しさん:2009/02/11(水) 09:02:15
なに!ScalaはJVMで動作するのか!?
無駄スグルwww 一体何のために。。。
736デフォルトの名無しさん:2009/02/11(水) 09:17:32
無知すぎるwww
737デフォルトの名無しさん:2009/02/11(水) 09:52:40
JVMつながりと言えば、Clojureのスレがないな……。
まぁS式嫌いなのでどうでもいいが。
738724:2009/02/11(水) 10:06:39
ありがとうございます。
>>733 を見てうやむやが氷解しました。

Scalaを書くためのScala。
何か関数言語的な美しいひびきを感じます。
使う気がしてきました。
739デフォルトの名無しさん:2009/02/12(木) 02:57:16
+ や * はメソッドだって聞いたけど、
2 + 3 * 4 は 14ってちゃんと評価してくれるんだね
メソッドチェーンになるから、20が戻ってくると思った

これって遅延評価のおかげ?
Scalaのソースをちゃんと読まないといけないんだろうけど
740デフォルトの名無しさん:2009/02/12(木) 03:21:54
+や*がメソッドだというのは間違ってないけど、中置式のメソッド呼び出しに
関しては、演算子の最初の1文字で優先順位が決まるというルールになってる。
このルールのおかげで、算術式に関しては直感的な動作をしてくれる。
Scala言語仕様6.12.3 Infix Operationsによると、優先順位は以下のようになってる。

letter < '|' < '^' < '&' < '<', '>' < '=', '!' < ':' < '+', '*' < '/', '%' < all other special characters

たとえば、

"HOGE" charAt 0 + 1

という式があった場合、charAtの最初の文字はletterなので、+よりも演算子としての優先順位は低い。
そのため、

"HOGE".charAt((0).+(1))

と解釈される。
741デフォルトの名無しさん:2009/02/12(木) 03:22:54
訂正。s/letter/all letters/
742740:2009/02/12(木) 03:25:55
ありゃりゃ。コピペして不等号加えるときにミスったorz
正しくは、以下。

all letters < '|' < '^' < '&' < '<', '>' < '=', '!' < ':' < '+', '-' < '*', '/', '%' < all other special characters
743739:2009/02/13(金) 00:44:52
>>740
サンクス

BigDecimalでも試したけど、ちゃんと掛け算・割り算を優先するってありがたいな
RemoteActorの動作がいまいちわからなかったり(コンパイルした後、scalaコマンドで動かないのに、javaコマンドからだったらちゃんと動くとか)
わからんことだらけなんだけど、しばらく弄ってみることにする
744デフォルトの名無しさん:2009/02/14(土) 03:01:26
RemoteActorっていったら、
メッセージ送った分だけヒープが貯まっていくのな・・

Asyncで(actor ! msg な)メッセージ送ると、反応しないことが多々ある
インタプリタで使う限りは問題ににならないけど、コンパイルした途端にダメ・・

ありえねぇ・・・(;´Д`)
745デフォルトの名無しさん:2009/02/14(土) 18:03:54
>>774
まさかとおもってやってみたら、思い切りOutOfMemoryしやがった(笑)

java.lang.OutOfMemoryError: Java heap space
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.lang.Class.getDeclaredMethod(Unknown Source)
at java.io.ObjectStreamClass.getPrivateMethod(Unknown Source)
at java.io.ObjectStreamClass.access$1700(Unknown Source)
at java.io.ObjectStreamClass$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.<init>(Unknown Source)
at java.io.ObjectStreamClass.lookup(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
746デフォルトの名無しさん:2009/02/14(土) 18:04:44
(続き)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at scala.actors.remote.JavaSerializer.serialize(JavaSerializer.scala:37)
at scala.actors.remote.NetKernel.sendToNode(NetKernel.scala:32)
at scala.actors.remote.NetKernel.namedSend(NetKernel.scala:39)
at scala.actors.remote.NetKernel.forward(NetKernel.scala:71)
at scala.actors.remote.DelegateActor$$anonfun$act$1$$anonfun$apply$1.apply(Proxy.scala:168)
at scala.actors.remote.DelegateActor$$anonfun$act$1$$anonfun$apply$1.apply(Proxy.scala:125)
at scala.actors.Reaction.run(Reaction.scala:78)
at scala.actors.Scheduler$$anon$2.run(Scheduler.scala:77)
at scala.actors.FJTaskRunner.run(Unknown Source)
747775:2009/02/14(土) 18:06:57
>>744 ですた(苦笑)

うーん、こういう不具合が未だにActor周りがver 1.0 にならない理由なのかな
2.7.2ではメモリーリークの不具合があったっていうし
748デフォルトの名無しさん:2009/02/17(火) 11:25:35
初学者にやさしい100〜500行くらいで書けるようなお題くれ
749デフォルトの名無しさん:2009/02/17(火) 11:33:01
750デフォルトの名無しさん:2009/02/17(火) 12:49:40
>>748
% 問題・・9時台から16時台(17時閉店)までの勤務表を作れ。
%
% 勤務表は1時間単位とする。
% 要員はAya、Koh、Sho の3名である。
% 最小勤務単位は2時間であり、一時間だけの勤務は認められない。
% 一人勤務は1時間までであり、もし一人勤務に就いたときは
% 次の少なくとも1時間は勤務につけない。
% 以下の時間は、それぞれ用事があり、勤務できない
% Aya・・14時台、Koh・・11時台と14時台、Sho・・9時台と11時台。
751デフォルトの名無しさん:2009/02/22(日) 03:21:25
OreillyやAPressもScala本を出すみたいだね

http://oreilly.com/catalog/9780596157746/index.html#top
http://www.apress.com/book/view/9781430219897

Oreillyのほうは、Twitterの中の人が書いて
Apressのほうは、Liftの中の人が書いてるみたいです
752デフォルトの名無しさん:2009/02/26(木) 00:15:33
>>737
Clojureは人口が少ないからね。scalaよりは。スレを作ってもarcスレみたいになりそう。
ircとgoogle groupをみてると盛りあがってるんだがね。
ScalaとClojureはライバル関係みたいだがなぁ。

ところでScalaでどのくらいの人口なの?
753デフォルトの名無しさん:2009/02/26(木) 00:57:02
clojureやarcは「yet another my own Lisp」でしょ。
面白いところはあるけど、Scalaとは無縁。
754デフォルトの名無しさん:2009/02/26(木) 01:08:45
>>753
調べた上でそういってるなら正しいが
755デフォルトの名無しさん:2009/02/26(木) 01:15:14
仮に調べてなくても正しいものは正しい。
756デフォルトの名無しさん:2009/02/26(木) 01:18:06
>>755
それは率直にいうと頭が悪いな
757753:2009/02/26(木) 01:28:37
>>753が間違っていると思う人は根拠を言ってみれば?
Scalaは静的な言語ですが、clojureやarcはそうではありません。
clojureなんて動的馬鹿といっていいような仕様です。
型システムや関数/メソッド呼び出しも全然違います。
OCaml辺りの方がずっとずっと近いです。

clojureやarcはLisp SchemeスレかARCスレがあるし、
ココで語る意味のある言語とは思えん。
758デフォルトの名無しさん:2009/03/02(月) 00:03:43
Lift 1.0が出たとか
759デフォルトの名無しさん:2009/03/02(月) 01:30:11
>>758
出ましたね。
APIドキュメントとか、Lyxで書いたドキュメントはいまいち整っていませんが・・
760デフォルトの名無しさん:2009/03/02(月) 01:34:09
Terracottaの中の人(Scala OTPの作者)が、QCon Londonで発表するスライドも
SlideShareにupされています 
ttp://www.slideshare.net/jboner/pragmatic-real-world-scala-45-min-presentation
761デフォルトの名無しさん:2009/03/05(木) 17:12:16
>>757
最近見かけたのは、 scala と clojureの共通点は java VM上の言語だってことだが
それだけじゃなくて、並列処理のことが念頭にあるみたいなのね。だからその並列処理
の考えかたの違いもあって、どっちが。。。みたいなことが話題として出てきてる。

だから、無縁だと考えるのは視点の違いから来てるね。悪いけど>>757は視野が狭いとしか
思えないね。言語の系統を語ってるだけなら無縁だからね。だから、言ってることはもっと
もなことを言ってるし、そこでライバル関係だとは誰も言わないだろう。

もっとも、たまたま、>>737で話題になって>>752で答えたにすぎないし、
対立を煽ったり、>>752>>757にあるように、他の言語をどこか馬鹿にするようなことも
言う気はないよ。
762デフォルトの名無しさん:2009/03/05(木) 17:17:59
>>761
>>752じゃなくて>>753だね。
おまけとして、
http://japan.internet.com/column/developer/20090224/26.html
でもみればいいよ。
763デフォルトの名無しさん:2009/03/05(木) 20:26:57
> あるみたいなのね
こういうの勘弁
764デフォルトの名無しさん:2009/03/05(木) 23:00:48
マギー司郎の声でよめば大丈夫だ
765デフォルトの名無しさん:2009/03/06(金) 22:53:35

ScalaはJava互換あるし、第一言語がJavaで、
Haskellもちょっとだけかじった俺なら余裕だろと思ったら、
Listのインスタンス化に2時間ハマったぞWWWWWWWW
ArrayListをnewしようとちょっとずつ構文変えて頑張ってた健気な俺涙目WWWWWWWWW

ていうか巷のブログ書いてるやつら、動くコード書いてくれよWWWW
断片だけじゃわからないからWWWWWWWWW
コンパイルする身にもなれってのWWWWWWWWWWWWWW
766デフォルトの名無しさん:2009/03/07(土) 10:41:55
マニュアル嫁
767デフォルトの名無しさん:2009/03/07(土) 11:25:33
Haskellかじったらリストのインスタンス化思い当たるんじゃん
768デフォルトの名無しさん:2009/03/07(土) 12:09:38
769デフォルトの名無しさん:2009/03/07(土) 18:28:12
リストのインスタンス化で2時間悩むとか、プログラム初心者ならともかく、どうかしてるだろ
Scala Listでぐぐって出てくる最初のページにすら、やり方出てくるぞ。
770デフォルトの名無しさん:2009/03/07(土) 19:07:59
こういうのを書きたかったんだ
List<File> list = new ArrayList<File>();

で、ググってでてくるのかね?
771デフォルトの名無しさん:2009/03/07(土) 20:28:23
ああ、すまん。Javaの方のListを作りたかったわけね。それなら、Listでぐぐっても
出てこないわ(それだと、ScalaのListが出てくるし)。調べるべきは、Listの作り方じゃなくて、
ScalaでのGenericsの使い方の方だったね。Scala Genericsでぐぐれば、色々出てくる。

var list = new ArrayList[File]
772デフォルトの名無しさん:2009/03/08(日) 11:33:00
コレクションは特別な理由がない限りScalaライブラリのを使ったほうがいいとおもうけどなあ。
773デフォルトの名無しさん:2009/03/27(金) 16:32:46
関数型言語について勉強中の者です。

関数型言語らしいプログラムの書き方ってどういうのを言うんでしょうか?
「リスト」を最初に作り、それに関数を適用して行くという形式で行くのが大事そうだ、というのは解りました。

ただ、これを読んでかえって解らなくなってしまいました。

刺激を求める技術者に捧げるScala講座---目次:ITpro
第7回 関数脳のつくり方 First Season
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20090224/325385/?ST=develop

これを書いている人はなんか理解したようなのですが、読んでもちっとも解りません。
特に
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20090224/325385/?ST=develop&P=6
>しかし,オブジェクトの技術を使わず,純粋に手続きで考えてみたのですが,頭がパニックになりそうでした。
>最初のNode(XMLタグ)を取得して,その子要素をとってループをまわす。
>その子要素がDirの場合は,childでさらにその子要素をとってループを回す。
>Fileの場合は中身のファイル名を表示する。Dirの子要素にまたDirが含まれていたら,さらにchildを適用して…。

このあたり。
手続きだって再帰すればすぐだと思うのですが。
手続きって言った場合、再帰は含まないのでしょうか?
774デフォルトの名無しさん:2009/03/27(金) 17:09:12
駄文読まずに>>8のチュートリアル翻訳版読めば?
775デフォルトの名無しさん:2009/03/27(金) 20:05:13
>>773
その文章、体裁はともかく内容としては
人に何かを説明することを目的として書かれたという感じがしない。
自分の頭を自分なりに整理してみただけの感想文という感じ。
776デフォルトの名無しさん:2009/03/27(金) 21:23:46
ScalaってJavaで作られた過去の遺産をそのまま使えるという点では素晴らしいけどさ
Scala使うなら関数型の技法を習得必要があるじゃん

だってScalaでJavaの書き方使うってんなら、Scala使う意味がないんだもん

大変残念だけど日本のほとんどのシステム開発の現場では採用されないだろうね
先鋭的な技術会社なら別だけど
777デフォルトの名無しさん:2009/03/27(金) 21:25:52
>>776
> Scala使うなら関数型の技法を習得必要があるじゃん

scalaを学べば十分
778デフォルトの名無しさん:2009/03/27(金) 21:45:34
だからScalaを習得するってことは関数型言語を習得するってことと同義だろ?

Scala使って関数型言語のメリットを利用しないってのは意味がない
Javaだけ使ってればいいんだから
学習コスト高すぎってことだ
779デフォルトの名無しさん:2009/03/27(金) 22:01:50
リストを使うっていうよりは一般的に副作用を最小化する心がけを持つといいんじゃないかな。
そして副作用のないコレクションの代表選手がリストなのでリストはよくつかわれる。
その記事で何を手続き的として想定してるかはわかんないけど、同じ再帰を使うのでも、
たとえばツリー構造からある条件で抽出するときに、
「結果を格納する変更可能なコレクションを用意しておいて再帰しながらその入れ物に追加していく」だとかなり手続き的だけど、
「再帰呼び出ししながら戻り値であるリストの和集合をとっていく」だとちょっと関数的になる、みたいな。
780デフォルトの名無しさん:2009/03/27(金) 22:02:30
scalaって関数型にしては癖が強いと思うよ。それはjavaを使った人向けに作られた
関数型言語でもあるからだよ。

日本で採用されるかどうかってのは、海外で普及して権威付けされるかどうかでしょ。
右に習えしか出来ないんだからね。先陣を切ってやるような多少?のリスクを背負っ
て進めるようなところはないだろうから。まだ、ベンチャーが育つ土壌があるならば、
可能性はあると思うが、海外で普及したあとの2、3年まちってところではないかな。

並列プログラミングが重要さを増せば変わってくると思う。

学習コストは手続き型しか知らないような人にとってみれば未知への恐怖というコスト
が高いと思うが、基本的なところは然程難しくないと思うよ。この手の事で保守的な
ことを言って無理だと言う人って、一般的に融通が利かない人の傾向があるよ。そんな
人が多いんかなぁ。プログラマってひとたちは。。。
781デフォルトの名無しさん:2009/03/27(金) 22:03:39
javaプログラマ向けの関数型言語になってるから学習コストはさほど高くないと思うんだが。
782デフォルトの名無しさん:2009/03/27(金) 22:06:29
>>778
全然そうは思わない。ScalaはScala、関数型言語ではない。
783デフォルトの名無しさん:2009/03/27(金) 22:13:56
>>780
>>782
Scalaと関数型言語の特性については無知だったようですまねぇ

でもね、俺みたいな2次請け3次請けで働いてるプログラマってプログラマの多数派なわけじゃん
そんな多数派の「現場」ではRubyすら使われる気配がないし、ましてや関数型言語なんて採用されるわけがない
ってことを言いたかっただけなんだが
784デフォルトの名無しさん:2009/03/27(金) 22:29:12
>>783
ごめん。言いすぎた。
言うようになかなか採用されないと思ってるよ。
785デフォルトの名無しさん:2009/03/27(金) 22:35:34
Scalaは関数型言語ではなくて、
関数型言語の機能、特徴[も]兼ね備えている言語。
今では特に珍しいことではない。

http://www.scala-lang.org/node/25
Introducing Scala
> It smoothly integrates features of object-oriented and functional
languages

http://www.scala-lang.org/node/1305#Func
Learning Scala
> If you come to Scala with a functional programming background
> you will find most of the more advanced functional programming
style familiar.

http://www.scala-lang.org/node/959
Book "Programming Scala"
> "Programming Scala" will show you the fundamentals of functional programming using Scala.
786デフォルトの名無しさん:2009/03/27(金) 22:41:01
ちょっと件のページのデータを踏襲した例を作ってみた。
まずこれは再帰を使ってるけど手続きっぽいでしょ。resultが順次更新されていくから。

import scala.xml._
import scala.collection.mutable._

val result = new ArrayBuffer[Node]
def find1(node: Node)(pred: Node => Boolean): Unit = {
if (pred(node)) result += node
for (child <- node.child) find1(child)(pred)
}
find1(xml) { case <file>{_*}</file> => true; case _ => false }

こうするとちょっと関数型っぽくなる。

def find2(node: Node)(pred: Node => Boolean): List[Node] = {
if (pred(node)) List(node)
else node.child.toList.map(find2(_)(pred)).flatten[Node]
}
val result = find2(xml) { case <file>{_*}</file> => true; case _ => false }

find2は便利メソッドのflatMapを使ってこう書いても同じ。

def find3(node: Node)(pred: Node => Boolean): List[Node] = {
if (pred(node)) List(node)
else node.child.toList.flatMap(find3(_)(pred))
}
787デフォルトの名無しさん:2009/03/27(金) 22:50:18
>>773
関数型言語の勉強なら「プログラミングの基礎」がいいよ。
http://www.amazon.co.jp/dp/4781911609/
788デフォルトの名無しさん:2009/03/27(金) 23:01:52
Scalaは関数型の要素抜きのGood Javaで使っても結構いい線いけてるから、
なかなか関数型まで行き着かないんだよね。
同じJavaVMで動くといってもJavaと食い合う言語だなと思ったよ。
確かに関数型だけを学びたいならHaskellやML系の言語を先にやったほうが手っ取り早いかもしれない。
789デフォルトの名無しさん:2009/03/27(金) 23:10:13
OCaml亜種のF#がC#や他の.NETグループの言語と組み合わせる前提の
設計になってるのと対比すると特徴的だな。
790デフォルトの名無しさん:2009/03/28(土) 09:22:03
http://jp.techcrunch.com/archives/20090326get-ready-for-java-on-appengine/
コンパイルしたScalaもつかえそう。
791デフォルトの名無しさん:2009/03/28(土) 09:40:47
いや、当然APIが制限されてるって。
Python版がそうであるように。
792デフォルトの名無しさん:2009/04/02(木) 02:27:10
PragmaticProgrammersのScala本がβで出たんで書いておく。

でも、Liftの中の人がAPressで出す奴のほうが出来良いな・・
言葉遣いがかなりぶっきらぼうなんだが、例文がためになる
793デフォルトの名無しさん:2009/04/02(木) 02:30:42
>>738

去年まで俺がいた部署はJython使ってたんだが何か?
794793:2009/04/02(木) 02:34:37
スマソ

× >>738>>783 だった
795デフォルトの名無しさん:2009/04/02(木) 14:20:32
>>791
実際のところはわからんが、.jarファイルをライブラリとして置けるなら
使える可能性は十分あるんじゃないか?scala-library.jarだけ同梱すればいいわけだし。
仮にそれが無理だったとしても、ProGuard使ってscala-library.jarとかもまとめて一つ
のjarにしてしまえば、原理的には可能だと思う。
796デフォルトの名無しさん:2009/04/02(木) 14:24:21
しかし、普段は寂れてるのになんか話題振られると結構レス付くんだな、このスレ。
797デフォルトの名無しさん:2009/04/02(木) 20:06:42
俺も思った
普段は過疎ってるけど結構チェックされてるんだな
798デフォルトの名無しさん:2009/04/02(木) 21:19:41
Droolsとか宣言型+Webはやってるからかな?
799デフォルトの名無しさん:2009/04/03(金) 02:26:16
>>795
だからjar置いてもそのjarから全てのAPIを使えるわけじゃない。
その辺りどうなっているかPython版で勉強してきてください。
800デフォルトの名無しさん:2009/04/03(金) 02:36:15
ちょ,ちょっとだけヒントでも
配置には特に公式サイトのFAQで〜調べればいいとか
801デフォルトの名無しさん:2009/04/03(金) 12:47:17
AppEngineのことはこっちで聞いたほうがいいかもしれない

Google App Engine
http://pc11.2ch.net/test/read.cgi/php/1207754942/
802795:2009/04/03(金) 19:09:10
>>799
Google App Engineに詳しいわけじゃないが、仮にjarに関して制限あっても
ProGuardとかFatJarとかで1jarに固めてしまえば、さすがに原理的には制限
しようが無いんじゃね?使えるJava APIに制限あると言っても、Scala処理系が
生成した.classファイルがそんなに色々なAPI使うわけじゃないし。
803デフォルトの名無しさん:2009/04/03(金) 20:17:19
http://code.google.com/appengine/docs/python/runtime.html#The_Sandbox
を読んだら>>801行けば?
まあいろいろなJVM系言語でGoogleApp版処理系(制約あり)が作られると思う。

ただスレッドを扱えない時点で、
scala.actorに依存したScalaの多くの部分が失われる。
上のJoin calculusの話とか、その辺のソースコードとかも読んで。
804デフォルトの名無しさん:2009/04/03(金) 22:21:21
むしろactorは単なるライブラリなので単純に切り離せると思うけど。。
805デフォルトの名無しさん:2009/04/03(金) 22:45:46
actorなくなるとhttpの基本ライブラリも関連も書き直しだな。
TcpServiceが使ってるから。Google Appが提供するhttp APIにしないと。
806デフォルトの名無しさん:2009/04/04(土) 00:09:47
twitterでscala使われるらしいね
807デフォルトの名無しさん:2009/04/04(土) 01:55:53
>>806
使われるというか、既に部分的には(メッセージキュー)使われてる。
808デフォルトの名無しさん:2009/04/05(日) 07:50:02
GAEでJavaが使えるようになるなんてまだ噂段階なのにここまでもりあがるとはwww
809デフォルトの名無しさん:2009/04/06(月) 07:46:44
は?
810デフォルトの名無しさん:2009/04/08(水) 19:27:49
http://www.atmarkit.co.jp/news/200904/08/gae.html
まあかなり記者の憶測入ってるけど。
811デフォルトの名無しさん:2009/04/09(木) 02:29:41
JRuby on Railsが動くんだったらLiftも動くんじゃないかなー
812デフォルトの名無しさん:2009/04/09(木) 02:37:37
clojureでも動いているから、大丈夫ちゃうか。
813デフォルトの名無しさん:2009/04/09(木) 20:50:34
http://froth-and-java.blogspot.com/2009/04/scala-on-google-appengine.html
It was fairly trivial だったそうです。
814デフォルトの名無しさん:2009/04/09(木) 22:28:51
あるある
815デフォルトの名無しさん:2009/04/10(金) 15:40:11
Twitter、Ruby on RailsからScalaへ
http://slashdot.jp/developers/09/04/10/0421223.shtml
816デフォルトの名無しさん:2009/04/11(土) 01:31:38
817デフォルトの名無しさん:2009/04/12(日) 23:35:41
ScalaとGAEについては、
http://pc11.2ch.net/test/read.cgi/php/1207754942/755
Officalブログで、「They even use alternate languages on the JVM, like Groovy, Scala, and JRuby.」
>816で
Scala
- Scala works out of the box.
- Scala Actors do not work, because they are implemented using Threads (which are not supported).
- The Lift web framework does not work out of the box, because it depends on Actors and JDBC.
あとは、ネットワーク接続は、HTTPしか使えないみたい
http://code.google.com/intl/ja/appengine/docs/java/overview.html
GAEで、Litfいじってる人はいるね。
http://groups.google.com/group/google-appengine-java/browse_thread/thread/642d7b97457b02bf/4fe712e3b4764ae7?lnk=raot
http://groups.google.com/group/liftweb/browse_thread/thread/7f33caf5e9db677b

818デフォルトの名無しさん:2009/04/13(月) 23:39:50
scalaって継続つかえますか
819デフォルトの名無しさん:2009/04/14(火) 12:25:17
KEIZOKU?
820デフォルトの名無しさん:2009/04/14(火) 13:21:31
グーグル先生に「Scala continuation」で聞いてみたら?
821デフォルトの名無しさん:2009/04/14(火) 14:36:52
6個のreal型変数x1、y1、x2、y2、x3、y3を定義しそれぞれに実数つを読み込んで、xy平面上の3点
(x1、y1)(x2、y2)(x3、y3)を頂点に持つ三角形の面積を計算して、その値を表示するプログラムを作成してください。
・公式:底辺x高さ÷2を使って計算してください。
お願いします!!

822デフォルトの名無しさん:2009/04/14(火) 15:59:32
>>818
あえて答えると、言語としてファーストクラスの継続は持ってない。
でも、ライブラリレベルで継続モナドみたいなのを作ってやるのは
できる(別にScalaに限った話でもないけど)。
823デフォルトの名無しさん:2009/04/14(火) 16:03:55
824デフォルトの名無しさん:2009/04/15(水) 00:01:39
>>823
てなことを、10スレ以上で言って回ってるのかおまえは? おヒマですね
マルチポストがどーたらを言ってる奴自身、ろくな回答してねえのが多いんだよな

# 加えてクロスポストを知らなかったりするし
825デフォルトの名無しさん:2009/04/15(水) 00:03:01
うわぁ>>824がマルチポスト
826デフォルトの名無しさん:2009/04/15(水) 18:40:25
見なかったことにしよう
827デフォルトの名無しさん:2009/04/15(水) 18:42:12
超法規的措置ですね
828デフォルトの名無しさん:2009/04/16(木) 11:25:19
>>821-824 までがコピぺw
829デフォルトの名無しさん:2009/04/16(木) 22:16:04
誰か一人いっしょに流されてないか?

ちなみに継続は Responder
830デフォルトの名無しさん:2009/04/23(木) 10:32:01
大学で学部生(情報系学科)のプログラミング入門にJavaを使ってるんだけど、Scalaに変えようと提案したら一蹴されてしまった。
日本語の教科書がないのと、講義担当教授(専門は信号処理)が全然知らないのが決定的らしい。残念。
演習担当助教としてはまちがいだらけの講義もなんとかして欲しいところなんだけどなあ。
831デフォルトの名無しさん:2009/04/23(木) 10:47:16
やっぱり2chに書いてたか。

お前人のこと言えるのかと。
832デフォルトの名無しさん:2009/04/23(木) 11:25:02
情報系なら、3年次ぐらいに関数型言語の講義があるんじゃ。
C言語から始めずにOS・ネットワーク周りとか何で実習するんだろう。
JAVAから入れば、Cぐらい読めると思うが。
833デフォルトの名無しさん:2009/04/23(木) 12:57:17
>>830
scalaってまだバグだらけじゃないの?なんでscala?

ところで
class Ex[T](t:T) {
 def ?:(o:Option[T]) = o match {
  case Some(v)=>v
  case None=>t
 }
}
implicit def any2ex[T](t:T) = new Ex(t)

val l = List(1,2,3)
l.find(_>3) ?: 5

でfindがNoneのときは5を返すようにしたかったのだが
java.util.NoSuchElementException: None.get
というエラーになってしまう。

5.?:(l.find(_>3)) だと
error :type mismatch
found :Doule
required: Option[Option[Int]]
とさらに意味がわからないことに…
834デフォルトの名無しさん:2009/04/23(木) 13:02:16
val foo:Int=>Int = {case x => x}
はありだけど
def foo(i:Int):Int = {case x => x}
はcaseに渡される型が失われてる、というエラーになるのはなんでだろ。
835デフォルトの名無しさん:2009/04/23(木) 13:40:17
>>834
{case x => x}の型はfunction typeだから、
val foo: Int => Int = ... の場合、受け取る型がInt => Intであることから、{ case x => x }の
型が推論されるけど、
def foo(i: Int): Int = ... の場合、受け取る型がIntなので、{ case x => x }の型が正しく
推論できない。
836デフォルトの名無しさん:2009/04/23(木) 13:41:03
というか、2番目の場合、仮に型をつけて
def foo(i: Int): Int = { case x:Int => x }
としても正しいプログラムじゃない(implicit conversion定義してあれば別だが)。
837デフォルトの名無しさん:2009/04/23(木) 13:50:35
>>833
>java.util.NoSuchElementException: None.get
Scala 2.7.3 finalで試してみたけど、正常に動いたよ。Scalaのバージョンはいくつ?

>error :type mismatch
>found :Doule
>required: Option[Option[Int]]
>とさらに意味がわからないことに…

これ、はまる人ときどき居るんだけど、5.がDoubleのリテラルとみなされて、
(5.) ?: (l.find_ > 3))
になるのが原因。コンパイラのバグじゃないよ。
838デフォルトの名無しさん:2009/04/23(木) 16:29:49
>>835,836
なるほど、case文は関数型のオブジェクトを生成して返してるのか。
1番目の式を見れば当たり前か。
俺はPartialFunction周りを理解できてなさ杉だな

>>837
すんません、こちらでもうまくいきました。
コンソール上でいろいろ試してたんでゴミができてたのかも。
コンソール起動しなおしたらうまくいった。

数値がDoubleとみなされるのは、そもそもどんな型でも取るような
implicit def は使わないほうがいいか
839デフォルトの名無しさん:2009/04/23(木) 19:21:28
>>830
教科書を自分で書くw
840デフォルトの名無しさん:2009/04/23(木) 22:30:27
liftって、公式wikiのコードサンプルでも、もう互換性無くなって
動かなくなってるのが至る所にある……
841デフォルトの名無しさん:2009/04/24(金) 01:12:42
Scala 2.8 プレビュー
http://www.scala-lang.org/node/1564
842デフォルトの名無しさん:2009/04/24(金) 22:09:51
結構変わりそうなのね。ある程度の互換性は確保して欲しいと思います。
843デフォルトの名無しさん:2009/04/24(金) 23:47:59
バイナリ互換性は無くなる。ソース互換性は基本的に保たれる、はず。
844デフォルトの名無しさん:2009/04/24(金) 23:55:46
Scalaは1Kコア時代のための布石みたいなもんだしな。
バイナリ互換は一切気にせず、改良に努めれば良いと思う。
845デフォルトの名無しさん:2009/04/25(土) 07:53:40
2
846デフォルトの名無しさん:2009/04/25(土) 07:55:28
2.7.4.final キタ
847デフォルトの名無しさん:2009/04/25(土) 09:20:25
大学の授業でScalaはインタプリタがあるっていう点ではJavaよりもいいかもね。
カリキュラム組むのは大変そう。
現Scalaユーザは他言語経験者だろうからプログラム入門者がScalaを習得する道程に考えが及ばないかもね。
848デフォルトの名無しさん:2009/04/29(水) 20:04:16
Stanfordは既に授業にしてるみたいだけどな、

ttp://www.stanford.edu/class/cs94si/
849デフォルトの名無しさん:2009/04/29(水) 21:29:26
>>848
最低二つのプログラミング言語の授業を既に取っている必要があって、
さらにCを使う"Computer Organization & Systems"の授業推奨だから、
>>847の言う意味とはまったく違うけどな。
850848:2009/04/29(水) 22:44:28
情報工学、科学を専門にする学生に対して最初に教える科目ではない罠
低レベルな言語と高級な言語を並列して教えるのがやっぱ妥当

素人にScalaを教えようとすると、JVMで動作するって説明で、もうアウトだろうし・・
型推論の説明がこれまた面倒臭い。
教養や専門にちょっと足突っ込むくらいのレベルならC,Javaあたりがいいかもな。

純粋に教養レベルでいいなら灯台みたいにRubyでいいんじゃね?
851デフォルトの名無しさん:2009/04/29(水) 23:59:27
>>850
> 純粋に教養レベルでいいなら灯台みたいにRubyでいいんじゃね?

灯台w
ラビ教えてんの?
木違い沙汰
852デフォルトの名無しさん:2009/04/30(木) 02:57:02
東大のrubyって文系理系共通科目の話だけどな。
情報系の授業は別にある。
853デフォルトの名無しさん:2009/04/30(木) 12:00:45
http://www.artima.com/scalazine/articles/programming_style.html
http://lotrepls.appspot.com/
>>> var name = "Samidare"; val nameHasUpperCase = name.exists(_.isUpperCase); println(nameHasUpperCase)
true
>>> var name = "satukibare"; val nameHasUpperCase = name.exists(_.isUpperCase); println(nameHasUpperCase)
false

文字列がイテレータで扱えるのはいいと思うんだけど
マルチバイトな文字をどうしたらいいかわからないんだ・・・
854デフォルトの名無しさん:2009/04/30(木) 12:53:03
>>853
http://www.h7.dion.ne.jp/~samwyn/Scala/scalag.htm
"" 文字列型のmanipulate は、java 風に indexOf, startsWith, endsWith
'' 文字型のmanipulate は、C 風に ==, != みたいにやればいい

>>> var name = "細雪"; var nameHasUpperCase = name.exists(_ == '細'); println(nameHasUpperCase)
true
>>> var name = "細雪"; var nameHasUpperCase = name.exists(_ == '太'); println(nameHasUpperCase)
false
855デフォルトの名無しさん:2009/04/30(木) 23:20:09
>>852
そうするといまは、
Ruby、Scheme、C、ML、(LINUXシステムプログラミング)、VHDL、(MPI+OpenMP)
て感じなのか。
ttp://www.is.s.u-tokyo.ac.jp/vu/vu_lessonlist.php

ある意味全方位だな。VM系以外
MLの代わりにならいけるんだろうけど、Java触らないからな・・・
856デフォルトの名無しさん:2009/05/02(土) 23:40:50
857デフォルトの名無しさん:2009/05/03(日) 04:10:03
公式サイトに「Getting Dynamic productivity in a Static Language」へのリンク記事が掲載されていた。
「Feel Of Scala」という講演に合わせた要約っぽい記事になってた
ttp://www.artima.com/forums/flat.jsp?forum=106&thread=253855

記事にも書いてある内容だとおもうけど、講演内容の半分は、
Scalaは簡潔に(個人的な解釈は自然言語っぽく)書けるからJavaみたいなつらいテストじゃないものが書ける。
動的言語的なダックタイピングをしながら、IDEでチェックもリファクタリングもしやすい。
コンパイル時にスペルミス(初期化ミス)のチェックなどにも、いろんな手法でチェック出来るようになってる。
みたいな感じだった。
使っていたテストスイートは、
・Test Methods (Suite,TestNGSuite)
・Test Fanctions (FunSuite)
・BDD (Spec)
でした、けっこう重要な講演だったと思う。

Groovyも(JRubyも?)Javaのテストが簡潔に出来るところが売りの一つだけど、
Scalaの特徴を活かした静的でかつ分かりやすいテスト環境が発展していて、
テストに使うにしても、総合的に上回りつつあるのかもしれないね。
858デフォルトの名無しさん:2009/05/03(日) 14:21:47
しっかり単語補完出来るIDEってどれ?
EclipseもNetBeansも中途半端すぎてあんまり使えないんだけど。
859デフォルトの名無しさん:2009/05/03(日) 20:49:05
映像で使ってたのは、IntelliJ IDEA@OSXだった。
ttp://plugins.intellij.net/plugin/?id=1347
860デフォルトの名無しさん:2009/05/05(火) 14:48:39
861デフォルトの名無しさん:2009/05/05(火) 18:41:28
http://www.artima.com/scalazine/articles/origins_of_scala.html
>We wanted to create something that would be at the same time
>practical and useful and more advanced than what we could achieve
>with Java. We started working on this language, which we came to
>call Scala, in about 2002. The first public release was in 2003.

age 7. にして 聡明な
862デフォルトの名無しさん:2009/05/06(水) 13:50:18
Scalaって何がいいすかね?
863デフォルトの名無しさん:2009/05/06(水) 16:18:19
864デフォルトの名無しさん:2009/05/06(水) 23:42:39
Scala紹介のスライドだけどライブラリがまとまってる
ttp://www.google.com/search?q=http%3A%2F%2Fwww.wankuma.com%2Fseminar%2F20081108toyama01%2F4.pdf
865デフォルトの名無しさん:2009/05/07(木) 06:06:17
>>864
> ■Web Flavor

> keisuken(日本の方) という人が作ってるらしい
吹いたwww プレゼンした人じゃねーかww
866デフォルトの名無しさん:2009/05/08(金) 02:22:06
867デフォルトの名無しさん:2009/05/08(金) 09:16:42
>>866
これのどのへんが「失禁してしまいそうな位鮮やか」なのか教えて欲しい。
Perlあたりで書いてしまったほうが楽そうなんだが
868デフォルトの名無しさん:2009/05/08(金) 11:51:52
>>867
866じゃないが、失禁してしまいそうな位鮮やかは言い過ぎにしても、かなり簡潔に書けてるとは思うが。
PerlだとCPANのXML操作ライブラリとか使うことになるんじゃないか?
869デフォルトの名無しさん:2009/05/08(金) 13:51:40
CPANのライブラリ使ってもいいが、Perlの方が楽はねーよ。
C#のLINQと比べるならまだわかるが。
870デフォルトの名無しさん:2009/05/08(金) 14:04:50
そういや、C#は従来のDOMそのまんま系と、LINQ用に導入された奴とで、
2系統有るんだよな。

Scalaは、XMLリテラルとか言語に入れてるし、今後も1系統なんだろうな。
871デフォルトの名無しさん:2009/05/08(金) 20:11:30
Perl最強
Scalaなんて書いたこともないけど
単なるJVMの寄生厨でしょw
872デフォルトの名無しさん:2009/05/08(金) 20:17:46
井の中の蛙落とし
873デフォルトの名無しさん:2009/05/08(金) 20:37:55
みんなが失禁したScalaのコードがあったら教えてよ。
874デフォルトの名無しさん:2009/05/08(金) 21:33:44
失禁はしてないけど、liftは色々とScalaらしいなーと感心したよ。
ドキュメントがダメで全然まとまってないけど、今月ぐらいに本が
出るらしいから、ちょっと期待。
875デフォルトの名無しさん:2009/05/08(金) 21:44:21
出る本は皆糞本ですよ
Scalaなんて糞だろw
876デフォルトの名無しさん:2009/05/09(土) 08:50:41
糞だと思うならこんなマイナー言語スレにいちいち出張ってこなくてよろし
別に一時期のRails程のブームになってるわけじゃなし。TwitterがScala
使い始めたってのでちょっと注目されてるくらいですぐ収束するだろう。
877デフォルトの名無しさん:2009/05/09(土) 10:19:18
>>876
Perlよりいいとかアホなこと2度と書き込むなよ
それと謝罪しろ土下座しろよ
878デフォルトの名無しさん:2009/05/09(土) 11:41:38
Perlを騙っただけじゃないかな。

いろいろ調べてたら、Apressから出る本は、liftの開発陣が書いてるみたいだね。
ttp://www.apress.com/book/catalog?category=32
Beginning Scala, By: David Pollak
ttp://www.apress.com/book/view/1430219890
The Definitive Guide to Lift: A Scala-based Web Framework, By: Derek Chen-Becker , Tyler Weir , Marius Danciu

今OHP内探してたら、「Exploring Lift: Scala-Based Web Framework」 作者同上、が消えてるな?5/5にはあったんだが。
879デフォルトの名無しさん:2009/05/09(土) 11:50:26
え、一気に3冊もlift本出るの?
amazon.co.jpだと『Exploring Lift』しか出てこなかったら、迷わず注文しちゃったのに。
消えた?

ML見た印象で言うと、作者のDave Pollakって人は
あんまり説明が上手くないような気がする。
880デフォルトの名無しさん:2009/05/09(土) 11:58:52
リンクつけ忘れた。
The Definitive Guide to Lift: A Scala-based Web Framework
ttp://www.apress.com/book/view/1430224215


Terracottaのコミッターのひともいろいろ記事とコードを書いてた。
ttp://jonasboner.com/archives/
・Real-World Scala
- Erlang-style Supervisor Module for Scala Actors (Scala OTP)
- AOP-style Mixin Composition Stacks in Scala
・Clustering Scala Actors with Terracotta

Pragmatic Real-World Scala presentation
ttp://jonasboner.com/2009/01/30/slides-pragmatic-real-world-scala.html
881デフォルトの名無しさん:2009/05/09(土) 12:03:29
ttp://www.scala-lang.org/ の右サイドメニューにも「Exploring Lift」しかでてない
自分もExploring Liftをアマゾンで注文したよ。

Dave Pollakの本は、scalaの本でした。
882デフォルトの名無しさん:2009/05/09(土) 12:07:11
書籍一覧はここにあるぞ
出版元の解説にも飛べる

Books on Scala
http://www.scala-lang.org/node/959
883デフォルトの名無しさん:2009/05/09(土) 12:17:11
liftの作者のくせに出す本がlift本じゃないとか、紛らわしすぎだろ。
884デフォルトの名無しさん:2009/05/09(土) 13:55:35
>>877
わけわからん。別にPerlと比較した覚えは無いが。
885デフォルトの名無しさん:2009/05/09(土) 13:58:05
似たような本ばかし何冊も出して意味あるのかな
Scalaの概要を知りたいなら、とりあえずProgramming in Scala1冊でいい気がする
他の本がもうちょっと実践的な側面に焦点当ててるならまた違うだろうけど
886デフォルトの名無しさん:2009/05/09(土) 14:36:45
O'Reillyのは、twitter社内でAPIをRubyからScalaで書き直した人?ので、
artimaにインタビュー記事があった。
ttp://www.artima.com/scalazine/articles/programming_style.html

Pragmatic programmersのやつは、
Agile DeveloperのVenkat Subramaniam(トレーナー、メンター)が書いた物
.NET Gotchas、Agile Developer、Programming Groovyを書いた人

ぱっと見のひとには、programming in scalaより薄いし、ここら辺が売れるような気がする。

CUPのは、ギリシャの人たちみたい。どういう経緯なのか分からんw
ttp://www.nabble.com/-scala---ANN--Steps-in-Scala:-Introduction-to-Object-Functional-Programming-td22554993.html
887デフォルトの名無しさん:2009/05/09(土) 14:45:23
細かい差はいいから、日本人でも読みやすいのはどれだよ?
変な修辞をこねくり回したり、アメリカンジョークや文学の引用が無い奴。
888デフォルトの名無しさん:2009/05/09(土) 15:37:20
やはり言語をデザインしたMartin Oderskyの本ではないかと。
CならK&R、C++ならStroustrup、Rubyならまつもとの本が一番いいのと一緒だ。
889デフォルトの名無しさん:2009/05/09(土) 18:44:40
ttp://www.jroller.com/sebastianKuebeck/entry/object_oriented_programming_2_0
C++の定跡で有名なCoplienのつくったDCIパターン?の解説の記事に、Coplienのアジャイル開発に
関する新著(草稿)へのリンクがある。
この本、当然C++で書かれてるんだが、8.6のBeyond C++のところの最初にScalaを持ってきてました。
Programming in Scalaの出た去年の後半ぐらいからほんとにすごい立ち上がりになってるね。
890デフォルトの名無しさん:2009/05/09(土) 19:17:59
http://code.google.com/p/scaml/
http://code.google.com/p/scala-deque/source/browse/trunk/Deque.scala

試みとして、何か書いてみようかというふいんき(何故か変換できない
は、とても感じる・・・
891デフォルトの名無しさん:2009/05/10(日) 06:38:16
892デフォルトの名無しさん:2009/05/10(日) 07:41:50
ミオワタ
decorateToString のとこに違和感があた
中盤の test コードの所は眠かた
最後ラ変5項目辺りは面白かた
893デフォルトの名無しさん:2009/05/10(日) 07:59:16
>>887
夏頃に、Programming Scalaの翻訳が出るよ。

それまで待て。
894デフォルトの名無しさん:2009/05/11(月) 00:51:01
>>893
ちょっとまて、どこの出版社だ?
895デフォルトの名無しさん:2009/05/11(月) 09:00:25
>>894
ビアソンか翔泳社かオライリーだと思われ。
896デフォルトの名無しさん:2009/05/11(月) 09:12:53
ソフトバンクかアスキーか技術評論社かマイコミかもね。
897デフォルトの名無しさん:2009/05/11(月) 19:01:25
>>891
音楽にフイタ
898デフォルトの名無しさん:2009/05/11(月) 19:22:22
>>896
著者から言って、そこは望み薄。
899デフォルトの名無しさん:2009/05/12(火) 00:19:05
訳本鉄板と名高いテクノロジーアートだろ
900デフォルトの名無しさん:2009/05/12(火) 01:01:07
>>899
鉄板か?コード書こうともしないモデリング屋は信頼できないんだが・・
901デフォルトの名無しさん:2009/05/12(火) 01:06:20
>>900
推薦図書の荒し
902デフォルトの名無しさん:2009/05/12(火) 01:07:55
>>900
鉄板で駄訳って意味だろ常識的に考えて

>>899
×テクノロジーアート
○テクノロジックアート
903デフォルトの名無しさん:2009/05/12(火) 15:18:15
The Goals of Scala's Design
http://www.artima.com/scalazine/articles/goals_of_scala.html

martin の英語、話している題目も関係してるのかも
しれないけど読みにくく感じる… guido さんも修辞と
語彙が凝ったかんじだけど、何かまた違ったかんじで
訳わからなす… また artima.com…ぐぬぬ…
904デフォルトの名無しさん:2009/05/12(火) 17:15:52
http://www.riffraff.info/

sinatra 風な cotroller が 30 行で書けるなんて
実質 9 行で書ける…これにキーワード引数が追加
されれば、いやいやホンマかいなと首を傾げる
905デフォルトの名無しさん:2009/05/12(火) 18:32:39
Scala and XML - Part 1
http://www.eishay.com/2009/05/scala-and-xml-part-1.html
>[3] An emphasis on the string as a value in the curly brackets.
>Some (like myself) placed there an Int or other primitives
>expecting something like string concatenation. Well, it won't
>work and you'll get this error:

tag 内 curly brackets は 変数として展開される。
それは文字列で、ほかの要素の場合はエラーとなると
906デフォルトの名無しさん:2009/05/12(火) 19:08:02
scala.xml.XML.save
scala.xml.XML.saveFull
のコードがおかしいと思う。マルチバイト文字は使用できない
907デフォルトの名無しさん:2009/05/12(火) 20:53:05
デフォルトエンコーディングが iso-8859-1 だから、エンコーディング指定版使わないと
908デフォルトの名無しさん:2009/05/12(火) 22:47:49
lift本はこういう事らしい。
http://groups.google.com/group/the-lift-book/browse_thread/thread/70fc38d4e6ba941

"Exploring Lift"から"The Definitive Guide to Lift"に名前変わった。
amazonが間違ってるから出版社に連絡しとくわい、と。


あと、今気づいたけど、先月から日本人のコミッターが加わってたんだね。
http://groups.google.com/group/liftweb/browse_thread/thread/354b7e939a7de971
909デフォルトの名無しさん:2009/05/13(水) 12:39:39
最近common lispにかぶせるパターンマッチ拡張言語Qiとかいうのできたけど
かぶせて拡張が流行ってるのかねえ
910デフォルトの名無しさん:2009/05/13(水) 13:06:30
最近できたのはQi IIだろ
911デフォルトの名無しさん:2009/05/16(土) 00:29:00
OHPの今度の紹介記事は、Scala on Google App Engineだった。
ttp://www.scala-lang.org/node/1831

Googleの人がガイドを寄稿してたのに、あわせたものみたい。
Documentation ≫ Quick Guides ≫ Programming Guides ≫ Scala on Google App Engine
Scala on Google App Engine
ttp://www.scala-lang.org/node/1826

liftの作者もいろいろ確認してるそうだ。
ttp://lift-example.appspot.com/
912デフォルトの名無しさん:2009/05/16(土) 22:39:23
Javaでいうクラススコープの変数はScalaではどうやって定義するの?

// Java
public class JavaClass {
  private static int staticVar; // <-- これ
}
913デフォルトの名無しさん:2009/05/17(日) 00:32:21
>>912
staticは無い。objectに定義する。
914デフォルトの名無しさん:2009/05/17(日) 12:02:28
object はシングルトンなのでその内部変数は Java の static としてバイトコード化される
また object 名はインスタンス名なので同名の class が可 (インスタンス名とクラス名は別の名前空間に属する)
915デフォルトの名無しさん:2009/05/17(日) 22:23:58
>>914
thx
916デフォルトの名無しさん:2009/05/18(月) 21:26:28
companion オブジェクトでしたっけ。
917デフォルトの名無しさん:2009/05/18(月) 23:12:25
companion objectはScala関係の記事でもあまり話題にならないね。
実際、知らなくてもまあ問題無いけど、知ってると便利なこともある。
918デフォルトの名無しさん:2009/05/19(火) 11:53:11
919デフォルトの名無しさん:2009/05/19(火) 12:23:13
Hashcode & Equals in the Scala 2.8 Collections Library
http://scalide.blogspot.com/2009/05/hashcode-equals-in-scala-28-collections.html
920デフォルトの名無しさん:2009/05/22(金) 23:27:56
921デフォルトの名無しさん:2009/05/23(土) 00:14:20
Lift本届いた。結構読みやすい英語。索引が無い。
でも、これでやっとLiftにもまともなドキュメントが出来たという感じ。
922デフォルトの名無しさん:2009/05/23(土) 10:42:12
うちも届いたよ。

Apressの本は、Google Booksにもサンプルあるからので、出てきたようだ。
http://books.google.com/books?id=5lPmFLC6sHAC

一部草稿かもしれないけど、3月時点のやつはCC改変不可ライセンスで配布してるみたいなので、
興味がある人はみてね。
http://www.google.com/search?hl=ja&q=lift+exploring+pdf&lr=

製本では付録(ABC)がなかったので、コピーしておこうかな。
923デフォルトの名無しさん:2009/05/23(土) 10:44:35
よくみたら、付録はABCじゃなくて、A-Gだったよ・・・
924デフォルトの名無しさん:2009/05/23(土) 10:51:04
Lift本読んでやっとScalaでJavaScriptコード生成するあたりの意味が分かった。
925デフォルトの名無しさん:2009/05/24(日) 15:53:58
オブジェクトのコピーを作るとき、明示的にクラスを指定せずにやりたいんだけど、どうしたらいい?
下の例だと、引数かメソッド定義で指定してしまっていてカコ悪い。

object Main {
def main(args: Array[String]) = {
var foo: Foo = new Foo("xyz")

println(foo)
println(foo.copy)
println(foo.copy2[Foo]) //引数でクラス指定
}
}

class Foo(var id: String) extends Cloneable {
override def toString(): String = super.toString + " : " + this.id

// メソッド定義でクラス指定。サブクラスでは再定義が必要。
def copy:Foo = this.clone.asInstanceOf[Foo]

// メソッドの引数でクラスを指定。呼び出し側でクラスが一意に決まらない場合に対応不能。
def copy2[T]: T = this.clone.asInstanceOf[T]

// コンパイル不能。こういう感じで汎用的なコピーメソッドを定義したい。
// def copy3: this.getClass = this.clone.asInstanceOf[this.getClass]
}
926デフォルトの名無しさん:2009/05/24(日) 16:22:32
これでOK。

class Foo(var id: String) extends Cloneable {
override def toString(): String = super.toString + " : " + this.id
// this.typeは実際のクラスの型に応じて変わるので、再定義不要。
def copy: this.type = this.clone.asInstanceOf[this.type]
}

class Bar(id: String) extends Foo(id)

val bar: Bar = (new Bar("bar")).copy //ちゃんとcopyの返り値の型がBarになっている
println(bar)
927デフォルトの名無しさん:2009/05/24(日) 17:21:27
>>926
できた。ありがとう。
928デフォルトの名無しさん:2009/05/24(日) 23:56:37
アマゾンからオススメされた
http://www.amazon.co.jp/gp/product/1430219890/
929デフォルトの名無しさん:2009/05/25(月) 23:49:58
>922
本文中にAppendixの何とかを参照せよって書いてあるのに、
巻末にAppendixが存在しないじゃねえか落丁かよって思ったら、
http://www.apress.com/book/view/1430224215
のBook Extras の下の Appendixes でダウンロード出来た。
930デフォルトの名無しさん:2009/06/03(水) 08:33:45
2.7.5.final キタ
931デフォルトの名無しさん:2009/06/05(金) 17:49:58
C#のnew制約にあたるものはありますか
このプログラムのコンパイルエラーをなくしたいです

class BaseRow
{
}

class BaseTable
{
}

class Row[+TTable <: BaseTable] extends BaseRow
{
val Table: TTable = null.asInstanceOf
}

class Table[+TRow <: BaseRow] extends BaseTable
{
def NewRow: TRow = new TRow() //class type required error
}
932デフォルトの名無しさん:2009/06/06(土) 19:44:49
Javaと同じくerasureによるジェネリクスだから型変数でnewすることはできないんじゃないかな。。
933デフォルトの名無しさん:2009/06/06(土) 20:36:50
>>932の書いてる通り、まあ無理なわけだが
scala 2.7.3くらいから実験的に入った機能にscala.reflect.Manifestというのがあって、
それを使えば、静的な安全性を犠牲にしてもいいならできなくも無い。

mport scala.reflect.Manifest
class Creator[T](manifest: Manifest[T]) {
def create(): T = {
manifest.erasure.newInstance().asInstanceOf[T]
}
}

object Creator {
implicit def creatorOf[T](implicit manifest: Manifest[T]): Creator[T] = {
new Creator(manifest)
}
}

def makeObj[T](implicit c: Creator[T]) = c.create

println(makeObj[java.util.ArrayList[String]]) //ArrayListが作れる
934デフォルトの名無しさん:2009/06/06(土) 20:39:38
>>932
コンストラクタだけは継承先で書かないといけない感じですね
ありがとうございます。
935デフォルトの名無しさん:2009/06/06(土) 21:29:26
こういうのみると.NET(Mono)だったらって思う。
あるいは、C++Template的なものがあれば。
936デフォルトの名無しさん:2009/06/07(日) 06:58:32
結局、無料サーバが無いんじゃイラネってなる
937デフォルトの名無しさん:2009/06/07(日) 14:45:00
無料とまでいかなくても月額1000円以内は欲しいな
938デフォルトの名無しさん:2009/06/07(日) 15:52:29
Google App Engineでも使ってろ
939デフォルトの名無しさん:2009/06/08(月) 10:08:09
>>933
その後いろいろとやってみましたが、
makeObjのTには型引数をそのまま渡すわけに行かないようで、
Tableクラスの中でnewRowを記述することはできませんでした。
940デフォルトの名無しさん:2009/06/08(月) 12:15:59
>>939
うーん。>>933のテクニックを使えば原理的には可能なはずなんだけど。
implicit parameterの指定を忘れたりしてない?
941デフォルトの名無しさん:2009/06/08(月) 12:59:47
>>940
こんなコードを書いてみて
abstract class Table[+TRow <% Row[_]] extends BaseTable
{
def create[T](implicit manifest: Manifest[T]) =
manifest.erasure.newInstance().asInstanceOf[T]
def newRow: TRow = create[TRow].asInstanceOf
}
コンパイルエラーがでました。
generics.scala:25: error: no implicit argument matching parameter type scala.reflect.Manifest
def newRow: TRow = create[TRow].asInstanceOf
^
「Manifest型仮引数にマッチしている暗黙実引数がない」という意味?

Tがクラスの場合だけManifest[T]型の暗黙実引数を渡しているのではないかと
思いました。
942デフォルトの名無しさん:2009/06/08(月) 14:22:01
>>941
この場合だと、implicit manifest: Manifest[T]の部分はコンストラクタの引数に書かないと
ダメ(クラス定義の中では、TRowは消去されて、単にRow型として扱われてしまうので)。
たとえばこんな感じ。

import scala.reflect.Manifest
trait BaseTable
trait BaseRow
class Table[+TRow <: BaseRow](
implicit manifest: Manifest[TRow]
) extends BaseTable
{
def newRow: TRow = {
val c: Class[_] = manifest.erasure
println(c getConstructors() toList)
c.newInstance().asInstanceOf[TRow]
}
def printRow {
println(newRow)
}
}
class MRow() extends BaseRow

object Main {
def main(args: Array[String]) {
val t = new Table[MRow]
t.printRow
}
}
943デフォルトの名無しさん:2009/06/08(月) 15:54:01
完動サンプルまで書いていただきありがとうございます
implicit parameterはコンストラクタでないといけないと言うこと
理解しました
思い描いたとおりに動作しました
またListのサンプルも参考になります
インスタンス化しないならtraitにするのも参考になりました
↓こんな感じにまとめました
944デフォルトの名無しさん:2009/06/08(月) 15:54:42
import scala.reflect.Manifest

trait BaseTable
trait BaseRow

class Table[+TRow <: Row[_]](implicit manifest: Manifest[TRow]) extends BaseTable
{
def newRow: TRow = {
manifest.erasure.newInstance().asInstanceOf[TRow]
}
}

class Row[+TTable <: Table[_]] extends BaseRow

class Row1 extends Row[Table1]
{
def code: Int = 1
def name: String = "abc"
}

class Table1 extends Table[Row1]

object TypedTable
{
def main(args: Array[String]) = {
val table = new Table1
val row = table.newRow
println(row.code);
println(row.name);
}
}
945デフォルトの名無しさん:2009/06/09(火) 00:06:07
明日からScala入門します
よろしくお願いします。

946デフォルトの名無しさん:2009/06/09(火) 01:15:38
いえいえ
こちらこそ、どういたしまして
947デフォルトの名無しさん:2009/06/09(火) 10:26:28
基底クラスのメソッドを呼び出すときはどうするのですか

override def test
{
base.test
}

のようなことをしたいのですが
948デフォルトの名無しさん:2009/06/09(火) 10:31:30
classにネストされたobjectって、シングルトンではなくて
外側のクラスのインスタンスとペアで生成されるみたいですね
コンポジット集約に使えそう
class Outer(var value: Int)
{
Inner.value = value
object Inner
{
var value = 0
}
}

object ObjectTest
{
def main(args: Array[String]) = {
var outer = new Outer(1)
var outer1 = new Outer(2)
println(outer.Inner.value);
println(outer1.Inner.value);
}
}
949デフォルトの名無しさん:2009/06/09(火) 18:39:29
>>947
Javaと同じ。つまり、

override def test
{
super.test
}
950デフォルトの名無しさん:2009/06/09(火) 21:40:46
>>949
ありがとうございます。
Javaの文法を先に勉強しないといけなさそうですね。
C# → Scala なのでわかりませんでした。
951デフォルトの名無しさん:2009/06/10(水) 18:17:06
>>950
あ、いや、Javaと同じ、というのは、あくまでsuperの文法に関してであって、
文法全般がJavaに似ているわけではないので。ただ、Scala使うのだったら
JavaのAPIはある程度おさえておかないとつらいかも。
952デフォルトの名無しさん:2009/06/14(日) 01:15:09
ScalaさんのHPがえらいことになってて吹いた・・

ttp://www.scala-lang.org/
953デフォルトの名無しさん:2009/06/14(日) 08:31:50
うさんくさいな。
954デフォルトの名無しさん:2009/06/14(日) 09:07:31
投票のPDP-11にフイタ
955デフォルトの名無しさん:2009/06/14(日) 10:41:31
なんか凄まじく胡散臭くなったなw >ページデザイン
これは改悪なんじゃなかろうかと
956デフォルトの名無しさん:2009/06/14(日) 12:06:32
スクリプト切ってたので気付かなかった
957デフォルトの名無しさん:2009/06/15(月) 10:02:08
I need Scala on
Sun JVM 6/7
52%
Sun JVM 5
8%
Sun JVM 1.4
1%
IBM J9 JVM
1%
Android
14%
J2ME cellphone
4%
.Net / Mono
12%
PDP-11
8%
Total votes: 1575
たしかに、PDP-11多すぎるな、J2ME涙目。
958デフォルトの名無しさん:2009/06/18(木) 23:10:32
scalaってjavaみたいに引数の型がjava.lang.Objectのところに
java.lang.Stringを渡すことは出来ないのか?
959デフォルトの名無しさん:2009/06/18(木) 23:18:47
>>958
できるよ。むしろなんでできないかもと思ったのか気になる。
960デフォルトの名無しさん:2009/06/19(金) 01:45:16
String.format() とかで、型が違うよエラーが出る件じゃないの?
次のバージョンで直すとか見たような?
961デフォルトの名無しさん:2009/06/20(土) 19:26:26
Scalaは、var使ったら負けだと思ってる。
962デフォルトの名無しさん:2009/06/20(土) 22:20:13
実際、varを直接使わないといけない場合は結構少ないよね。
標準ライブラリのmutableなデータ構造のお世話になることはままあるけど。
963デフォルトの名無しさん:2009/06/21(日) 12:47:05
インスタンスの構築時には初期化できないようなメンバフィールドとかはどうしてる?

俺は、Optionにしたり、あるいはprivateだから良いかとvarにしちゃったりするけど。
964デフォルトの名無しさん:2009/06/21(日) 13:45:31
>>961
ScalaなんかやめてHaskellつかえよ
965デフォルトの名無しさん:2009/06/21(日) 15:02:42
>>963
クラスの外部に副作用が漏れない形でvar使うのはときどきあるかな。
966デフォルトの名無しさん:2009/06/21(日) 21:03:59
>964
手続き型言語 → Haskell
より
手続き型言語 → Scala → Haskell
の方がなじみやすいと思う。

ところで、Scalaの一番いただけないところは、Maybe(Nothing | Just)型の名前が
Option(None | Some)になってるところ。なんか直感的でないと思うのは、俺だけ?

ちなみにこの部分は、LiftがOptionを拡張して作ったBox(Empty | Failure | Full)が
色々と便利なのでLift外でも使いたい感じ。
967デフォルトの名無しさん:2009/06/21(日) 21:11:55
MaybeとかNothingとかJustとか言われるほうがわかりにくいような。。
そしてOption=None|SomeはML系でも使われるのでScalaは異端ではないのです。
968デフォルトの名無しさん:2009/06/21(日) 21:28:55
でも、Scala自体はML系よりもHaskellからより影響受けてる気がするな。
implicit parameter使って型クラスエミュレートとか
Option、List、Streamなどの色んなクラスがモナドとして使えるようになってる辺りとか。
969デフォルトの名無しさん:2009/06/22(月) 00:27:54
Scalaさわってる人ってML系よりHaskell経験者が多そう。
つまりミーハー
970デフォルトの名無しさん:2009/06/22(月) 00:50:09
>969
ああ、つまり、話題にはなるけど、何も成果物があがってこないって事?

Webアプリを作れるLiftが有る分、若干マシな気がするけど。
971デフォルトの名無しさん:2009/06/24(水) 19:16:14
972デフォルトの名無しさん:2009/06/24(水) 23:02:34
ScalaでWebアプリっていうとLiftが有名だが、スイーツなプログラマ専用の
Sweetってフレームワークを見つけた。
http://code.google.com/p/sweetscala/wiki/WikiHome

Liftみたいに関数型である事に拘ったつくりではなく、オブジェクト指向の方を
重視して、ふつうのMVCを目指してるそうだ。ビューの部分にはFreemarker を使う。

あと、Scalazってライブラリも紹介しとく。これをベースにした、Slinkyって
Webフレームワークも有る。
http://code.google.com/p/scalaz/
973デフォルトの名無しさん:2009/06/26(金) 00:58:02
>961
一瞬そんな気になるかもしれないが、Scalaライブラリのソースコードを
見てみると、var使いまくりんぐだったりする。

さすがに、ListのfoldLeftの内部実装がvarとwhileループで出来ていて、
再帰なぞしてない事に気づいた時にはがっかりした。

あと、常識的にはListって言えばimmutableなものだが、Scalaのそれは
private[scala] varな変数で構成されていて、ライブラリ内部では
mmutableな物としてがりがり書き換えてたりする。
これがListBufferの性能の秘密。
974デフォルトの名無しさん:2009/06/26(金) 01:17:50
>>973
再帰使ってなくてがっかりって、Scalaって末尾再帰最適化されんの?
さもなければループでライブラリはループで書いとくのが安全じゃね?
975デフォルトの名無しさん:2009/06/26(金) 09:57:55
ttp://d.hatena.ne.jp/athos/20081113/p1
> ただし、すべての末尾呼び出しが最適化されるわけではないらしい。

> Scalaならforを使ったループの方がすっきり書ける場合が多いみたいなので、
> 「再帰でもループが書ける」くらいに思っておいた方がいいのかもしれない。

安定性と性能を考えて974な考えなんじゃないか。
976デフォルトの名無しさん:2009/06/26(金) 11:09:05
JVMにtail callをサポートする命令がないからなあ。
次のJVM仕様では候補に上がってますが。
977デフォルトの名無しさん:2009/06/26(金) 19:49:12
そうみたいね
clojureの解説でもjvmが対応したら対応するって書いてあった
それと、jvmは動的言語向けの機能強化が予定されてるらしいね
978デフォルトの名無しさん:2009/06/26(金) 22:49:26
>>977
> それと、jvmは動的言語向けの機能強化が予定されてるらしいね
この辺の話かな。
http://www.infoq.com/jp/news/2008/06/jsr_292_edr
http://journal.mycom.co.jp/articles/2009/06/16/jdk7/index.html
979デフォルトの名無しさん:2009/06/27(土) 02:26:58
高階関数と末尾再帰の話題におけるHallo Worldと言ってもいい存在である、
left foldをwhileループで実装せざるを得ない(標準ライブラリでそうなってるんだから
それなりの理由があるんだろう)ような言語が、関数型言語とか名乗っちゃっていいの?
ちょっとおかしくない?

じゃ、C#も関数型言語?
http://en.wikipedia.org/wiki/Foldl
980デフォルトの名無しさん:2009/06/27(土) 02:29:22
あ、helloのスペル間違えた
981デフォルトの名無しさん:2009/06/27(土) 06:14:14
名乗ってません
982デフォルトの名無しさん:2009/06/27(土) 23:21:00
1 to 5 foreach println
983デフォルトの名無しさん
すまん、誤爆した