プログラミング言語 Scala 7冊目

The Scala Programming Language
ttp://www.scala-lang.org/

■リンク集
ttp://sites.google.com/site/scalatohoku/%E5%8B%89%E5%BC%B7%E4%BC%9A%E8%B3%87%E6%96%99

■前スレ
プログラミング言語 Scala 6冊目
ttp://hibari.2ch.net/test/read.cgi/tech/1307416864/

■Scalaの紹介文（さわり）
Scalaは簡潔かつ優雅で型安全な方法でよくあるプログラミングパターンを表現できるように
設計された汎用プログラミング言語です。
Scalaはオブジェクト指向と関数型言語の特徴をスムーズに統合しておりJavaやその他の言語を扱う
プログラマをより生産的にすることができます。（以下略）
ttp://www.scala-lang.org/node/25

■Scalaに関する書籍（英語）
ttp://www.scala-lang.org/node/959
リファレンスマニュアルや草稿のPDFなども充実しているのでそちらも参照してください。
日本語の資料には、チュートリアルの訳やIBM dW、IT Proの連載記事、各々で開かれた勉強会の資料などがあります。

>>1
乙なんだぜ！
「ＥＲＲＯＲ：Lvが足りなくてスレッド立て(ら)れません。」
とか言われてスレ立てられなかったんだぜ…。日に日に使いにくくなる2ch。
しかしこれ、"ＥＲＲＯＲ"が全角で"Lv"が半角という統一感の無さで憤死しそうになるな…。

あと次スレからリンクにはこれも追加しようぜ

プログラミング言語Scala 日本語情報サイト
http://sites.google.com/site/scalajp/

前スレの終わり方なんなの…

前スレのことは次スレに持ち込まないのが2chのルール

はい

そんなルールは初耳だなぁ

上手く使えば、いい感じで話題が切り替えられるのが
1000スレッド落ちシステムの特徴だとは思う

結局またモヒカンが来て
この定義はおかしいって騒ぐだけだろ？

>>2
前方互換性の考慮の結果だよ

なぜScala村にはモヒカン族が沢山居るのですか？

とんでもない！Scalaは初心者でもウェルカムですよ！！

そうやって騙すのはもう無理だと思うの

そんなにたち悪いモヒカンは居ないだろ。
JavaとかRubyのモヒカンのガチのキモさに触れたら、Scalaなんぞ平和そのもの。

そもそもScala周辺には人がまだ少ないから、、、。

ていうかScalaやってる人って、何作ってるの？

Webから情報収集するプログラム書きたいのだが、他言語に比べて情報が少なすぎる、、。

>>14
そのくらいならまずJavaで作ってみて、書き換えていけばいいのでは？

Scalaの総代将がモヒカン過ぎるのがいけないのでは？

C++はハゲだけど大丈夫だよ

中之条

REPLからJavaクラスを実行すると、その中の
URL url = Thread.currentThread().getContextClassLoader().getResource("log4j.properties")
という箇所で、urlにnullが格納されてしまうのですが、どなたか回避をご存知でしょうか？
(当然ながら、log4j.propertiesはクラスパス上においています。)

普通にコンパイルして実行すると、urlにはlog4j.propertiesのパスがちゃんと入るのですが…。

おまえらがそうやって新しい言語に飛びついてる間に、cを極めてニッチかつ専門的な分野でウマー

>>19
Thread.currentThread().getContextClassLoader()
で取得されるクラスローダが別物なので。
> val url = getClass().getClassLoader().getResource("log4j.properties")
とやるとちゃんと取得できます。

>>16
総大将になったつもりは無かったんですけど、モヒカン過ぎると色々摩擦を生む事自体は理解してます。
あまりモヒカン的になりすぎないようにしようとは思っているのですけど、人間、すぐには変われないですね…。

けーみずさん、スルーするのも大事ｗ

総大将というより、最大限持ち上げて切り込み隊長だろｗｗ

>>22
限界集落のOCaml村に煽られてもスルーできるが、
同じJVM言語仲間のGroovy村に煽られたら戦争だろうが……！
って感じですかね？

>>14
情報が少ないならここで聞けばいいじゃん

他の言語がクソならdisってやりゃいいんだよ
馴れ合う必要なんてないね

>>27
そういう怖い人はScala使わないでください＞＜

Scala ノ ヒンイ ガ 10 サガッタ

ここのモヒカンよ、これ読んで少しは見習えよ
http://journal.mycom.co.jp/articles/2011/09/05/efl2/index.html

>>30
キモいもん貼るなボケ

どっかに配布されているjarファイルをこんな感じで読み込もうとすると、
> scalac a.scala -cp path/*.jar
error: IO error while decoding ... with UTF-8
Please try specifying another one using the -encoding option
で数時間ハマりました。
正解は
> scalac a.scala -cp "path/*:."
だそうです。（"path/*.jar:."もダメらしい）

エンコーディングとか関係ねーじゃん！

ぜんぜん関係ないですがこのスレ久々で、「モヒカン」の流れがわかりません。
誰か簡単に解説してちょ。

>>33
はてな村用語。
http://mohican.g.hatena.ne.jp/keyword/%E3%83%A2%E3%83%92%E3%82%AB%E3%83%B3%E6%97%8F
「対立した文化として→ムラ社会」なんて書いてあるけど、
モヒカンが集まってムラ社会形成してるよな。

>>34
thxです。
こんな用語かってに作られて、本家（native american）は迷惑してるだろな。

モヒ漢

引数に型Tをとって、Tを継承した型を返す関数って
どうやって書くんだっけ？

http://groups.google.com/group/clojure/browse_thread/thread/b18f9006c068f0a0?pli=1

>>37
お前モヒカン村で何聞いてるの？

>>38
ソースとテストケース出さずにそんな事言われても…

モヒカンならソースとテストケースで事実を示して反論しよう！

>>38
長いから要約して

>>42
Scalaの標準のアクター実装のせいで、負荷をかけるとOut of Memoryで落ちた
Clojureで書き直してみたら負荷かけても動くようになった
さらにコードも短くなった（行数：1,000行から260行、文字数：31kから11.5k）

>>37
動的型言語では簡単に出来るけど、Scalaでは出来ません。

そういえばScala-Swing使ってて、ComponentのpaintComponentをオーバーライドしてGraphics2Dを描画させる時に、
イベント処理でrepaintを呼ぶと以前描画したものが消えてしまうのの回避方法ってある？

例えで言うと、マウスでクリックした所に円を描くプログラムに関して、
新たにクリックすると直前に描いた円が消えてしまう感じ。
ここで聞くなって話なら申し訳ない。

>>45
描いた円を全て覚えておくか、メモリ上にビットマップ展開して、そこに円を描画。
paint(repaint含む)はメモリ上のビットマップを画面に描画するだけ

Java/scalaに限らず、GUI全般の問題やね

>>46
ありがとう。GUIプログラミングについてもっと勉強し直す。
スレチに近くてスマソ。

>>43
カッコだらけの時代遅れ糞言語なんて誰も使わねえよ、ばーかばーか
っていうのを翻訳して投稿しておいてくれ

>>44 >>37の意味がいまいちわからない。でもこれだけはいえる

動的言語にできるという意味でなら、scalaでもできる

以上

>>49
こんなことがしたいのでは？

Python

def newType(T):
    class Foo(T):
        pass
    return Foo

C++

template <class T>
class Foo : public T {
};

よくわからん

ゆろよろがTwitterのアイコン変えてつまらん
不細工を角度で誤魔化そうとするスイーツ臭はどこにいった

そういうのはヲチ板でやってくれ

だから、Scalaでこんなコードが書けたら良いなってことかと（実際は以下のようには書けない）

def newType[T:ClassManifest]() : ClassManifest[Foo[T]] = {
    class Foo[T] extends T {}
    return implicitly[ClassManifest[Foo[T]]]
}
def construct[T](t:ClassManifest[T]) : T =
{
    return t.erasure.newInstance().asInstanceOf[T]
}
val t = newType[Bar]()
val x = construct(t)


こっちはPython版
http://ideone.com/lNfZi

>>49「動的言語にできるという意味でなら、scalaでもできる（キリッ」

馬鹿過ぎワロタwww

静的動的でいろんな所を煽ってるいつもの人でしょ
相手にするだけ無駄

静的動的で煽り合いするスレどこいったんだ？
隔離スレとして機能してたのに

ScalaはRubyより劣る
Pythonより劣る
F#のような洗練された言語設計もない

どうやってつかえばいいの？

無理して使わなくていいんだよ＾＾

ジェネリックの型引数って継承できたらいいと思わない？
実体化したらそれで終わりなんて継承ツリーの中で使いにくい
自分と同じ型のメンバーを表すだけでも大変
抽象型を使ってみたが妙に不自然な書き方しか思いつかない

abstract class Base {
type TParent <: Base
var parent: Option[TParent] = None
}

class とり extends Base {
override type TParent <: とり
override def toString = "とり"
}

class とんび extends とり {
override type TParent <: とんび
override def toString = "とんび"
}

object AbstractTypeTest {
def main(args: Array[String]) = {
var とり = new とり { type TParent = とり }
とり.parent = Option(new とり { type TParent = とり })
println(とり.parent)
var とんび = new とんび { type TParent = とんび }
とんび.parent = Option(new とんび { type TParent = とんび })
println(とんび.parent)
}
}

>>55 馬鹿すぎるのはお前。そもそも自分の思い込みが完全にまちがっていることにまるできずいていないｗｗｗ

>>61
「使うプログラミング言語により思考は制限される」
http://www.slideshare.net/yukihiro_matz/ruby-9183142
http://itpro.nikkeibp.co.jp/article/NEWS/20110909/368352/

つまり、静的厨の発想は制限されてるから
動的言語でしか出来ない事は思い浮かばないw

Rubyより劣るScalaを使うと思考が制限されるよ

>>62
静的言語でしかできないこともあるから
両方やれば一番いいんだよな

心を落ち着けて>>56を読むんだ

バイトコード操作で実行時に引数の型を継承したクラスを生成って言う風になら出来るがちょっとずれるか

Rubyのような幅広い概念を取り込んで
いない言語なんてつかっちゃダメだよなぁ

まあアンチがいるだけ言語発展してる証拠にもなるし微笑ましい対応で

>>68
モヒカン言語らしくしろよ

動的言語の方がより制限されていることにまだきづいていないようだなｗｗ

>>69何故俺がD 言語住民と…!

動的言語＋型＋静的型チェック＝静的型付け言語
と考えれば、静的型付けの方がリッチだな。
いらないときは静的型チェックをはずせばいいだけ。

え

scala好きだけどIDEとか未熟だから止めたとかいう英語の記事かなんかが紹介されてたけど、みつけられません。
確かコンパイラ系を作ってる人の文章で、Javaと別のtoolに戻ったとか言ってました。
どんなtoolか知りたいので、もう一度その記事を教えて下さい。

>>70>>72
じゃあ、Dumpクラスを継承したクラスの全ての公開メソッドに
引数と戻り値を出力する処理を追加するようなDumpクラスを
Scalaで書いてみてよ
動的言語なら10行くらいで書けるから

>>75
っ AspectJ

bytecode manipulationなんて卑怯ですう＞＜

>>77
そんな君にはdynamic proxy。

何でも使っていいからScalaで書いてみなよ

そもそもLoggingのweavingを、言語のネイティブな機能だけを使って10行で書けると何かメリットがあるのか。

さすがモヒカン言語
コードは書けないが口だけは一人前

Scalaだけでは書けないよ、うん、終了。
で、それが実用においてどういうデメリットがあるの？ って聞いてるんだけど。

またモヒカンが暴れてる

>>60
暗黙的変換を使って少しましな書き方ができた
でも素直じゃない

class HasParent[TParent <: Base](any: TParent) {
def parent = any.parent
def parent_=(p: TParent) = any.parent = p
}

abstract class Base {
var parent: Base = _
}
class とり extends Base {
override def toString = "とり"
}
class とんび extends とり {
override def toString = "とんび"
}

object AbstractTypeTest {
implicit def toHasParent[T <: Base](any: T): HasParent[T] = new HasParent[T](any)
def main(args: Array[String]) = {
var とり = new とり
とり.parent = new とり
println(とり.parent)
var とんび = new とんび
とんび.parent = new とんび
println(とんび.parent)
}
}

>>83
自分の思い通りにならないとモヒカンのせいにするのはよくないな。

スカラって10回言って。


スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ

巣から落ちた鳥は？

カラス！

死ねよ

>>60
型引数「を」スーパークラスから継承したい場合は、まさに抽象型使えってのがScala流かと思います。あと、
ジェネリックで型引数を継承できるようにしたとして、ややこしくなるだけな気がします。型引数はメンバ
じゃないので、本来継承できるべきものじゃないですし。

あと、ここで「とび」や「とんび」クラスをさらに継承する必要が無いなら、
override type TParent <: とび
じゃなくて、
override type TParent = とび
にしてしまった方がいいのではないかと。そうすれば、new とび { type TParent = とび } じゃなくて、単にnew とび
と書けますし。

スクルト

モヒカンだ助けてくれぇ

みんな飽きてるのにずっとモヒカン言ってるのっていつもの知的障害の人？

>>88
ありがとうございます
override type TParent = とび
継承する必要がないのならこの方がよいのはわかります
それだと継承の可能性を閉じてしまいますのであえてあの書き方にしました

変数の変位（代入互換性）の問題は残るのですが、
こんな書き方が許されたらと思いました

abstract class Base {
type TParent <: Base
var parent: Option[TParent] = None
}

class とり extends Base {
override type TParent = とり //ここで指定しても派生クラスで継承できる
override def toString = "とり"
}

class とんび extends とり {
override type TParent = とんび //ここで指定しても派生クラスで継承できる
override def toString = "とんび"
}

object AbstractTypeTest {
def main(args: Array[String]) = {
var とり = new とり
とり.parent = Option(new とり)
println(とり.parent)
var とんび = new とんび
とんび.parent = Option(new とんび)
println(とんび.parent)
}
}

60,88→60,84 間違った失礼

静的型チェックはずせばいいだけｗ

>>94
ゴミだから間違えるんだよな

お前みたいな奴はプログラムで変なミスするよ

むいてない　死んだほうがいい　しんだほうが　いい

>>96
welcome to http://hibari.2ch.net/test/read.cgi/tech/1312201995/

Scalaだけでは書けないよ、うん、終了（キリッ

http://krautchan.net/files/1315760995001.jpg
↑糞言語の開発者 メガネ、ハゲ、ヒゲなどが特徴

http://lamp.epfl.ch/~odersky/images/Martin.JPG
↑神言語の開発者 なんというナイスガイ！

プログラム板って何か変なのが住み着いてるんだな。

ハゲが二人いる

>>99
美的センスのなさが見てくれにも言語にも表れてるな

scalaがはやると困るやつがいるみたい

メガネ率たかいな

>>100
慣れると避けて歩ける
無視されているのがわかるとなんとかしてレスさせようとどんな変なことでも書くようになるが、
それだと余計わかりやすくなるのでむしろ好都合だったりもする

全然避けられてないじゃないっすか

http://tech.cm55.com/wiki/scala/ruby

こんなサイトがあるからScalaにも粘着が湧くんじゃね？

>>106
避けてるってば
「どんな変なことでも書くようになる」の意味噛み締めれ

>>107
こんなところに書いても世の中は何も変わらんけどな

>>108
自演っぽいのは時々見るよね…

Scala の記述力は動的型言語に遠く及ばない、とか
Scala の structural subtyping や型推論は出来損ない、とか
そういう荒し発言はやめてもらいたいね

慣れると避けて歩ける(ドヤッ

これが荒らしトリガーのレスじゃなくてなんなの(笑)(笑)(笑)
荒らしにアンカでレスしなければセーフとか思ってんのか(笑)(笑)
恥ずかしい奴だ
お前はルビーでも使ってろよ(笑)

はっきり言って旧世代のRubyとか眼中にないんで、しつこく絡むのはやめていただきたい

これが誘い受けというやつか

IDEはほとんど話題に上がっていないが IntelliJ IDEA 使ってる？
結構優れもののように思う
インテリセンスで暗黙型変換のメソッドまで表示してくれる

>>115
IntelliJ IDEAが今のところ自分のScalaメイン開発環境です。Scala IDE for Eclipseは
補完がだいぶマシになって、インクリメンタルビルドがちゃんとできるようになったので、
テキトーにプログラム書くときには重宝しています。

ただ、IntelliJ IDEAのScalaプラグインにはまだ及ばないかな、という気が(個人的には)しています。
(Java + Scalaの)inter-language renamingとか、実装するのが面倒だけどいざというときに必要になりそう
な、そういう細かいところも含めてサポートしてくれて便利だなと思います。ただ、IDEA + Scalaプラグインだけ
だとビルドが糞重いので、sbt plugin入れてます。

なんでながいの？

短文しか読めない理解できない馬鹿を排除するため

三文字で頼む

>>119
かえれ

これはひどい

vimがあればなにもいらないもん！

最近vimとHHKBの組み合わせは偉大だということを知った
……とはいえ、Scalaは本来IDEを使うべきじゃないのか

>>116
Eclipseはうちのマシンだとエディタが遅くて
タイピングに付いてこないので候補に入れていませんでした。
(Java + Scalaの)inter-language renaming そんなことできるんですか
自分は コンパイラオプションで Use fsc(fast scalac)を有効にしたら
結構早くなって満足していたのですが sbt plugin で
もっと早くなるのだったら入れようかと思いました。

Scalaでは戻り値は常に明示的に書くべきなの？

>>125
俺は書く
関数のシグネチャは大事だと思ってるから省略しない

俺も書く
Unitのときも省略しない

俺も書くなー、可読性を維持するためには必要な税金だと思ってるがどうなんだろ

型推論なんていらんかったんや！

まあ型推論なんてJava7のダイヤモンドオペレータ程度で十分なんじゃないの、とは思う

プログラミング言語史上最も可愛いマスコットキャラのScalaちゃん
なぜエロ同人が出ない

死ねよキモオタ

俺は書かない派だったけど、最近なんか雰囲気的に書かなきゃ駄目っぽくなってるね
でも一行関数とか書く気しないんだよなあ

>>130
Hindley-Milner型推論じゃないですもんね
すっぱい葡萄ですね

え、Hindley/Milnerじゃないんだ























わからないのにレスしてみる

>>134
あれってたまに凄いエラーメッセージを返してくるとか言われない？
強力な型推論を採用しちゃうと、型宣言のような
型に関する冗長な情報を書かなくなるので
矛盾があった時にどこがエラーか決定できなくなるんだと思うけど

型を書かなくても、IDEが型推論の結果を表示出来れば
可読性は維持出来るんじゃないの？

あれほどのモヒカンっぷりを見せつけておきながら、
匿名じゃない場所で質問が来ると思ってたのかw
面白い人だなぁ

>>137
Scala IDEの完成度がもう少し上がればねー。

とか言ってたらbeta 10が出た。
http://www.scala-ide.org/2011/09/scala-ide-beta-10-available/

SBT統合とかセミコロン表示とか、楽しげな機能が増えたな。

>>140

そのセミコロン表示機能の紹介
http://scala-ide-portfolio.assembla.com/wiki/show/scala-ide/Show_Inferred_Semicolons

で例として出されているコードだけど

object Test extends App {
　val result = 3;
　　+12;
　println(result)
}

みたいに、意図せず 式が途中で区切られてしまうScalaの仕様はどうにかならないのだろうか？

たとえば、「この先セミコロンを忘れるべからず」 みたいな命令があって、
それ以降は、セミコロンが必須になるようにしてほしい。


Martin先生に直訴したら、機能追加してくれるだろうか？？

>>138
実のところ、それほど多くの質問が来ることは期待してませんでした
ただ、もう少し来るかなーと思っていたのが正直なところです。その辺の
感覚が世間ズレしてるのは認めます

>>142
> みたいに、意図せず 式が途中で区切られてしまうScalaの仕様はどうにかならないのだろうか？

セミコロン省略可能であることのトレードオフというかScala慣れたらあまりぶつからない問題な気がします。私は、

(1) 基本的に行頭に2項演算子は書かない
(2) 読みやすさの問題から、行頭に演算子を置きたいときは式全体を括弧で囲む
例：
val statement: Parser[Statement] = (
while_stmt
| for_stmt
)

という感じで対処しています。(1)は既に意識してない感じです

> たとえば、「この先セミコロンを忘れるべからず」 みたいな命令があって、
> それ以降は、セミコロンが必須になるようにしてほしい。

そういうad hocな機能追加は言語屋さんは嫌う傾向にありますし、文法がさらに無駄に複雑になるという
デメリットもあるので、たぶん採用されないと思います。やるなら、自分でそういうuse("strict");みたいなの
を宣言できるコンパイラプラグイン書くか、CheckStyle的なツール作るしか無いのではないかと。

申し訳ない。>>142は>>141の間違いです。

セミコロンが省略可能なのもナニだけど
ターミネータじゃなくてセパレータだってのもアレ

セミコロンなんていらないだろ
ってこの話題、前もしたことあるような

for式の型はどう規定されているのかな。
for(...) yield eならIterable[eの型]としか保証されていない？

scalaのforはシンタックスシュガーなのでmapやらflatMapが返す型を返す
http://www.ne.jp/asahi/hishidama/home/tech/scala/collection/for.html

scalaのコレクションライブラリはだいたいが自分と同じ型を返すので

for {
a <- hoge
b <- fuga
} yield ...

みたいなのだと最初のジェネレータのhogeと同じ型を返す場合が多い

>>142

セミコロンの対処方法だが、

> (1) 基本的に行頭に2項演算子は書かない

↑こういう記述スタイルが不可になるのは、窮屈だと思う。

たまに、行頭に演算子置きたい時ってあるよね！！
↓

> (2) 読みやすさの問題から、行頭に演算子を置きたいときは式全体を括弧で囲む

なるほど。。このテクニックでなんとかやってみる。Thanks!


ちょっと窮屈だけど、、まあ、慣れるしかないかあ。。

バッドノウハウ

Rubyを笑えない

セミコロン推論は落とし穴でも何でもないな

>>151
> セミコロン推論は落とし穴でも何でもないな

落とし穴かどうかは、慣れで解決する。
それよりか、記述スタイルに制限が付くのが、イヤなの。

文法としては、ステートメントの最後には、セミコロン必須の方が、
文法として美しかっただろう。



今は、改行がステートメントの区切りであったりなかったりと、文法的に美しくない。
慣れで解決するから別に良いのだけど、言語として美しくない。

慣れないと解決しない時点で負けてる

俺は;が必須でも必要なコストとして納得できる。むしろソースコードのフォーマットなんぞの為にケースバイケースを求められるほうが苦痛。

>>152
それほど記述スタイルに制限付くものでしょうか？確かに、行頭に二項演算子とかおきたいことは
たまにありますが、それは>>142の方法で十分対処できる話ですし、頻度もそれほど多いとは思えません。
というか、セミコロン推論は、元々、低頻度で出現するパターンが書きにくくなる代わりに、高頻度で
出現するパターンが書きやすくなる、というものですよね。

また、ステートメントというか式ですね。というのはともかく、セミコロン必須の方が確かに文法はシンプル(美しいか
どうかはおいといて)になりますが、文法の美しさ(シンプルさ？)をそれほど気にするなら、極論を言えば、S式
使ってればいいのでは？とかいう話になってしまうような…。

>>154
両者が同頻度くらいで出てくるなら確かに嫌な話ですが、実際のところ、明らかに頻度の偏りがある以上、私はセミコロン推論が
あった方がトータルのコストは安くなると思います。実際、最近の言語の多くが;相当の省略をどんどん取り入れてるのはそれを
示しているかと。

君がScalaを愛してやまないのは分かるが
無理な擁護は逆効果だぞ

>>156
Scalaを愛しているかというどうかは別の話です。別にRubyとかの他のセミコロン省略できる言語でも構わないです。で、
>>152と>>154の批判に、「嫌い」とか「美しくない」以外の指標での実用的問題が発生するのかなあという話です。
私は経験上、そういう問題が発生することはほとんどありませんでしたし、Ruby等でその事がそれほど問題視
されたことも無かったと記憶しています。結局、頻度の問題だというのが私の認識です。

実際に〜というコードパターンを書きたい事が頻繁にあって、それでScalaのセミコロン推論が邪魔をして困る、
という問題提起なら意義があると思います。

Rubyは文法がどれだけ難解になっても
ユーザー側から見て多くのケースで便利になるなら問題ないという立場だったが、
>>152が言うように文法上美しくないという観点もありえる
Scala的には何を良しとするべきなのだろうね

Rubyはどうだか知らんがPerlやJavaScriptではセミコロンを省略するのは悪い習慣だとされているな

たかだか1文字省略できるだけで大して書きやすくなるわけじゃなし
ていうか書くときに気にしなければならないことが増えてむしろ面倒になるし
文の区切りが分かりにくくなって可読性は落ちるし
場合によっては分かりにくいバグの元にもなるし

まあなんもいいことないよね

まあ、少なくともRubyに比べりゃ分かり易いって
Rubyなんて

p 1 + (1
    + 1)

て書いたら2が出力される言語だぜ？
こんな言語でも実質問題が起きてない（ということになってる）んだからScalaも無問題

>>161
算術記号の名前を持つメソッドに限って、 1.+( 1 ) は1 + 1 と空白区切りで書いてよいという
シンタックスシュガーが影響を及ぼしているので、例としてはあまり適切ではない
p( 1.+( (1; +1) ) );
+メソッドの引数 (1; +1) の戻り値は最後に評価された+1なので、結局は1+1になって表示は2

(1; +1) のセミコロンを省略できることが原因じゃんかよ

基本的には改行で、改行の代わりにセミコロンを書いてもよいという動作
セミコロンを省略してもよい、というのとはちょっと違う

なにその言葉遊び

ステートメント終了の改行をセミコロンで表現することができるというだけで、セミコロンには意味はないってことだろ
まあ他の言語は文化ごと違うので参考にはならんな
>>161だって正しく「（2つ目の1の直後の）改行は文の終わり」と判断しているだけに過ぎん

人間にどう見えるか（慣習含む）は関係なく、正しくパース出来れば良いって話なら
そもそもScalaのセミコロン推論もまったく問題ないがな

連言・選言や並行性の制御を表現するために使うんならいいと思うし、
むしろそれ相当のものは必須だと思うぜ、;。
「無くしても意味通る」とかいうレベルで考えるべき要素じゃ無いと思う。
記号は慎重に、大切に使うべき。

eclipseでのJavaのフォーマッタのように、ツールを前提にしている言語ならセミコロン必須にしたほうが享受できるメリットが大きい。
改行、空白は人間の美的感覚というテキトーなものに左右されやすいので言語的な機能を持たせることは間違い。

Python全否定。

eclipseでのJavaのフォーマッタのように、ツールを前提にしている言語ならセミコロン必須にしたほうが享受できるメリットが大きい。
改行、空白は人間の美的感覚というテキトーなものに左右されやすいので言語的な機能を持たせることは間違い。

Python全否定。

空白を無視といえばFORTRAN66。
マリナー1号のバグは有名。

Scalaスケーラブルプログラミング第2版、表紙をサムネイル画像で見ると
第1版と区別しづらいな…と思ったのだけど、コップが2つになってるんですね。

誰か画像処理に詳しい奴はいないか？
openCV使ってステレオビジョンで視差画像を出したいんだが
誰か心優しい方教えてけろ

スレチ

List(8,6,3,2)の標準分散求めるコードは、mapを使って
どのように書くのでしょうか？

scalaプログラマが愛用してる汎用スクリプト言語は？

val avg = list.sum / list.size
(list map { i => (avg - i) * (avg - i) }).sum / list.size

>>176

基本的には bash のシェルスクリプト。辛くなってくると
ファイルの頭にこれ書いて、何でもかんでも Scala で書いてるわ。

#!/bin/sh
exec scala "$0" "$@"
!#

$ cat a.sh
#!/bin/sh
exec scala "$0" "$@"
!#
print("hello")

$ time ./a.sh
hello
real 0m13.741s
user 0m0.815s
sys 0m2.254s

小さい方にはスケーラブルじゃないな

こういうのってスクリプトに使えたっけ？
コンパイルしてるから関係ない？

http://www.google.co.jp/search?q=scala+groovyserv
http://www.infoq.com/jp/articles/groovyserv

Scalaってなんか実績あんの？
面白そうかとは思うけどただの言語オタの趣味ならやめておこうと思ってる

twitterのバックエンドとか。つか、実績で左右されるって、脆い知的好奇心だな。

scalaでliftとかplayを書いた場合、
javaのwicketやrubyのrailsと
並べて評価した場合どうですか？
言語の違いでフレームワークも結構変わりますかね？

どこに知的好奇心の要素があるんだ

評価を他人に委ねてる時点でだめだろ
>>183が実際使ってみてなにか分かったら報告してくれ
それまで連絡はしなくてかまわん、以上だ

暗黙の型変換を使って、いかにトリッキーなことができるか

同じならマイナーで普及しそうにない言語なんて
時間の無駄だからな

そこで普及するまで待つという手がある

>>178
スクリプトで、サードパーティのライブラリ使いたい場合とか、scalasが何気に便利です。
http://blog.twiwt.org/e/f835d9
スクリプトの最初の方にdependency書くだけで、勝手にライブラリのjar落として来てくれ＆＆そのまま使えます。

>>184
知的好奇心、という面でもScalaは結構面白い試みを色々していると思います。全く新しいパラダイムを提示する、という
わけではないですが、Scala 2.8のコレクションアーキテクチャとかは精巧に作られていて凄いですし、プラグインとし
て型システムを拡張できるおかげで、型システムに関する実験的＆＆そこそこ実用的な試みがしやすいと思います。

あとは、Scalaの型システム自体も、λ計算をベースに発展してきた静的型付け関数型言語とは異なったアプローチ
を取っているのですが、それが、既存の静的型付け関数型言語のモジュールシステムとかとうまく対応付く、とかも
面白いです。

何が面白いかは主観になりますが、ともあれ、単に既存のアプローチを集めただけの言語ではないことは確かです。

>>189
ああ、書いた直後に誤解されるかな、と思った懸念がそのまま…
>>184ではScalaに対して知的好奇心をそそるものが無い、と言いたかったわけではなく、
>>181が求めてるのは知的好奇心じゃなく実用性なんじゃね、その問いに>>182の返しは変じゃね、
ということです。

まぁ「面白そうかとは思うけど」って部分で揚げ足取っただけなんで、そう解説されるとそのなんだ困る。

>>190,191
どうもすいませんorz

ともあれ、実績の話なら、Twitterだけではなく、既にVMWare, LinkedIn, Amazon.com, Foursquare, Novell, Siemens,
Remember the Milkとかそれなりに名前の知られてるのが色々ありますね。求人見ても、Scalaなどの関数型言語の
経験のあるエンジニアを求めてるところも増えて来てる感じです。名前出せないけどとある金融系のところで
使われているとか(Scala Days 2011での情報)。

あとは、前どっかで見た話でソース失念なのですが、githubが一部をScalaで置き換えてるという話もあります。

国内だと、有名なところはあまり無いですけど、有限会社ITプランニングさんとか、GMO株式会社さんとかパテントビューロさんとか、
その他中小/フリーランスで使われているところが少しずつ増えて来てるみたいですね。

全く問題が無いわけじゃないですけど、使える周辺ツールは一通り揃っていますし(sbt, ScalaTest/Specs)、IDEに関してもScala版が
だいぶ進歩した他、IntelliJ IDEAは「普通に使える」レベルになってます。あとは、Scala自体の教育コストとか、チーム開発でのノウハウ
とか、それ以外の政治的な話が問題になってくるのかなあと思ってます。

>>189

確かに便利だけど、java しか入っていない環境に持って行って即座に展開できるようなものがあったらなあ、とも思います。

>>193
TypeSafeの作ってくれたインストーラ使え
ttp://typesafe.com/stack/download

ScalaDays 2011 Resources (Paper | Slides | Video | Home Page)
https://wiki.scala-lang.org/display/SW/ScalaDays+2011+Resources

scala って 関数型系では異質というのか違和感がある言語だけど
IDEの話を読んでて思ったのは、やっぱりjavaの流れでやってる人が
多いんだな。と思った。

なぜ他の言語コミュと上手くいかんのかしらん。でも何かあれば
FUD FUDだからな。S式言語なんて使ってもいない奴がDISるけど
相手にされないのが普通なのにな。いちいち FUDといってるような
無駄はしないわな。ここでも他言語を一人前にDISる連中はおるよう
だけど、わがままだよな。(>>113など)海外のscala使いにそんな狭量を感じる
事は少ないような印象は持ってるんだが。

>>192
｜Scala自体の教育コスト
全てを知らなくても使えるだろうけど、自由度を得るために、複雑な仕様を
みてるとC++と同じに見えることはある。複雑すぎて使いこなせない言語
なんじゃなかろうか？better javaというだけでいいならそれでいいんだろう
けどね。

>>196
Scala関数型言語じゃない
そのように見える機能を集めたOOだろ

>>107
そのサイトも他をDISってscalaを持ち上げるパターンだよね。
別にその信念で使ってることは問題ではないけど、発想が減点法というか
他の言語を使っててDISる人も減点法的に書いて使えないと喚く連中は
見かけるから、阿呆な連中は他にもおるとは思うがね。
優れてるならその点だけ全面的にだして話をすればいいだけなんだけどな。
ここでもそうだけど、rubyへの敵対感はかなり強すぎるよな。なんか幼稚
なんだよね。
松本氏の態度に気に入らない連中も多いのも理解はできるけどさ。

>>198
そうゆう見方もあるね。

>>199
続き、ブログとかでかかれて第三者が読むときって、他をDISって持ち上げる
ような阿呆としか言えない書き方より、どう使って行ったらいいか？という
ことを書いてくれて特徴を生かせるアイデアを出していけばいいんだよね。
言語が複雑になれば、関数や機能が似通ったもんだとかよく使い方がわからない
ものは増えるけど、どんなときに有効か分かるだけでずいぶん読者は参考になるよね。
だけど、DISるだけというのは、それ以上の情報が含まれないから、読む価値
としてはあまりなくなるよね。

Scalaってインテリが使って満足する言語でしょ
DISられて当然じゃないか？

>>196
＞なぜ他の言語コミュと上手くいかんのかしらん。
一般論として、Scala特異の事情があるかというと、どうなんでしょうね。他の言語コミュニティとの
摩擦というのは、それなりに名前が知られてきた言語だと大体とこでもある話のような。

＞海外のscala使いにそんな狭量を感じる
＞事は少ないような印象は持ってるんだが。

コアなScalaistがJavaをこきおろしまくってるのは結構よく見ます。ただ、大体そういう人たちは
生産性の問題から真剣にJavaを嫌がってて、Javaをこき下ろしたい、という印象はあまり受けないです。

ちなみに、海外のScalaistがML/OCaml/HaskellとかCommon Lisp/Scheme/ClojureをDISってるのは
ほとんど見ないです。というか、JVM系言語で言うと、Clojureとかの人たちがむしろScala意識しまくりで、
コード行数の比較の話になると、かなりの確率でScalaが出てきます。

あと、Scalaコミュニティの人(海外勢含む)は不当なDISりには結構敏感で、CeylonやKotlinの
中の人が根拠レスの「Scala is too complex」マーケティング展開したときは、中の人のブログ
がかなり炎上してました(根拠レス、というのは、本当に"too complex"だけしか言わなくて、
どこが"too complex"なのか、というまともなDISりが皆無でした)。Ceylonについては、Gavin King
が、捨て台詞吐いてブログ閉鎖するくらいの勢いで。あと、Odersky先生ご本人が、不当なScala DISが
あったらブログにコメントとかしてるのを時折みます。

2chの煽りレスを真に受けて日本のScalaコミュニティを語る馬鹿がいると聞いてやってきました

Scala is too complex

> 生産性の問題から真剣にJavaを嫌がってて、

こういうことをサラッと書いてしまうのも、
また理由があればdisって良いという思想もヤベェw

理由があればディスってもいいんじゃねーの
JavaもC++もいたるところでディスられまくってるけどね
C++なんかよく耐えてるよな
実際ディスってるやつでC++使ったことないやつも多いだろ

>>205
いいんじゃないか？言語作者自信が、ブログ炎上させて閉鎖に追い込んだりと一部では、思想体系がネオナチに近いって言われているからな。

酷い日本語を見た

むしろ日本の問題点はこういうところだろうな
なぜか言語じゃなくて個人攻撃になる
コミュニティがどうとか口調が怖いとか
そういう低レベルなところでしか言語を語ることができないのが問題
英語読めないやつが多いんだろうな

反論があればかかってこいやぐらいの気概があればdisもいいんじゃねーかと思う

反論でファビョったり、一方的な言い逃げとかだとあららって感じ

>>206
DISるのって根拠が不十分なことも多かったり、実際に使ってない
状況で、オナニーしてるだけのもあってね。それは水嶋さんが
書いてるような傾向もあるんだけど、他のところならスルーする
ところがこっちではFUDだとか刈込にいったりするからな。
おかしいんだよな。

disるのって大体が極論なことが多くってね。参考にならないことがある。
たいてい会話が成り立たないから、炎上してしまうんだろうな。
言語界のネオナチか。。。なんでそこまで陶酔するんだろうか？
Scalaに麻薬的要素があるの？ 知らんねんけど

宗教論争は麻薬
言語でも何でも

スカスケ2版amazonから発送通知来た！

>>210
disじゃなくてただの感想言っただけなのに突撃してくるイメージ。

そしてその突撃は正当なものと信じて疑わず、
「議論できないのは日本人の悪いところ」と言わんばかりに揚げ足を取り、
挙句には「◯◯を示せたので満足です」「実は◯◯は重要だとは思っていません」などと捨て台詞を残して去って行く。

うむ。なるほどモヒカンだな

たぶんScalaユーザーを減らしたいんだろう

技樹的に間違ったことを書いておいて、それを指摘されたら人格攻撃にすり替えるんだから
日本のネットのプログラマーは救いようがねえな
しかも本人には言えず2chでネチネチと叩くんだから酷すぎるわな

何でも一般化しようとするな

http://mobile.twitter.com/tatsuya6502/status/117520413545873409
http://mobile.twitter.com/tatsuya6502/status/117522292564692992
>38
これって、主にJVMのGC実装の問題で、
追加でscalaの不変データ構造の実装の問題なのかな。

http://www.infoq.com/jp/news/2010/09/bigmemory
こういうやつのscala版が必要なのか、akkaあたりで良いのか
http://akka.io/docs/akka/1.1/general/jmm.html

clojureで、scalaと比較が多くなるのは
JVM言語でとりあえず両方触れるぐらいの人が多いのと、
あとは、たまたま当時のscala実装(>221)で商用アプリの実装が上手いかず
clojureを使ったら上手くいったという、経路の書き込みが多いから。

移行時に行数が出てくるのは当たり前だけど、
javaからrubyに移動した時と同じ話で
静的型チェックを補うテストコードまで考えていないし、
scalaでチェック済みではあるので、rubyでテストコードが膨らんでscalaに移行したら総行数減ったというのとは
ちょっと違う。

そして、cl,schemeと行数比較する機会や意味はあまりない。

2.8から不変データ構造の実装変えてたよね？
twitterの話は、2.8以降の話なんだろうか？

>>221
http://mobile.twitter.com/tatsuya6502/status/117522292564692992
の書き込みは、一部勘違いがあるのではないか、というのが私見です。原理的に、現在のSTW型のGCは、
色々工夫されているとはいえ、メモリ量に応じて最大停止時間が長くなる傾向があるので、
特にメモリ搭載量がどんどん増えてるサーバでは、そっちの方が問題なんじゃないかと。Erlang VMのGCは
詳しくないですが、Erlangの複数のプロセスでGCが走ったらやっぱり問題が起きるような気が…。Erlang VM
のGCは詳しく無いので、外してるかもしれません。


>>223
clojureも不変データ構造が基本なので、scalaでダメで、clojureで上手く行ったとしたら、それは当時のScalaの不変データ構造の実装が
あまりこなれて無かった、というのがあるでしょうね。

>>224
Continuation Workshop参加してましたので、Scala < 2.8なのかそれ以降なのかわからないですけど、今のJVM(1.6.0 u24以降くらい？)だと
エスケープ解析が効くので、関数型プログラミングでよくあるパターンの、大量の短寿命オブジェクトによる実行コストの増大はかなり減らせます。
実験的に、implicit conversionで短寿命オブジェクト生成しまくるベンチマーク取ってみましたが、うまいことスタックにアロケートされてるっぽく、GCが
ほぼ起きてなかったです。あと、immutable objectがGCと相性悪いか、というと、使い方の問題も大きいと思います。2.8で導入されたVector
型はかなり効率が良くて、コンパイラ内部にこれを導入しただけでパフォーマンスが結構改善したという話があったり。

Java 6を採用できる現場がどのくらいあるのか、って話は別にあると思いますが。

ClojureとScalaが好きって人は海外のClojure使いのサイトを見ればよくいる
印象があるけど、ここって前スレの後半にもあったけどClojureを敵視してる
人たちがいるよ。特に敵対する必要もないのに無駄に敵をつくろうとしてる。

もう、めんどくさいからgithubに多くコミットしてる奴の発言が一番正しいことにしようぜ。

>>226
私が見ている範囲がずれてるのかもしれませんが、設計思想の根幹が違うこともあってか、
(Clojureが好き∧Scalaが好き)という方はあまり見かけないです。Clojure作者のRich Hickeyご本人
からして、Scalaには批判的な立場で、実際にpublicな場で"Scala isn't really a functional language"
等等のという批判をしています。

ちなみに、Clojureを敵視しているScalaな人は、国内でも海外でもほとんど居ないです。Scalaな人が、
Clojure --> Scala という批判への応答として、Clojureコミュの人に何か言うことはあっても、積極的に
Clojureに勝負を挑むモチベーションがそもそも無いだけだと思いますが。

ここでClojureを敵視してる人を何名か見かけるのは事実ですけど、それが原因でClojureコミュニティとの軋轢を生む
というのは杞憂じゃないかと。

正直なところ、Clojure言語そのものを羨ましいとは思わないのですが、I/Oも含めて(準)標準ライブラリが揃っているのは
良いなあと思います(ScalaはI/Oが…)。

>>228
日本人で「ぼくのかんがえたさいきょうのIOライブラリ」を作って世に問うというのはどうか。

>>229
それはとても楽しそうな案だと思う。

Scala isn't really a functional language は的を得た感想だと思うけど。
個人的には。

OCaml isn't really a functional language

>>231
素直な感想を書くとそうかもしれない。でも、受け取る側は批判ととる。
これがSCALAクオリティー

>>231
その言葉が述べられたコンテキストをはずしてたのがまずかったですね。コンテキストとしては、
Scalaはpurityをプログラマに強制しないので、関数型言語としては不適格というもので、
関数型プログラミング＝良いもの、という前提に立ってる人の言葉としては、十分な「批判」だと思います。

ちなみに、私自身はRich Hickeyの批判に妥当性が無いとも言って無い、というか彼の立場からすればある程度妥当だろうとすら思っている
ということは付け加えておきます。念のため。

Perl忍者は偉大
Perlの知名度を上げPerl業界に大きく貢献した

◆CgacaMDhSQでは話にならない
帰れ
Perl忍者様に土下座しろ詫びろ

巣に帰れよクソ忍者

P忍 って Scalaモヒカン としてここで現れる予定だろ？

Scalaサムライと聞いて。

変なID粘着してからまともな議論
何もないけどこのままでいいのかな

では、俺らの考えるさいきょうのI/Oライブラリの要件出しでもしようか。

そもそも俺はScalaのIOのどこがヘボいのかすら把握してないのでそこから頼む。

へぇー

We will have a PrePrint of Greg's book out soon, with final publication set for early next year.
http://www.scala-lang.org/node/10448#comment-47711
http://www.biosimilarity.com/publications.html

歴史秘話ヒストリア
http://www.amazon.com/Pro-Scala-Monadic-Design-Patterns/dp/143022844X （発売中止）
Monadic Design Patterns for the Web has moved to Artima
http://comments.gmane.org/gmane.comp.lang.scala/19713

関数型IOだと、こういう話になるのではないか。
Scalaz Tutorial: Enumeration-Based I/O with Iteratees
http://apocalisp.wordpress.com/2010/10/17/scalaz-tutorial-enumeration-based-io-with-iteratees/

最新のJAVA APIでScala/JVMの関数型IOが高速化することが
できたら実装する人いるんだろうか。

発信源のHaskellさんの記事もろもろ
http://www.google.co.jp/search?q=Enumerator+Iteratee

そういえば、この人たちもscalazの本かもしれないけど、Functional Programming in Scalaという本を執筆中。
http://www.scala-lang.org/node/10448 （上のリンクと同じ）

>>244
スレッドの最初から出てくる、Tony MorrisはScalaz始めた人ですね。ただ、スレッドを流し読みした感じ、
Scalazの本にはならないんじゃないですかね？本の中で紹介とかはしそうですが。

ttp://hibari.2ch.net/test/read.cgi/tech/1316016777/438

俺もそろそろScalaz習得して優越感ポイント稼ごうかな

じゃあ俺は圏論はじめまつ

コップ2のp702、
「Scala2.9.1はScala2.9.0.1と完全にバイナリ非互換であることを目標にしています。」
ってどういう意味？いや意味というか意図というか。前後の文章とのつながりがわからん。
あと、バイナリ非互換って目標にするようなものなの？

PEPLとREPL(p703)って別物？誤植なのかな？

つーか2.9.1の話まで載ってんのか
ギリギリまで書いてたんだな

ミズシマさんﾊﾟﾈｯｽ

だが、正直キモい。

キモカッコイイ

>>249
申し訳ありません。それは誤植です。「バイナリ互換であることを目標」が正しいです。そう読めば意味
が通るようになっています。Twitterで既に何名かの方に指摘を受けているので、正誤表に載せていただくようにします。

>>250
一瞬何のことだかわからなかったのですが、p.703のリスト99.1ですか。これも誤植ですね。
同じく、正誤表に載せていただくことにします。ご指摘ありがとうございます。

>>251
それほどギリギリ、というわけではないのですが、大体書籍が出版される頃には2.9.1が
出てるだろう、という目測が立つくらいの時期ではありますね。ちなみに、誤解されると
申し訳ないので言っておくと、2.9.1 finalそのものの改善点(REPL高速化など)については
載っていません。記事自体もページ数の制約もあり、あくまで2.9新機能の概要なので、
おまけ程度に思っていただければ。

>>253
明らかに誰かわかる形でコテハンやってる時点で既にキモい奴だなあと自分で思います。

このスレ初めてなのですが、◆CgacaMDhSQさんは、Scalaの本の著者なんですか？

>>256
mizushima kagerou
でググれ

Scalaエヴァがんばってください
うごいてよ！今動かなきゃ(ry

Scales Xml 0.2
Performance, Flexibility and Correctness Improvement
http://implicit.ly/scales-xml-02

ライブラリー実装:
ミュータブルのが速いし省メモリだよ派
遅延評価寸止め革命中の今がのし上がるチャンスだよ派

とうとう みずしまはんも カリスマ性を帯びてきたか。

>>259
そっちも気になってたんですけど、@djspiewak の
Anti-XML https://github.com/djspiewak/anti-xml
も標準のXMLライブラリよりフットプリントが軽くて、
かつimmutableなのをウリにしてるんですよね。ちょっと
ベンチマーク取ってみたいところですね。

akka1.1のデータフローAPIに登場するFuture/Promiseって、
javaのFuture/Promiseと別物？
Scalaの限定継続プラグインを使っているみたいだし。
http://akka.io/docs/akka/1.1/scala/dataflow.html

>>261
なるほどっすな。
Scala2.8の登場で、XMLをもっとうまく実装できる環境が整ったんでしょうね。


そして、これは有望なWebフレームワーク？
BlueEyes
https://github.com/jdegoes/blueeyes
A lightweight Web 3.0 framework for Scala, featuring a purely asynchronous architecture, extremely high-performance, massive scalability, high usability, and a functional, composable design.

Sinatraクローン（Scalatra）をネタに上を目指すとか。MVCならLift使えとか。

ms単位の差が問題になるパーサを作っているのですが、
scalaで高速なパーサを作る定番はあるのでしょうか？
パーサコンビネータライブラリしかないのかなあ。

>>264
Scalaのパーサコンビネータライブラリは、速度が重要になるパーザを書く用途には
本質的に向いていません(これはコップ本にも書かれていますが、Scalaのパーザコンビネータライブラリの
実装によるところが大きいです)。

速度的に、それよりもっと良いものとして、@djspiewak の GLL Combinators
https://github.com/djspiewak/gll-combinators
というのがあります。これもパーザコンビネータですが、Scala標準のものより速度が出るように
設計されています(特に、LL(k)文法に収まる場合)。

もっと速度を追求したい場合は、既存のJava用パーザジェネレータを使うという手もあります。いくつか
注意すべき点はありますが、基本的にScalaから問題なく使えます。ANTLR辺りが個人的にお勧めですが、
この辺は(必要に応じて)どれ選んでも良いと思います。性能がかなり重要とのことなので、実際にいくつかの
パーザジェネレータで簡単なベンチマーク取ってみるのが良いかと。

最後に手書きの場合ですが、Scalaで手書きパーザで速度出したい、となると、どうしてもある程度手続き的なコード
書く必要があって、その場合、本質的にJavaとあまり変わらないコードになります(型推論とかで多少楽はできますが)。

>>262
概念的にはjava.util.concurrent.FutureとAkkaのFutureは類似のものですが、
AkkaのFutureはモナドなので、他のFutureから簡単にFutureを合成できたりと、
機能がよりリッチなものになっています。で、Promiseですが、これは
java.util.concurrentには無いもので、データフロー変数と呼ばれるものを作成
して、後からそこにFuture型の値をくくりつけることができるようになっています。

>>265
ありがとうございます。
やはり標準のパーサコンビネータは向いてないようですね。

GLL（GLRのLL版？）をまずは試してみます。

scala実践プログラミングを母校の図書館で借りたんだけどあまり人気ないみたいね

>>268
尾崎のクオリティが低いばかりに…申し訳ありません…

そろそろ名誉毀損とか、そういう言葉を持ち出した方がいいのか。

ループの外側でリストを生成して、直下のループのなかでTuple2オブジェクトを生成して、そのリストに追加して行く。(ループ回数は不定)
このコードってどう書くの？
リストにタプルを追加しようとするとtype mismatch になっちゃう。

>>269-270
コンセンサスがとれているならともかく、まあ確かに、具体的にクオリティの低い箇所を
具体的に指摘すべきだよな。

本人の自虐だと思った

>>271
Scala歴二日のHaskellプログラマが書いてみました
意図どおりですかね？
たぶんエラーになったコードを貼ったほうが思い違いが少なくてよいと思います

var l : List[(Int,Int)] = List()
for (i <- List(1,2,3)) {
l ::= (i, i + 1)
}
println(l)

Scalaキモいなあが二日間いじった感想です
subtypeキモいです
これからこのスレでお世話になろうと思います
よろしくおねがいします

>>271
タプルを囲むカッコを書いたつもりで、実は引数のカッコを書いていた、
というのがありがちだから、とりあえずタプルのカッコを更にカッコで包んでみるんだ。

>>274 >> 275
ありがとう！
どうやらListの宣言の時点で間違っていた（理解していなかった）みたい。
object GetOptions {
def main( args:Array[String] ){
var list:List[(String,String)] = List()
for ( i <- 1 to 10 ) {
//list =:: "a"+i -> i.toString()
list = list ::: List("a" + i -> i.toString())
}
println (list)
}
}

普段仕事でJavaとPHPしか触らなくて、まったくScalaの勉強が進まなかったから、とりあえずPerlのGetOptions
みたいなものでも作ってみようと思っていきなり躓いてた。

>>276
ListBuffer使えばいいと思うよ

object GetOptions {
def main(args: Array[String]) {
val buf = new scala.collection.mutable.ListBuffer[(String, String)]
for (i <- 1 to 10) {
buf += "a" + i -> i.toString
}
println(buf.result)
}
}

>>276

(1 to 10).map(i => "a" + i -> i.toString)

または

for(i <- 1 to 10) yield i => "a" + i -> i.toString

どうしてもリストが良ければ、最後で

toList

でどうでしょうか

Scala 2.9.1 ＆ Akka 1.2 のお手軽インストーラ
「Typesafe Stack 1.1」がリリースしてるよぉ

http://typesafe.com/stack/download

こっそり同僚のPCにインストールするのに便利！

Finagleはまだscala2.8.1だし食い合わせのいいakkaにしようかな

>>280
何を作る気なんだ？

>>278
元々の質問読んだら？

akkaり〜ん!

アニオタきめえ

日本のScalaユーザの大半はアニオタだろ。お前も含めて。

Haskellほどではないな

Haskellやったらかわいい彼女やかっこいい彼氏が出来るらしいけど、
Scalaやったところでモヒカンになれる気しかしねぇぜ！

酢辛って感じ

やっぱさー
文系馬鹿がScala使ったところで、ベタージャバにしかならないね
文系にはオブジェクト指向

文系くん、ベターな日本語で頼む

どうしたのおっさん？年下の上司にScala却下されたの？

ベターなJavaでも、全然OKだと思う、、。


だが、問題は、Java自体が人気下降気味なこと。
Android関連で、また、盛り返してくれればうれしいけど。

Javaは、GUIとかがイマイチ垢抜けないよね。
SwingXとかでサクサク作れる開発環境があると良いのだが。

Javaはオワコンだろう

AndroidのJavaはOracleに訴えられちゃったからね……

Java言語とJVMは分けて考えろよおめーら

jvmのjava離れ

jvmってジャヴァで実装されてるんですか？

Squawk VMの話？

「すっからかん」に「あっかん」やろ？関西弁にしたらすからはあかん
のや

>>299
つまんねえんだよクズ
これだから土人は…

>>300
頭がすっからかんなのね。気の毒に。

荒らしはスルーでお願いします

普及率を考えるとWebはPHP >> java >> rubyの順でずっと席巻してそうだな。
scalaはベターC++を目指したD言語と同じ末路確定

ちょっと何言ってるかわかりませんね

Facelets/JSF2.xみたいなのがScalaで書けたらなぁ…。

Scalaの日本語wikipediaの記事を見るたびに、いたたまれないというか、悲しい気持ちになる。

>>303
言語仕様に優れ、C言語と連携もばっちりのD言語は
かつてベターC++と一部で騒がれたが、結局は普及率せず風前の灯し火
scalaの立場と似ているだろ

そして言語仕様の酷いPHPが普及率で君臨し続ける

>>307
別に国内での普及率なんてどうでもいいなぁ
俺はScalaが気に入ってるから使うけど、JavaやPHPが好きな人はそれを使い続けてればいいと思うよ

D言語はともかく、信頼できる体制でメンテされる言語なら仕事でも使いたいじゃん
だから普及してくれないと困る

>>309

同意。

とりあえず一度普及してくれれば、その後もメンテされ続けるからなあ。

>>303 >>307
しかし何故に比較対象がPHP…？？
C言語とかも出てくるし、どういう分野での話をしてるのだ？

国内はともかく、海外では、著名なサービス(Twitter, LinkedIn)を提供している会社が何社も使っていますし、
著名じゃない所でもScalaを採用している会社が増えています。Typesafe社という形でサポートビジネス等を
立ち上げたからには、それらの会社が軒並みScalaを破棄するという事にならなければ、当分はメンテされるでしょう。
Typesafeがどれだけ儲かってるかはわかりませんが、主要メンバって結局はEPFLのScalaチームなので、Typesafe
が儲からなくてもメンテナンス自体は継続可能な状態ですし。

あと、互換性の問題を無視して言語仕様を拡張しようとしても、公式MLで文句言う「仕事でScala使ってるユーザ
(海外)」がそれなりに居ますし今後しばらくは「破壊的な」言語仕様の変更は起こらないと思います。

JVM依存が無くなってくれれば……

http://www.youtube.com/watch?v=jAMNyqYLh78
小田好先生ってこんなイケメンだったんだな

>>314
Odersky先生に会った個人的な印象としては、ナイスミドル、という感じでしたね。なんか顔つきがあまり泥臭くない
というかw あと、結構情熱家だなあ、とも。

>>313
使う人がいなくなる。

.NET移植が順調に進んで、進みすぎて本家追い越すくらいになればあるいは
でもあれIKVMだったっけ？

コンパイルターゲットがJVMなのは、各種のJVM資産が使えるというメリットもある一方で、
環境が限られるというデメリットもあるよねえ。
、
まあ、OpenJDKとかもあるから、JVMがなくなることはないと思うのだけど、、。


あと、JavaならGWTで JavaScriptに変換できるけど、
Scalaではそういうのないの？？

The Scala Compiler Corner, for .NET and Mono fans: A collection of resources for compiler hackers focusing on the MSIL backend of the Scala compiler
http://lamp.epfl.ch/~magarcia/ScalaNET/
jdk2ikvm: A source-level conversion tool to migrate Scala programs from JDK to .NET
http://lamp.epfl.ch/~magarcia/jdk2ikvm/
ikvmを使ってconvertするみたいだけど、よくわからん

>>318
＞あと、JavaならGWTで JavaScriptに変換できるけど、
＞Scalaではそういうのないの？？
あるよ。
http://scalagwt.github.com/
まだ正式リリースは無いが、GWTのJavaで書かれたデモ(に相当するScalaコード)ほとんどがコンパイル/動作できるくらいには進展してる
らしい。

s2jsというコンパイラプラグインもあるが、俺の所で動いたためしがないな。

JVM抜きでは衰退するというのは、ScalaってJava使いから来てる人
が圧倒的に多いようだからだよ。逆に言えば、Java使いから魅力が
あっても、それ以外からは魅力がない言語ということを暗に意味してる。
C＃なんかも.NETじゃなかったら普及してないだろう？それと同じ。

今のところJVMの問題よりJava文化の恩恵を受けているほうが遥かに大きいだろ

今更だが、並列コレクションを使ってみた。
確かに全CPUを使いきってくれる。
手軽だね。

ただ、共有データを操作する際にロックは必要だと思うけど、見当たらない。
これはJavaのロック機能を使えということなのかな。

Javaの経験のある初心者です。scalaすごくいいですよね。Javaで面倒くさいと思った部分（ex　new）をいろいろ楽にしてくれているし。
これが広まらずに終わるのって正直やだなと思います。
scalaが信用され利用できる範囲が広がる事を祈ってます。

>>324
まず、並列コレクションでは、明示的なロック操作を行う事は基本的には想定されていません。
並列コレクションのモデルは、いわゆる「暗黙的な」並列化という奴で、不変コレクションを使って
いて、共有データを高階関数内で書き換えなければ、処理が並列化されている事は、プログラマ
から「見えない」というものです。ですから、そもそも並列コレクション専用のロックメカニズムは
用意されていません。Javaのsynchronizedを使うことはできますが、基本的にそれはやらない方
が賢明です。

ロックを使う必要がある場合には、ロックを使わないでいい形に、並列コレクションを使った処理にうまく
変換するか、Actorなどの「明示的な」並行処理を提供するライブラリを利用するべきです。

プログラミング初心者なんですが、コップ本とSICPはどちらがためになりますか

その前置きが必要な質問か

高校生でお金がないので、どちらか一冊を読み込もうと思っています

そりゃSICPのほうが役に立つだろうが、通読するのはなかなかきつい
特に日本語版

図書館か図書室の司書に言って買ってもらえや

SICPなら工学部がある大学の図書館に行けばあるかもね。
そこの学生じゃなくても入館はできるよね？

最近のデジタルネイティブのネイティブっぷりはほんと驚異だなぁ。

SICPはプログラミング(もっというとコンピューターサイエンス)を
学ぶための手段としてSchemeを使う本で、コップ本はScalaを学ぶための本。
だいぶ毛色が違うんで目指してる方向が逆ならそれぞれ役に立たない。

それから、ほんとにまったくプログラムしたことない状態なら
コップ本一冊だけでやるのはかなりきつい

任意の関数を受け取って、その関数をラップした同じ引数の新しい関数を返す関数ってタイプセーフに書けますか？

>>335
任意の関数を受け取る時点で無理じゃない？

def wrap[T,R](f: Function1[T,R]) = (t: T) => {
println("wrapped")
f(t)
}

こんな感じでFunction0からFunction22用まで定義するとか

ちょっと違っちゃうがwrap呼ぶ前にtupled呼んで1つのタプルを引数に取る関数に変換すれば

tupleですか。ありがとうございます。

一応やりたい事のサンプルみたいなのをpythonで書いておきます。
型のない言語だと可変長引数でなんとでもなるのですが、
タイプセーフにできないものかと思いまして。

...def wrap(func):
... def cls(*args, **kwargs):
... brfore()
... try:
... return func(*args, **kwsrgs)
... finally:
... after()
... return cls

こういう感じでラップ前と同じ引数で呼び出せば
実行前になんらかの処理を実行してくれて、
かつ呼び出す側はラップされてるかどうかを
意識する必要がないという状態にしたいです。

できなければいくつか引数の違う関数を作る方法で妥協するのが一番かなと思ってます。

Scalaで書いてから質問しろよｗ

俺よくこういうコードを書くんだがもしかしてこんなので代用できねーか？

def wrap[A](block: => A): A = {
　before()
　try {
　　block
　} finally {
　　after()
　}
}

wrapに渡すときに引数も一緒に渡す
wrap(hoge(a,b))

やりたいことと違ったらゴメンだが

詳細がわからないから何とも言えないけど、
どうも発想の筋が悪いというか、関数型っぽくないというか

>>341
関数型ではデコレーターとかあまり使わないのでしょうか？
代わりにどのような方法で代用するのでしょうか？

ログ出力とか楽なのになぁ。

普通の関数型言語は、1引数関数しかないので何の問題もない。

残念ながらscalaはJavaとあわせるという制約があって、そうなっていないので
ちょっとぎこちなくなるね。

>>330-334
レスありがとうございます
JavaとJavaScriptは少しだけ書けます
JavaもJavaScriptのように自由に関数を扱えればいいのにと思っていたところ
Scalaを知って大変興味を持ちました

SICPは翻訳も内容も難しいとのことですが、挑戦してみよぅと思います
Scalaプログラマの皆さん、ありがとうございました

>>344
SICPは何年かかっても読む価値のある本だ
問題も解けよ。感動がある
分厚いので挫折しそうになるが、なんとか二章までがんばれ
偉そうなこと言えるレベルになるぞ

SICPは前半は抽象化の話で
後半はmeta circular
重要だけどちょっと毛色が違う

>>343
なるほど！
1引数の関数しかないってことですか。
じゃあ関数をカリー化する関数を作れば
なんとかなりそうな気がしてきました。
ありがとうございます。

def wrap[T, U](func: T => U): T => U = {
val r: T => U = {...}
r
}

こんな感じ？

scalaからJavaで書いたクラスのメソッドを呼び出すとき、
そのメソッドと同名のフィールドがあると呼び出せません。

public class A {
private int m;
public int m() { return 0; }
}

--- scala

def f(A a) {
a.m() <-- エラー
}

scalaではメソッドとフィールドの名前空間が同じためかと思うのですが
回避策はあるのでしょうか？

ここよりいい解説知りませんか？

http://twitter.github.com/scala_school/basics2.html

こっちだった

http://apocalisp.wordpress.com/
http://www.codecommit.com/blog/ruby/monads-are-not-metaphors

>>350
http://dl.dropbox.com/u/261418/Monads_are_Elephants/index.html
これを貼れというステマですか？

Scala IDE for Eclipse入れてjavaのプロジェクト触ってるとよくScalaのライブラリを
ビルドパスに追加するか聞かれてうざったいんだけど、これ消せない？

>>327
SICPを読むくらいならHaskell勉強した方が学びやすいし、ためにもなると思うよ。
基礎的な勉強がしたいならTAPLの方がオススメ ttp://www.cis.upenn.edu/~bcpierce/tapl/

ITProで新しいScalaの連載始まったね。けっこうわかりやすい。
「Scalaプログラミングに欠かせない機能---Scalaの基本4」
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370491/

始まったね、とかいいつつ最終回の記事を紹介するとは

>>355 あれ、これって4回で終わりなの？もっと連載してほしいのに。

>>356


連載っていうか、もともとは月刊雑誌の一回だけの特集を、Webに乗せただけ。


日経ソフトウェアの2011年6月号 　pp.78-79 が、
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370488/
変数とクラスを学ぶ---Scalaの基本1

同じく pp.85-87が
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370491/
Scalaプログラミングに欠かせない機能---Scalaの基本4


だから、最初から これで完結だよ。

HaskellもOCamlも、定義したヴァリアントはデータ型の内部構造を
直接さらしてしまう、という欠点を持っているけど
Scalaではケースクラスにしつつ内部表現を隠蔽することも簡単にできるらしい

これってどういうこと？

プライベートなメソッドを持てるかどうかって事？
なんかOCamlとかでもできそう。

Haskellならデータ構築子をモジュール外に公開しないことで可能
内部と外部の境界がモジュールなので、クラスとかに比べたら少し大きい

発想の基本がOOPの言語と発想の基本が関数型では違ってくるよ。
ありがたがってる土俵が関数型のプログラミングではあまりありがたみが
ないというのはよく有りそうだよ。

関数型言語ではそもそもアクセスされて困るプロパティが作れないからなぁ。

>>362
何を言っているのか理解できないので
くわしく教えて

そもそも、関数型でOOP的なものが必要なところは限られてる。シミュレーション
をやるなら重宝するんだけど。でもScalaをやってる人のソースを見てるとやっぱり
関数型っぽくないというのかJavaの後継という使い方に見える。
関数型のスタイルでScalaをやってるブログなどがあったらぜひ見てみたいので
英語でもいいし教えてね。

scalaz界隈をうろつけばいいじゃない（想像）

なぜScalaモヒカンは他言語をdisるのか
それも詳しく知りもしないくせに

>>366
いいじゃん別に
disらせとけば
なんか不利益でも被ってんの？

不利益を被ってないなら黙ってろって？
どうせScalaをdisられたら顔真っ赤にして反論するくせにw

うむ、disられたら顔真っ赤にしてキッチリ反論するのはいいと思うよ
2chの言語スレに来てグダグダいうよりはよっぽど

>>358
ocamlのvariantもモジュールで隠蔽できるから、
たぶんそれ書いた人の勘違いじゃないか？

sbtのtestの出力結果ってwinではカラー表示できないの？

>>370
たぶん書いた本人です。
>>358はちょっと誤解で、元の発言は
http://twitter.com/#!/kmizu/status/128044795615653888
http://twitter.com/#!/kmizu/status/128045117264248832

これはこれでちょっとわかりにくいですけど、要はパターンマッチ使いたかったら
variantの内部構造さらさなきゃいけないけど、Scalaだとパターンマッチのために
内部構造さらさなくても良いよね、という話です。

Haskellだとviewパターン、F#ならActive Patternがあるので似たような事が比較的簡単に
できますが、少なくともOCamlではvariantの構造をさらさなければパターンマッチング
できない(モジュールにvariantの構造を隠蔽しちゃうと外からパターンマッチングはできない)と
認識しています。もし間違っていたら、文献へのポインタを教えていただけるとありがたいです。

>>364
>>365が挙げてるようにscalaz界隈の人(単なるマニア向けライブラリに見えますが、意外にこれ
使ってるScalaプロジェクトは多いです)はかなり関数型的なスタイルやってますし、sbtも
かなり関数型的なコードになってます。全体的に見て、関数型スタイルでScalaプログラミング
やってる人は以前に比べてかなり増えてる印象です(少なくとも海外は)。

あと、ブログでも、関数型的なスタイルでScalaやってるところは、たくさん見つけられるかと。
@djspiewak さんのブログとか、@jamesiry さんのブログとか、色々ヒットしますよ。

actorでreplyするとAny型じゃん．
Int型の値に代入すると怒られるんだが，match文使わずにエレガントに
代入したい．

>>372
variantの構造、で何を指してるのかがイマイチわからない
例があると良いと思う

あ、良く読んでなかった。F#のActive Patternsねー
あれと同じことをOCamlでやるにはパターンガード使うしか無いけど、
それでパターンマッチできてるとは言わないわな

個人的にはパターンって内容を取り出すのが目的だと思ってた

Scalaは型ちゃんと書くから2nd order polymorphismが表現できてもよいと思うんだけど
(つまり、forall をいろんなところにつけれる)
例えば:
def foo(id : [A]. A => A) : Unit =
　id(id)(())
これが普通にできればMLやHaskellより明らかに強力と言えるのではないか。

>>376
ですよねー

多分この中のどれかにやりたいことがあるのでは？

(* データ型の隠蔽 *)
module type S1 = sig
  type r
  type s
  type t = Foo of r | Bar of s
end

(* コンストラクタの隠蔽 *)
module type S2 = sig
  type t = private Foo of int | Bar of string
end

(* 幽霊型 *)
module type S3 = sig
  type s = Foo | Bar
  type 'a t constraint 'a = s
end

Camlp4使うしexperimental featureだけど一応こんなのあるみたいっすよ
http://martin.jambon.free.fr/mikmatch-manual.html#htoc10

>>377
書いてみた
import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id.apply[Unit])(())
foo(new Forall[({ type X[A] = A => A })#X] { def apply[A] = identity })

もうちょっと短く書けた
import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id[Unit])(())
foo(Forall[({ type X[A] = A => A })#X](_(identity)))

>>372
ありがと いくつかのブログ漁ってみるよ。

ファイル出力の標準的な方法ってありますか？
ファイル入力のSource.fromFileに対応するようなものです。

今はFileOutputStream〜PrintWriterといったJavaのAPIを使ってますが正直面倒です。

jajava.nioで

(Int)=>Intのような関数を引数に取るAPIを、Javaから呼ぶにはどうやって引数を渡せばよいの？
自力でFunction2にラップする？
そういうユーティリティが既にある？

>>386
scala.Function1をimportして
new Function1<Integer,Integer>() { public Integer apply(Integer i) {...}}
とすればよいのではないか。

>>386
ScalaのtraitはJavaのinterfaceになるから、具体メソッドはすべてつぶされてしまう(ヒドス)。
Function1はtraitなのでJavaから便利に使うためにabstract classにする。

==========scala============
abstract class Fun[-A,+B] extends Function1[A,B] {
override def andThen[T](g: (B) => T): (A) => T = this.andThen(g)
override def compose[T](g: (T) => A): (T) => B = this.compose(g)
override def toString(): String = this.toString()
}

==========java=============
import scala.Function1;
import scala.Some;

public class Main {
public static void main(String[] _args) {
Fun<Integer,Integer> f = new Fun<Integer,Integer>() {
@Override
public Integer apply(Integer n) {
return n+1;
}
};
System.out.println(new Some(3).map(f));
}
}

>>387,388,389

さんきゅー！
基本は388&389の方針に従った。

scala側は

abstract class Func1[-A,+B] extends Function1[A,B]

で十分みたい。
andThen,compose,toStringは勝手に生成されたよ。

実装のあるtraitをabstract classでextendsしたら
その実装を引き継ぐコードが自動生成されるみたいだね。

(Int)=>Intの関数は、JavaではFunction1<Object,Object>に
見えるらしく、Java側はこんなコードになったけど、
まあ、我慢できる範囲かな。andThenもこのまま使えたよ！

|　Func1<Object,Object> f = new Func1<Object,Object>() {
|　　@Override public Object apply(Object v) {
|　　　return (Integer)v + 1;
|　　}
|　};

ありがと！

play2.0ってeclipsify出来ないの？

上でファイル出力の質問があったけど、実際みんなJavaのAPIでやってます？
Sourceはなぜこんな非対称な仕様なんだろう…

俺はOutputStreamへの書き込みは次のようなusing関数を使うのがよいと思うのだが
どうだろう？
| def using[T](out : OutputStream)(f : Outputstream => T) : T = {
| try {
| val r = f(out)
| out.close()
| r
| } catch {
| e => out.close(); throw e
| }
| }

def usingFile[T](fileName : String) = using[T](new FileOutputStream(filename))

使い方
usingFile("foo.txt") {
　out =>
　　val w = new PrintWriter(out)
　　w.println("firstLine")
　　w.println("secondLine")
}

>>395
out => ってどこから使えるようになったの？

>>396
仮引数だよ。

list.map { a => a+1 }

の　a と一緒。

PrintWriterもusingFileで作ってしまったら？

か、か、かりひきすう？
それなに？まだよくわからん

引数と違うの？

>>399

仮引数ってのは正確な物言いじゃあないかもしらんが、Java でも何でも一般的な概念でしょう。

仮引数に束縛…とか、アリティが…とか、正直実用だけを考えるなら、用語を知る必要もない。
つか仮引数とかって基本情報とかに出てきたような過去の記憶が。

>>396
関数を引数として渡すときに #Scala ではしばしば {}で囲って表現する。
someArray.foreach(x => save(x); println(x)) って書くよりも
someArray.foreach {
　x =>
　　save(x)
　　println(x)
}
って書いた方がDSLぽくてカッコいいでしょ。

>>388

> Function1はtraitなのでJavaから便利に使うためにabstract classにする。
>
> ==========scala============
> abstract class Fun[-A,+B] extends Function1[A,B] {

その目的のためには、scala.runtime.AbstractFunction1が既に標準で用意されている也。

>>396

気になってるのは out が前触れなしに出てきたからでしょ。
これってたとえば 「def add1(a: Int) = a + 1」 の add の直後に出てくる a つまり仮引数と一緒なんですよ。

で、もう最初に気になったあたりを見直すと、

def using[T](out : OutputStream)(f : Outputstream => T)

ってなってて、結果的に usingFile の 2 つめの引数の型は「Outputstream => T」になる。
これは「Outputstream を一つ引数にとり T を返す関数」を要求してることになるから、

(out: Outputstream) => hogehoge....

と書くところを

out => hogehoge...

と書けるわけ。

>>404

def using[T](out : OutputStream)(f : Outputstream => T)
って表記されればわかった。

REPLってなんで定義した関数の型とか引数の情報も
詳しく出してくれないのですか？F#ならでるのですが

>>405
え、嘘、出るだろ！？と思ってやってみたら出たけど、
どういう時に出ないの？

今更かもしれませんが、これってどう思いますか？

SIP-12 - Uncluttering Scala's syntax for control structures.
http://docs.scala-lang.org/sips/pending/uncluttering-control.html
(なぜか過去のコメントが見られなくなってしまったようです)

個人的には、利点があまり感じられない上に、
ユーザ定義の制御構造との統一感が無くなるので、
賛成できないのですが。

forのカッコは鬱陶しいと思ってたので歓迎
他はどっちでもいいかな

>>407
#Scala がますます #Haskell や #OCaml みたいになるな。
しかしあまりJavaと離してしまうと、Javaユーザーが導入しづらくなり、
ポストJavaの立場がやばくなるのでは。scalaユーザが増えてほしい俺としては
ちょっと反対。

>>409
その#は何？

Twitterのつもりなのでは。

>>409
個人的には、もっと早いタイミングで導入するのならアリだった。
シンタックスがよりJavaっぽくなくなってしまうことはそれほど問題じゃないと思う。
ただ、2.10のタイミングで、こういう、言語の表現力を上げるわけでもない「些細な」
構文的変更入れてしまうのは、反対というか遅すぎるな。

まだSIPの段階なんで入ると決まったわけじゃない。提案者が
Odersky先生ではあるけれど、まだpendingだし、MLで反対票が
多ければ入らない可能性も十分ある(2.8のときに、Seq -> Sequence
の名前変更が、反対が多くて断念したという実例とか)。

今は当時よりもScalaを実用で使ってるユーザが増えてるので、幅広く
意見集めれば反対票も出てくるのでは、と思う。

>>412
Javaユーザが敬遠してしまう要因を増やすことになると思うがそれはよい？
JavaユーザがScalaへ移行することは重要ではないと言っている？

>>413
最初の問いについては、元々Scalaの構文はJava互換でないので、>>407くらいの
変更が入ったところで、敬遠する要因が増えるかというとそんなに変わらないのでは、というのが自分の考え。

ただ、「2.10のタイミングで」これを入れるのは、Scalaへの移行を検討しているJavaユーザを遠ざける
要因になり得るので、反対(既存の構文がすぐに使えなくなるわけではないにせよ、
しばらく、旧構文と新構文を使ったコードの両方が出てきて、無用な混乱を招きそう)。

二つ目の問いについては、重要だと思っている。だからこそ、SIP 12に対しては反対。
なら行動起こせよ、と言われそうなので、説得力のある反論をまとめて、>>407のページに
コメントする事は検討中。

>>413
お前も然るべきところで意見できるように精進しろよ＾ｗ＾

>>415 はい。勉強させていただきます。先生。

しかしifにかっこがいるというのは最初の頃はしょっちゅう間違えたところなので、
できれば導入して欲しいな。
せっかく一引数関数のかっこを不要にしてるんだから。

構文まで変えるなら2.10じゃなくて3.0にすればいいのでは

省略できるもんはなんでも省略しようぜｗｗ
Javaなんて忘れて新しい秩序をつくるんだ

Scalaが話題にのぼるようになってから、もう何年経つと思ってるんだ
未だにJavaで満足してる奴はもう切り捨て！いらね！
というわけで「Javaっぽさ」という視点はもうScalaには不要

>>419
カッコは必ず書く派としては賛同できんな。
言語仕様として「できる」ようにする事には必ずしも反対ではないが、原則は書くべき。

設定した通りにカッコとかを付けたり付けなかったりしてくれるコード整形ツールがあればいいと僕は思います！

よく分からんが、

現在の
if (expression) expression else expression
という構文は廃止して
if expression then expression [else expression]
という構文になるってことか。


ただ、expression の外側に "( )" をつけてもそれはexpression だから、

if ( expression ) then expression [else expression]

はOKなんだよね？
つまり、then 必須になるってこと？

これまでかっこが果たしていたセパレータとしての役割をthenが果たすようになるってこと

Javaで書いていたswingの部品（たとえばJPanel）を
scala.swingのフレームに張り付けるなんてことは可能でしょうか？

scala.swingは薄いラッパーといわれているので、Javaとまぜて使えないかと期待してます。

>>425
できるよー。scala.swingのコンポーネントには、peerというメソッドがあって、対応するSwingの
コンポーネントを取り出すことができる。

val panel : scala.swing.Panel = ...
val peer = panel.peer

みたいな感じで

>>426
横からだけど便利だな〜
objectにしておいてくれたほうが良かった気がするけど。
何か理由があるのかな？

>>426
ありがとうございます。

私のやりたかったこととは逆（scalaで書いていた部品をJavaに取り込む方法ですよね？）
ですが、便利そうです。

なお私のやりたかったことはwrapでできるということがわかりました。

http://www.eclipse.org/Xtext/xtend/
もうScala不要じゃね？

関数型としてじゃなくてBeyond javaとしては、そっちの方が筋いいかも

genericsの型制約のシンタックスが好きじゃない
? extends とか読めない
Scalaのほうが良いと思う

Scala終わったなぁ

http://lambda-the-ultimate.org/node/4396
これぐらいしかnewsがないな。

xtext2.1リリースで、xtendもバージョンアップしたのかな？
http://www.infoq.com/jp/news/2011/06/xtext-20

バイトコードじゃなくて、Javaコードを吐くというのが特徴？

このクロージャの構文、リスト内包表記に喧嘩売ってる気が

val predicate = [ Person person | "Hans" == person.name ]

どっちかというとSmalltalkのパクりじゃね？

公式の右下に開発環境は何よ？ってミニアンケートがあるね。
もちろん皆 vimだよな？！

IDEA1択

sbtがあるから普通のテキストエディタでも問題ないね

>>429

JetBrainsのKotlin といい、 ほとんど同じような言語開発する暇あったら、
Scala を手伝ってやれよ、って思ってしまう。

言語ばっかり乱立しても、共倒れするだろうに。

xtendは、xtextのサンプルでもあるから、
JVM上のbetter javaのCeylonやKotlinとはちょっと意味合いが違うと思う。

たしかにいくつ作るんだよとは思うが。
Javaのシンタックスシュガーに徹するんならJSRにのせたりしないのかね。

別にいくら作ってもいいんだが、なぜみんなScalaとJavaの中間を目指すんだろう
仕様は日和っているわりに、これから実装しますとか実用性もない状態で、誰が使おうと思うのだろう

えっ、気分でしょ？

>>443
Scalaより単純で実用的と言ってるんだから、使える標準ライブラリとひとまとめにしてさっさと公開すればよいのにね
結局、現時点でScalaの方が基本インフラ整ってる分実用性が高いとか皮肉すぎる

>>443
発想が「ぼくのかんがえた さいきょうの Better Java」だから、だろうねぇ。

xtext,xbase,xtend 2.1 リリース
http://www.infoq.com/jp/news/2011/11/xtext21
scalaこれで実装したら遅くなるんだろうな

Oderskyはバリバリ実装する人であると同時に優秀な理論屋なので、Scalaの仕様は
理想と現実の妥協点がよく考えられてるんだけど、後発のおいしい所取り狙ってる言語は、
なんかよくわからずにテキトーにScalaの一部分持ってきてるだけに見えるんだな

最近更新されてないんだな。
あんまり学会発表しなくなった？
http://www.scala-lang.org/node/143

http://ppl.stanford.edu/wiki/index.php/Publications
もしかして、こっちで少し指導してる？
並列とDSLだね。（C++テンプレート使った奴が何年か前かなり流行ってた。最近はHaskellとかも）

#xtend って結局Javaと #Scala の中間的言語だから Java->Scalaの道が
よりなだらかになったと考えるべきじゃね。だから Scalarはむしろ
xtendを大歓迎すべきだと思う。そしてxtendに新しい機能が追加される
度に「あーそれ2年前にやったわー」と言っておけばよい。
問題はむしろJavaがいつまでも使われ続けること。

JVMで動く言語、に限らずだけど、スクリプト系の言語みたいに一ファイルだけデプロイして置き換えるだけでOKって出来ないのが辛い

>>452 まともなスクリプト言語開発者なら、デプロイする前に
単体テストしたりコミットしたりするだろ？それを考えると
そこまで大差ないと思うんだが。

s/スクリプト言語開発者/スクリプト言語を使う開発者/

xtendがあればScalaが不要になるんだよね？

gitからhotデプロイ出来る仕組みにしてみるとか？

JRebelのscala lisenceのページが消えて、購入ページに飛びますな
http://sales.zeroturnaround.com/
変わりに非商用プロジェクト向けのJRebel Socialなるものが
https://social.jrebel.com/
そして、facebookかtwitterでログインしろとか

テキストファイルの内容を丸ごと文字列に変換するライブラリ関数はありませんか？
今は，scala.io.Source.fromFile(file).getLinesで一行ずつ読みながらつなげていってますが、
どうも馬鹿げているので。

mkString使え

最近、whileで書いていたところは、大体Stream.iterateに置換できることを発見して、うひょーと思ったが
前スレを見たら余裕で紹介されてた

Stream.iterateめちゃくちゃ遅い
forはwhileでガチガチに最適化するのがいい

Javaのソースファイルが生成されるってのは予想以上に便利だな
ものすごく親和性が高い気がする

http://twitter.com/#!/Isuzu_T/status/137495976599486465

株式会社ドワンゴでも使っているみたいね。
http://live.nicovideo.jp/watch/lv71111927
ドワンゴ研究開発チャンネル

非公開設定してるユーザーのツイート貼ってんじゃねえぞボケナス

http://scan.netsecurity.ne.jp/article/img/2011/11/13/27625/93.html
tokuhirom、ma.la？っていう人の話だけ聞きたい
色々なスレで見かけるけどWEB業界で有名らしいね
動画ありませんか？

貼られたときは公開してたよ

>>464
なにこれ面白そうじゃん
タイムシフト予約したわ
あまり初心者向けにならないでほしい

>>464
面白そうだな
ドワンゴのレベルを見させてもらおう

会場がドワンゴなだけじゃないの

発表スキルの落差がすさまじいな

そら社内リソース+αだけじゃ裾野が狭すぎ。

俺も度湾後入りたくなったわw
内容は初心者向けに平易なものにしてくれてたのかな

これ平易じゃなかっただろｗ

そうかな？

javaのComparableインタフェースを実装したクラスC

public class C implements Comparable { ... }

のサブクラスをscalaで定義したいのですが、ここにある問題にぶつかってしまいました。
http://scala-programming-language.1934581.n4.nabble.com/extend-from-a-Java-class-interface-implementing-Comparable-without-type-parameters-in-2-8-0-x-td2258995.html

class D extends C {
def compareTo(other:AnyRef) : Int = 0
}

とやっても
class D needs to be abstract, since method compareTo in trait Comparable of type (x$1: T)Int
is not defined (Note that T does not match AnyRef)

というエラーになります。
なにか回避策はないでしょうか？

ちなみにクラスCの実装はJavaのライブラリ内にあって修正はできない状態です。
できればscala側で何とかしたいのですが…

Java側でcompareToをoverrideしないと無理かもしれぬ

これ何でエラーが出てるの
型が違うのか
anyrefとobjectで

>> 476

"Note that T does not match AnyRef"

っていうメッセージのとおり、compareToの引数の型がAnyRefではだめってだけじゃないの？

リンク先のメーリングリストの議論は、2.8のRCのときだからたまたまbugってたというだけで、関係なさそうだけれど

ここを見ると、scala単体での回避は無理そうだね。

http://stackoverflow.com/questions/3329001/scala-class-cant-override-compare-method-from-java-interface-which-extends-java

ドワンゴ入ればScalaやらせてもらえるらしい

Scala書ける人を雇ってphpを書かせる
怖いお

絶対Scalaなんてやってないだろ
そもそも人気高くて入れなさそうだけど

今年新卒60人採用でしょ
景気のいい話さ

しかしあそこに集まってた連中は流石に濃いメンツだったな
本当にニコニコかという感じだったw

あぁいつものメンバーかって感じがしたわ

ひろゆきもちょっと来てたらしいね。
さすが技術には力を入れているっていう感じだった。

なにその胡散臭すぎる話

いつものメンバーは一人病欠だろｗ

>>490
病欠ですいませんorz

今回のは、ニコ動本部の配信だけど、

草の根的なScala勉強会も、地方にストリーミングしてほしいなあ。

渋谷のやつなら大体Ustしてるんじゃね

http://www.scala-users.org/shibuya/index.php
これって毎週やってんでしょ？ネタなくならないの？
たまに録画みるけどすごいぐだぽよ〜な感じだよね

今思うとscala東北の配信は最高に濃かったよな

>>495
@ymnk さんというスーパーハカーの力あってのものでしたね…
あのクオリティを毎週維持できてたのはほんと凄いとしかいいようが無いです
震災の影響で休止になったままなのが残念

コテつけろやエバンジェ！

了解です。最近スレをあまり覗かなくなったのと、マシン環境変えたのでトリップ付けるの失念してました
いやまあ、たぶん発言の仕方でバレてる気もしますが。

>>498
ついでに>476にも愛の手を

>>499
ちょっとでかけるので、手短に言うと、>>476の問題はJava側でワークアラウンド用のJavaコード書くしかないです。
これは、ジェネリックなクラス/インタフェースの型パラメータ無し(raw type)をスーパータイプとして
Java側で継承したときに起きる、ややレアな問題で、当面は対処されないと思います。

ttp://d.hatena.ne.jp/karasuyamatengu/20111122/1321978693
早速ヒロちゃんが来てる。このブログ主は訳してるだけだから・・・そっとしておいたげて。

そこの元記事：
http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html
すでに、炎上してて、読む気が起こらん。FUD連呼厨をみてどこも同じだな。
とは思った。

>476みたいなJavaとの相互運用上の落とし穴をまとめた資料ってどっかにないのかな

>500

ありがとうございます。
Javaで接続用のクラスを作ることにします。

eclipseだとscalaとJavaを同一プロジェクトに共存させられないのが
こういうとき面倒ですね。

>>501
そこのコメント欄、読みづらすぎｗ

でもJodaTimeは俺も使ってるからショックだなあ
実はScalaTimeのしょぼラッピングぶりとか見て切れてたりして

>>504
eclipseでScalaとJavaを同一プロジェクトに共存させることはできます(というかそれをするために、JDTがまともな拡張ポイントを提供してくれてない
せいで、ScalaのEclipseプラグインはかなり苦労してます)。単に、Javaパッケージ下に.scalaファイル置けばそれでOKです。

>>501
さすがに、ブログ主がその主張をしてるとは思ってません。日本語だけ見る人が訳のまとめ見て誤解したら
嫌だなあ、と思ってつい長文コメント書いてしまいました。ただ、そのブログ主にとっては迷惑だったかもしれませんし、今は反省してます…

>>506
自分も、JodaTimeは良い設計してると思うだけに、その作者がこんなに残念な(感情的な)書き散らしをするのだなあ、というのはちょっとショックでした。

>>507は自分です(見ればわかるかとは思いますが)

向こうは、営利的な部分でも感情的に振る舞う、ポジショントークは多い気はする（経営者っぽい？）
そして人間関係は別だったりする。
日本の技術者は、普段は公平性を重んじるから、会社の立場はあまり気にしないんだけど。
本当に好き嫌いでポジショントークしたり、論理的に装ったりする場合も多いから、イマイチ立場が判りづらい。

この場合、scalaをこき下ろす営利ってなんだろうか？利害はなさそうに思うけどな。
ただ、感情的なものがあるとしたらコミュニティへの不信感はあらわにしてると思う。

仕様が複雑なものに柔軟性を加え用とすると、さらに仕様が複雑になって手に負えな
くなるというパターンは普通にあることだし、言ってることもわからないことではな
いかな。複雑にすればするほど、直交性も崩れやすいのも当然だしね。だから、
感情的なところと理性的な部分を含んだ内容と理解してるね。

彼の場合、正直、Scala(コミュニティ？)嫌いが先にありきでそのために理由を作り出しているようにしか見えないのが問題
つーのは、彼の挙げてる例とかコメント見る限りで、Scalaをほとんど使った事が無い事がわかるので。 状況証拠は大体揃ってて

(1) ++ が java.util.List#addAll() と同じだという初歩的な勘違い
Scalaを使ってプログラムしたことがあれば、この程度の勘違いをするはずが無い
(++ は immutable collectionの連結で、 java.util.List#addAll()は、mutable listへの要素の追加)

(2) List(1, "foo") の結果型が List[Any] でコンパイルエラーにならないのが問題だと言っている
コンパイルエラーが検出されるタイミングがずれるという意味では全く問題ではないとは言わないけど、
少なくとも安全性の面で問題は無い(mutable listに要素を追加するのと勘違いしているのだろうと推測)

(3) Scalaのフレキシブルな構文のせいでコンパイラが遅いと言っている
本当の理由は、implicit searchのコスト + コンパイラのパス数の多さ
彼は、パージングにかかる時間が一般にコンパイル時間の多くを占めていないということすら知らない

(4) Scalaが言語レベルでimmutablityを強制できていない(ので、並行プログラミングで問題だ)という事をことさら問題視している
実際には、たとえばActorでmutable objectをわざわざ渡す奴は居ないし、海外Scala MLでもその手のトラブルは聞いたことが無い

(5) 空想のScalaコミュニティに対して反発している
型理論とかを知らない奴をけなしている、などと言っているが、実際にはそのような人物はコミュニティではほとんど居ない。
むしろ、そういう質問があったら、積極的に答えようとする人が多い(多すぎるくらい)。つまり、実際のScalaコミュニティ(特に公式
MLなどでの経験があったわけではないのは、ほとんど確実)

(6) Scalaを使用した経験から批判してるのか、そうでないのか、どっち？という質問を全スルー。

他にも色々あるのだけど、この辺で。要はScalaをまるで知らないのに、一知半解どころか一知すら無い状態でこきおろしてる、ってのが一連の
ポストとコメントでわかったのが収穫かな。で、誠実な部分含めて、都合の悪い指摘全スルーしてる辺り、確信的にやってる(FUD)とやはり俺は思う

もちろん、Scalaには色々な問題があると俺は思う。

・実用的には重要な標準IOライブラリが中途半端なscala.ioしかない
・sbtという重要な基盤ツールの進化が速過ぎて、ドキュメントが追いついていない
・標準ライブラリのscaladocのドキュメンテーションコメントが少ない
・これは、コミュニティ内部でも問題視されてて、その結果、 http://docs.scala-lang.org/ が出来たわけだが。
・コンパイル遅い(sbtでだいぶ緩和される & 改善に向けて内部的にも色々進行中だけど)
・バージョン間バイナリ非互換性の問題(Typesafeが、この問題を解決するツールを開発してるみたいだが)

IDEはかなり良くなってきた(特にIntelliJは良い)ので、そっちの方の不満は少なくなってきたけど、もっと周辺ライブラリとの強調とか
標準IOライブラリへの取り組み(Scala-IOの支援とか)とかを積極的にやって欲しいな、という印象。言語自体は、もうちょい型推論
強化してくれたらな、というくらいで、不満はそれほど多く無いかな。

sbtもclojureのleiningenほど使えるようになればいいのにね。

マイナー言語が人気出てくると、貶すためだけの書き込みが
一時的に増えるのは、お局様が新人に切れるのと似てるな。

FUDはなぁ。 http://ja.wikipedia.org/wiki/FUD
言語のことで、毛嫌いされてるといえば、lisperという立場から見ると
さんざんいろんな誤解を書き散らされてるけど、率直にいって、しゃーないなー
スルー。って感じが多いよ。中には、誤解に対して丁寧に答えてる人も
いるけど、よくあることさ。あんまり、FUDと捉えないほうがいいよ。
どんな話があっても流れてくる人はいるもんだ。

そうそう、楽する方法を一つ。適当なよくある質問を集めて、FAQを
作ってみたら？あるんだったら、そこに新たな質問と答を逐次追加し
ていけばいいしね。いつも丁寧に答えてたら、時間がいくらあっても
大変だろうし、水嶋さんは見る限り周囲の空気にはやや鈍感なのかも
しれないけど、聡明な方みたいだしね。その行動力はすごいと思って
見てるよ。でも、この性質は時々頭のよい人に見られるものだからな。
それを、より建設的な方向に利用すればいいってことだと思う。あなた
位ならば、すでに、どこがよく誤解されやすくって、その誤解をどう
説明するかは察しがついてると思うんだよね。

FAQもどんな形式が読み手が楽かとなると１問１答１ページ＋目次のほ
うが余裕があるかも。

FAQを作って、いろんな誤解があるものをまた良くわからんとって批判しとる
と見てたらいいし、乗り込んで丁寧に答えるような労力もつかわなくても
よくできると思うよ。
いちいち論戦したり答えたりするより、言語を使ってこんなこともあんなことも
そんなこともできるって示していったほうが、腕利きさんのセンスを持った
人を獲得しやすいんじゃないかなと思うよ。
長くなったけど、ほな頑張ってね〜

>>515
なるほど。少なくとも、FUDというワードを使うのは議論をややこしくする可能性が高いので、避けるべきかもしれない。
ただ、今回の場合は色々反論があった(自分は何もしていないというかコメント欄で馬脚を現しただけだが)おかげで、
彼の批判が実経験に基づかない空想上のものである事が明らかになったわけで、まあ反論することにも意義は
あるかなと。自分の質問へのレスポンス
http://blog.joda.org/2011/11/scala-ejb-2-feedback.html?showComment=1322218727885#c5182138328634130006
で、結局、彼は「俺はScalaの経験はほとんど無いが、Scalaが駄目だって事を判断できる(キリッ」とか言ってるだけの人
だって事が確定したので、もう怒る気持ちすら失せて呆れてる段階だけど。

>>516
ちょっと今回は色々大人げ無くて、みっとも無かったかもしれませんが、丁寧なアドバイスありがとうございます。
よくある誤解に関するFAQについては、仰る通りそろそろ用意すべきときかもしれませんね。
また、FAQの形式に関しても、1問１答１ページ＋目次という構成は良さそうですね。その辺り含めて、
ちょっと検討してみます。

ちなみに、おっしゃる通り、自分はかなり空気が読めない方です(という自覚はあります)。聡明かどうかは自分では
どうにも判断できないですが。で、自分が聡明かはともかく、これまでのTwitterでのbot活動wによって、大量の疑問点に
対するリプライの蓄積があるので(twilogで読めます)、ある程度誤解やハマりパターンの傾向は把握している感じです。

>>517
応援ありがとうございます。確かに、誤解 or 曲解に対して、乗り込んで論戦するとかは結構労力使う
割に得るものが少ないという意味で、費用対効果が悪いですね。>>516さんのリプライでも書きましたが、
FAQをちょっとずつ書き溜めていきます。あとは、本家Scalaコミュニティに対してもっと貢献していきたい
ですね。今年になってからあまりバグレポートもできていないので。

文章の長いコテハンって痛いの法則

日本のScalaコミュニティが怖くて粘着質でウザイのは
まぎれも無い事実

このスレでは、519,520 みたいなウザイの短文野郎が現れるけど、ゴミだね。
なんで、わざわざScalaのスレにきて、粘着するんだろうね？彼は。


>516とか>517
は自分も同意です。

>誤解 or 曲解に対して、乗り込んで論戦するとかは結構労力使う
>割に得るものが少ないという意味で、費用対効果が悪いですね。

見る側にとっても、この手の議論に飽きてきたところ。
章立てとかいらないから、どっかにFAQでまとめといて、って感じ。


そんなことより、Scalaの事例を増やしたいなあ。
最近だと、C#とかは Kinectやりたいって理由だけで C#人口増えている。
Scalaもそういうキラーアプリがないかなあ。

他、日常業務スクリプト集 とかあったらうれしい。本でたら買う。

Scalaスレにウザくて粘着質な奴が張り付いているのは
まぎれも無い事実

>>521
対抗してQUMA用API充実させるとか？

Scalaの.net実装？が復活するって前に聞いた記憶があるかど今どうなってるのかしら？

>>521
第二回Scala会議で、その辺りについてちょっと発表できるかもです＞FAQでまとめ

Scala事例に関しては、国内だと細々とした利用は増えてるのですが、キラーアプリ
というのはまだ不在ですね。Play 2.0がTypesafe Stackのインストーラに統合される予定
なので、今までよりWebアプリをScalaで作りやすくはなるかもしれません。

>>524
.net実装自体はexperimentalですが既に動かせます。
http://lamp.epfl.ch/~magarcia/ScalaNET/2011Q2/PreviewScalaNET.pdf
にやり方が書いてあるので、参考までに。ちなみに、昔のScalaの.NET実装と違い、
今回復活したのはIKVMのランタイムを利用したものになっているため、手順が違うことに注意してください。

あああ、引数の型とか再帰の返り値型を書かなきゃならんとはめんどくせえ！
なんで他の言語と同じように推測してくれないんだよ！

誰か、俺があきらめがつくように、型推定できない最小の反例を見せてくれ！

引数と返値の2パターンでよろしく。あとゴルフでな。

def f(x,y) = x + y

とか

>>527
そうそう、その問題も。
なんで他の関数型ではできるそれが、Scalaでは許されないようにデザインされたのか？も知りたい。

>>526-528

まず、Scalaでは許されないようにデザインされた、というのは順序が逆、ということを念頭においてください。
ScalaはJavaの型システムをリファクタリングした上で拡張するという既定路線があって、その制約の元で
どこまで型推論できるのか、というのが問題になるわけです。

さて、

def f(x,y) = x + y
相当の関数が、何故ML系の言語では完全に推論できるのに、Scalaでは無理かというと、まず、"+"演算子の意味するところが
違うからです。たとえば、OCamlなら (+) の型は int -> int -> int なので、そこから x が Int, y がIntである事を容易に
推定することが(人力でも)できます。

一方で、Scalaでは、
def f(x,y) = x + y
における + は 式 x をレシーバとしたメソッド呼び出し (引数はy) になります。この時点でまず、+の型が不明である事に注意して
ください。この時点で、fは多相関数として推論しなければいけません(たとえば、Int同士の+だとみなすと、他の型に適用できなくなる)。
さて、この定義のx, yおよび x + y にどのような型を割り当てるべきでしょうか？
ひとつの方法として、

def f[T <: { def +(other: T): T }](x: T, y: T) = x + y

という方向が考えられます。しかし、以下のように別の推論を行うことも可能です。

def f[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y

さて、このどちら(他の推論候補もありますが、とりあえず2種類で考えて見ます)。少し考えればわかるのですが、
これはどちらが正解である(より一般的な型を推論している)とも言うことができません。MLのHM型システムの
元では、一切の型注釈無しに、完全かつ健全に、関数の「もっとも一般的な型」を推論できる事が保証されて
いますが、Scalaの型システム上では、それは「原理的に」無理なようになっています。この辺りはScalaが
サブタイピングを持っている事などと関係があるのですが、その辺りは長くなるのでこの辺りで。

捕捉ですが、説明の都合上、
def f[T <: { def +(other: T): T }](x: T, y: T) = x + y
というScalaの関数を定義してみましたが、現在のScalaのstructural typeの実装制約上、これはコンパイルを通りません。
通りませんが、この制約が緩められて、上のように書けたとしても、Scalaの型システム上での型推論は単純なものですら
かなり難しくなりえます。

>>507
> eclipseでScalaとJavaを同一プロジェクトに共存させることはできます(というかそれをするために、JDTがまともな拡張ポイントを提供してくれてない
> せいで、ScalaのEclipseプラグインはかなり苦労してます)。単に、Javaパッケージ下に.scalaファイル置けばそれでOKです。

これ、scalaプロジェクトの下にJavaパッケージ作って、その下にJavaクラスを置いたのでは駄目なんだね。
scalaソースからJavaパッケージのJavaクラスを参照しても見つけてくれない。

>>531
うーん。こちらの環境では、その方法で普通に使えましたけど…。ひょっとして、JavaエディタからScalaオブジェクトのメソッド
補完などが効きにくい事を仰っている？

>>532
いや、コンパイルエラー（エディタ上でエラーマーカーがつく）になります。
きっと微妙な落とし穴があるのでしょう。
scalaプラグインの完成度は余り高くないので。

>> 529,530
ありがと！

>> 529
前者のfと後者のfを比べると、「より一般的な型を推論している」という
意味では、明らかに後者の方がより一般的だけど？
それとも「一般的な型」の意味に齟齬がある？
日本語だと曖昧になるなら英語でも大丈夫すよ。

さらに、一般的な型という意味なら、こちらの方が。

def f[T <: { def +[U,V](other: U): V }](x: T, y: U) = x + y

これでFAでいいじゃん。
でも、Scalaはこれは許されないし、
許さないようにしているのは理由があるんだよね？それが知りたい。

>> 530
> Scalaの型システム上での型推論は単純なものですらかなり難しくなりえます。

そりゃ、探索空間が増えるから、比較すると難しいのは自明だけど、
「かなり」って主観的だし、もう一声！

実際のところ、どれくらい難しいの？

(a) 一般的なコーディングでも推論不可能なケースが多い
(b) 一般的なコーディングでは推論不可能なケースはまれだが存在する
(c) すべての推論可能だけどコンパイラ性能的に計算量が実用的でない
(d) すべての推論可能だけどコンパイルが実用範囲内で遅くなる
(e) すべての推論可能でコンパイル時間も問題無し

>>534
おそらく、「より一般的な型を推論している」という言葉の使い方に齟齬があるかと思います
ここで、自分が「より一般的である」といっているのはメソッドシグニチャの包含関係がある
かどうかをさしています。

たとえば、次のfの推論と

(1) def f1(x: Int, y: Int): Int = x + y

以下の多相的なfの推論を比較したとき、

(2) def f2[T <: { def +(other: T): T }](x: T, y: T): X = x + y

(2)は(1)に比べて、「より一般的な型」を推論しているといえます。これは、
全ての式 x: X, y: Y について、f1(x, y) が型チェックを通るならば、f2(x, y) も型チェックを通るからです。
さて、次に

(3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y

と(2)を同様に比較してみます。結論から言うと、(2)では型チェックを通るが、(3)では
型チェックを通らない例が存在します。たとえば、x: Int, y: Intのとき、

f2(x, y) は 型チェックを通りますが、 f3(x, y) は型チェックを通りません。この理由は、必要であれば別のレスで述べますが、
ともあれそのような意味で、(3)は(2)より「一般的ではない」という事ができます。ここで、HM型システム
の元では、型付け可能な関数について、かならず「もっとも一般的な型」(principal typeと呼ばれます)
を推論することができる事が保証されており、推論結果の「正しさ」が保証されます。しかし、Scalaの
型システムではprincipal typeが存在しないので、そのような保証がありません。

>>535
> 実際のところ、どれくらい難しいの？
前提として、推論が可能かと言えば「可能」です(推論結果の正しさや実用性を問わなければ)。
しかし、仰っているのは、そのような型推論システムでは無いでしょうから、それを前提
として答えると、答えは (a) になります。実際のところ、もうちょっと答えは複雑で、principal type
は推論できないけど、「大体のケースで正しくなりそうな」型推論を多くのケースで行えるアルゴリズムを
Scala上の型システムに構築できる可能性はあります。しかし、仮にできたとしても、それは理論上の
保証が無い(少なくとも簡単に保証できない)ので、HM型システムの型推論のような「安心感」を得ることは
できないでしょう。

>>535
> 必要であれば別のレスで述べますが、

ぷりーず。そこが議論の本質な気がする。

あと、(2)と(3)はそれで正しい？

>>537
おーけーです。これから述べます。の前に
> あと、(2)と(3)はそれで正しい？
はい。それで正しいです(少なくともScalaにおいて) 。

さて、その理由が議論の本質、ということなので以下に理由を述べます。先ほどは、
> (3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y
に対して、f3(100, 200) のような式が型チェックを通らないということを書きました。
ここで、問題になるのは、Intの+のシグニチャが(オーバーロードバージョンを無視したとして)、
(Int)Int
であるのに対して、(3)で、structural typeによって要求されているシグニチャは
[U >: T](U)U
であることです(ちなみに、これはScalaにおける「メソッド型」の表記法です)。この二つの
メソッドシグニチャ(というより、非ジェネリックメソッドとジェネリックメソッド一般に)には
互換性が無いので、型チェックを通りません。一方、(2)の場合、structural typeによって要求されるシグニチャは
(T)T
になります。ポイントは、(2)の場合、「+そのもの」は多相メソッドではないので、T = Intとしてインスタンス化されている
場合、
(Int)Int
になり、(1)のケースを包含することです。長くなりましたが、一言で理由を述べるなら、「非多相メソッド」と「多相メソッド」の
シグニチャの間には互換性が成立しない、ということが根本的な問題です。

>>531
ナイトリービルドやRCを使ってるから違うかも。
それからプロジェクトのクリーンで再ビルドすると見えるようになることもある。

>>518
ttp://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/script-lang
読んでみたらいいよ。

>>540
もくじ付けて

Scalaは新しいEJB 2か
http://www.infoq.com/jp/news/2011/11/scala-ejb2

静的型付け言語全体の評価を下げているって部分は論理がよく分からんな。
他はまぁうん、問題提起としてはいいんじゃないかというのが初心者の俺の感想。

>>543
関数型言語として一番最初にscalaに遭遇すると、型宣言の仰々しさを
一番感じて、敬遠するだろう。これが型システムの複雑さなんだが、
適当な例は少し上の水嶋さんのコメントからも分かるだろう。
この複雑さが初めての人にとって静的型付け関数言語ってと頭の中で
一般化してしまうことがある。（どれだけかわからない。）→静的型
付け関数型はとても複雑で、頭のいい人しかわからない。使えない。
→他人との話題でそんな話になる。→静的型付け関数型の評判が落ち
る。という流れになることを指してる＜その論理。
関数型を学習するのにscalaからはいるのは不適当だとは思うが、ここ
の人の多くは異論を持つだろう。
scalaの作者ってむかしpizzaって言語を作ってたんだね？Haskellの
本を読んで知った。

いや、ScalaをやるならまずJavaとHaskellをマスターしてから来いと再三言ってるが、実践してる人は少ないだろう

自分はまずSchemeから入ってOCaml→Haskell・Scalaと流れたから、割とすんなり関数型を理解できたなあ。
強い静的な関数型の入門はOCamlがいいんではなかろうか。
ちなみにJavaは全くできない。

>>545
そんなこと言ってるから複雑だとかコミュニティがとかになるんだろ

だからScalaはオブジェクト指向と関数型を掛け合わせたくらいの複雑さはあるし、
関数型を学ぶなら専用の関数型言語で学んだほうがいいって言ってるだけなんだけどな
Scalaの標準ライブラリのソースは関数型っぽく書かれてないしね

Scalaは新しいEJB 2か
http://www.infoq.com/jp/news/2011/11/scala-ejb2

しつこい

ここは天丼に行くべきか？

549

また、いつもの粘着野郎かな？

言語の比較の話はもう飽きた。


そんなことより、おまいら、Scalaで何作る？

JVMに足りないのはlikeが付いてるあたりか。

groovy(ほか) ←→ clojure
==================
java → C#-like
==================
scala
==================
sml/haskell-like

>>549
これ読んだら別にscalaじゃなくても
javaのままでいいや
と思ってしまう。

えーscalaじゃないと思っても、Fantom、Kotlin、Groovy、Ceylonを気になれよｗ、javaでいいのかよ

>>555
結局商用とかでつかわれない
趣味レベルだし、
やがてjavaでもできるようになる
機能しかもってないから
javaのみに注力すればよいのでは？

新しいの勉強したくないわーって正直に言えばいいと思う

>>557
釣りかもしれないけど
勉強したいけど時間を無駄にしたくないだけだよ。優先度を考えてるだけ。
どうせ勉強するなら実用的で
業務にもつかえるものにしたい。
でも既存の技術にしがみつかないで
将来有効な技術なら勉強したい。
1997年くらいにjavaを勉強
しはじめて後悔してない。
Androidの公式開発にもつかえるし
サーバサイトのデファクトだ。
15年後scalaがそのような地位を
気づけているか気にしてるだけだよ。

釣りかもしれないけどｗ

558さんの先見性ぱねえっす

ｿｯｶｰ、さすがに15年後scalaがどうとか誰にもまったくワカンないと思うわー
558さんが15年後でもscalaおｋって感じ取れたらまたこのスレに遊びにきてねー

基礎と実用ってよくトピックになるが、
実用という言葉ってけっこうマジックだからなぁ。
基礎を強くしようとしてる人は、いわゆる 土方への道は進まなくてもいいけど
基礎がない人は 。。。 ね。この話しとは違うことだけど。

scalaが１５年後どうなるかって？ちょっと考えてみればいいよ。あれだけ、
複雑な仕様だってことを考えると、５年先には別のものがはやってると考
えてしまうよね。今がピークで２，３年で傾くように思うよ。
現に、javavmのライバルは増えてる。

むしろ、変化についていけるようにしておくほうが賢そうに思うけどな。
言語なんて、似たものが増えた所で学習コストは余り変わらないのでね。
Lisp族、CやJava族、ML族 この辺をおさえておいたらどれでもこいにな
れるだろう。

１５年後はまさかのSmalltalkの天下だったりしてな。もともと近未来
志向言語だったからな。

数ヶ月後、そこにはSmalltalkを勉強する558さんの姿が！

おれは558ではないが、
おまえら強がってるけど
結局scalaはそのうち廃れるんじゃね？
ってのには反論できねーんだな。
廃れるかもしれないけどそんなの
わかんないじゃんみたいな思考停止が招いた事故

実用がマジックワードだとしても、LispやMLの仕事なんてほとんどないでしょ
仕事で使えるかもしれない関数型言語というのは大きい

まあでも実際廃れるかどうかはマジでわからんし562の言うとおりいろんな言語触っとくといいよねってのは同意するよ
その中にscalaも混ぜておくとおもしろいと思うわー

>>565
それがね。。。基礎云々と言った理由なんだよ。動的の他の言語やるにしても
その他にしても、多くのアイデアや技術は、そこから流れてくるから新言語で
突拍子もなく新しいものを触るより学習を助けるってことからなんだよ。「
あっ、あの考えを使ってるのか。」ってわけ。

多分、scalaを触り続けて、scalaの複雑さに苛立った人が、また別の言語
を作るみたいなながれになるような気もする。scala△ だとか ｗ 出てく
るかも。

scalaはここ２，３年が勝負さ。その間にキラーを作って無いとね。頑張り
なよscalaの諸君！

>>567
ちょっと何を言ってるのかわからないけど、
Scalaをやってる人が他の言語を知らないという前提なら間違っていると思うが

まとめるとscala△てことか

まとめるとscala(笑)ってことか

興味のある言語を好きなだけ何個でも弄ればいいじゃん

Scala ▼0.13%

なんか新しい言語でまわりを出し抜いてみたかったんだよ。
変身願望なのかな、これって。

正直「仕事で使えるかもしれない（静的型付けの）関数型言語」という点でScalaには期待してる
もっとJavaっぽい言語に偽装して騙す感じでマーケティングして欲しい

スレのメイン話題で盛り上がっているところで流れをぶった切ってスマン。

>>538

(T)T が (Int)Int を包含するのは異論なし。
しかし、[U >: T](U)U が (Int)Int を包含しないのは納得いかない。

> 長くなりましたが、一言で理由を述べるなら、「非多相メソッド」と「多相
> メソッド」のシグニチャの間には互換性が成立しない、ということが根本的
> な問題です。

(T)T と [U >: T](U)U が互換性が無いのも異論なし。
だって [U >: T](U)U ⊇ (T)T なのは自明だから。
んで、(T)T ⊇ Int(Int) なのだから、
[U >: T](U)U ⊇ (T)T ⊇ Int(Int) になるよね。
だから、[U >: T](U)U は (Int)Int を包含するじゃん？


あと、もう一度聞くけど、>>535の(2)と(3)はそれで正しい？
大文字のXが未定義とか、Uが[]の中に含まれていないとか、
Scalaは+メソッドに交換法則を強制していないから

def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y

の方が一般的とか、気になる点が3点もあるんだけれど。

>575のような礼儀知らずに真摯に答え続ける水嶋さんを尊敬

そう思っているのはあなただけだよ
水嶋さんはこういうネチネチした議論大好物だよ

議論って本来、ねちっこさはあるよ。
それを避けて陰口を叩くだけの人多いけどな。

>>575
疑問にお答えする前に、まずは私のミスについて訂正を
> 大文字のXが未定義とか、Uが[]の中に含まれていないとか、
これは自分の単純ミスですね。確認が不足していて申し訳ないです。
正しくは、
(2) def f2[T <: { def +(other: T): T }](x: T, y: T): T = x + y
(3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: T) = x + y
です。ご指摘ありがとうございます((2)は、そもそも現在のscalaではどの道コンパイルを通らないですが)。

> (T)T と [U >: T](U)U が互換性が無いのも異論なし。
> だって [U >: T](U)U ⊇ (T)T なのは自明だから。

「 [U >: T](U)U ⊇ (T)T」という前提に問題があります。これは全く自明では無いどころか、
「 [U >: T](U)U ⊇ (T)T」は一般に成立しません。ここで、TがUと同様に多相的っぽく見えるから
話がややこしくなるので、T に Int を代入して(インスタンス化して)考えてみます。すると、
[U >: Int](U)U ⊇ (Int)Int が成り立つか、という話になります(Uはメソッド適用までインスタンス
化されない点が重要です)。で、おそらくおわかりかと思うのですが、これは成り立ちません
(リスコフの置換原則を思い出してください)。というわけで、それを前提にした
> だから、[U >: T](U)U は (Int)Int を包含するじゃん？
という結論も正しくありません。とりあえず、また疑問があれば言ってくださればと思います。

なお、
> def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y
の方が一般的というのは、技術的に誤りです。説明が若干ややこしいので、
一般的だと考えられた根拠を述べていただけると解説しやすくなります。

この兄ちゃんもよくやるなあ

>>576
そのように評価していただけるのはありがたいのですが、真実は
>>577が近いです。ねちっこいかどうかはともかく、技術的な議論自体が好物なのは確かなので。
ちなみに、あえて訂正しなかったのですが、s/嶋/島/です。いや、別に不快なわけではないのすが。

◆CgacaMDhSQ 氏は、せっかく能力あるんだから、もっと他のことに使ってほしいなあ。

とりあえず、10月ころのScalaのアップデートのスライドをたまたまWebで見たけど、
あれ、なかなか良かったです。

結局、プログラム言語の良し悪しは、どんだけその言語を使う人が居るか、プログラマーの数って重要だと思う。
プログラマーが増えるには、最近では、ライブラリーとか使用例とか、ググったらやりたいことが見つかるか
とかそういうのが重要。

Scalaでググると、言語の話ばっかりなのが、最近、飽き飽きしてきた。


Scalaは、まだまだ基本ライブラリが足りないよね。。

ちょっと今、CSVからデータ抜き出す方法をしらべてて、
たまたま次のページ見たのだけど、RubyやGroobyに比べて、ちょっと面倒なのが残念。
http://d.hatena.ne.jp/fits/20101129/1291043635

>>582

> あれ、なかなか良かったです。
関数プログラミングの集いの時のやつでしょうか？そう言っていただけるとありがたいです。

> Scalaでググると、言語の話ばっかり
海外を見渡すと、色々新しいフレームワークの話とか話題になってたりするんですが、国内だと
まだ言語の話が多いですね…

> プログラマーが増えるには、最近では、ライブラリーとか使用例とか、ググったらやりたいことが見つかるか
> とかそういうのが重要。
> (snip)
> Scalaは、まだまだ基本ライブラリが足りないよね。。
賛成です。Scalaは、標準ライブラリがあまりにも偏っている点が「実用的な」問題だと考えています。
# 特に、よく書いてますが、腐ったscala.ioはなんとかならないものかと思っています。Scala-IOは
# いつ取り込まれるのかわからんですし…
で、(本家) Scalaのコミュニティの問題の一つは、そういう実用的なライブラリを標準に取り込む動きが
遅い点にあるのではないかと。言語としてはともかく、そういう標準ライブラリの取り込みに
関してはGroovyの方が先に行っている印象です。

Iterator.continuallyを見て、便利だと思うか、面倒だと思うかでScalaを使う資質が分かれると思うね

15年後も、なんていってたら情報系黒板言語しか選択肢がないぞw
もっとも、最近のMITのオープンクラスを眺めてみれば、
RoRを使ってウェブアプリ作る講義があったりで、
黒板に書かれる言語すらも徐々に変化しているみたいだわ

ソフトウェアに永遠の命なんて戯けたことを抜かすなら、
FSFの信仰者になってGPLでソフトウェアを配布するしかないぞ

MITでRailsやってんの？イメージに合わない…

寿命だけで言えばプログラミング言語なんてめちゃくちゃ寿命長いからね
ScalaよりJVMの寿命を心配したほうが良さそうだ

>>587
Delphiの寿命は長かったといえる？

Yammer.comがScalaからJavaに戻したそうな。
理由とかはまだ調べられてないけど。

http://codahale.com/downloads/email-to-donald.txt

>>589
>>590のURLと一緒に、その背景
http://codahale.com/the-rest-of-the-story/
も読むといいかもです。わかりやすいように時系列で整理すると、
(1) Yammerのエンジニアの人(@coda)が、昔の同僚(Twitter時代)に、Scalaの一部をJavaに置き換えてるとメンション飛ばす
(2) それを見た Donald Fischer (現Typesafe CEO。 Odersky先生は現在チーフアーキテクト) が、数日語、@codaに、詳細を聞きたい
旨のメール出す(CCにOdersky先生が入っていた)
(3) @codaは、Scalaの改善に関われる中心的な人物がそういうメールを送ってきた、ということで、Scalaの経験からどんな問題があった
かを Donald Fischer にリプライ(CC: Odersky)。このやり取りはprivateなものだった。
(4) @codaは、e-mailのドラフトをgistに置いていたので、それがHacker NewsやTwitterに流出
(5) しまった、と気づいた@codaがあわててgistを削除するも時既に遅く、publicに
(6) @jodastephen はそれが流出したものだという事を知らずにYammerが公式にアナウンスしたとブログに掲載
(7) @coda -> @jodastephen 「ちょw それ、Yammerの公式アナウンスじゃなくて、それ、俺の個人的見解だから」
(8) @jodastephen のポストの影響でTwitterなどあちこちでその話が飛び交う
(9) @code が http://codahale.com/downloads/email-to-donald.txt のコンテキストを釈明 (イマココ)

まあ、流出情報ということはともかく、 http://codahale.com/downloads/email-to-donald.txt
に書かれている事自体は(書かれたコンテキストを踏まえる必要があるにせよ) @jodastephen
の記事とは異なり、読む価値があると思います。私が彼のメールで特に重要だと思ったのは

(a) Scalaの学習曲線の問題(特に、チームメンバにどうやってScalaのコンセプトを教育するか)
(b) sbt 0.7系 -> sbt 0.10移行に伴う問題
(b) Scalaのバージョン間のバイナリ非互換性問題

辺りでしょうか。彼自身がそれほど重要な問題ではない、と書いている通り、scala.collection.{mutable, immutable}
がどうとかの話は、まあパフォーマンス特性を踏まえてコレクションを使いましょうね、という話で、場合によっては
彼の書いたような指針に従ってチューニングするのもありかもしれませんが、Scalaに関する一般論としてはあまり
重要ではないでしょう。

ただ、私も原文読んだ中から、特に重要だと思った部分を抜き出しただけなので、実際の所は原文読んだ方がよかろうと思います。

技術的な問題もあるが、In addition toからの3パラグラフもなぁ

釜本さん…

@codeはたぶん消されるなw

>>593
コミュニティの話については、まあ、scalazコミュニティの一部の人とOdersky先生がひと悶着あったとか
そういう事実はあったりします。scalaz自体は私は好きなんですが、過激な人が一部に居るという話はあって、
そういう人の声が目立ってしまうという側面はありますね…。

ちなみに、パフォーマンスについて言えば、端的に@codaのやり方はエンジニアリング的に(Scala以前の問題で)
間違っているんじゃ？というのが正直な感想です。実際、java.util.HashMapよりscala.collection.mutable.HashMap
が遅いという事実は正しいです。が、実測してみればわかるように、実際には最大で3倍くらいの差で(OpenHashMapだと
java.util.HashMapとほぼ同じ速度だったりする)、チューニングする必要があるとして、パフォーマンスにクリティカルな部分
のみを置き換えるというアプローチが技術的には正しいでしょう(それよりはるかに遅いLL言語のいわゆる「ハッシュ」が
普通に使われている事を考えてください)。ボトルネックを考えずに片っ端からwhileに置き換えるとかそういうチューニングする
ルールを導入するのは、あまり筋が良いとは言えないです。これは、技術的な観点からの感想で、YammerがJavaに
戻した事についてどうこう言うつもりは無いですが。

この辺りのチューニングの話については、現Typesafe(元Google)のJosh Suerethのブログ記事
「Macro vs. Micro Optimisation」
http://suereth.blogspot.com/2011/11/macro-vs-micro-optimisation.html
が参考になるかと。

皆どうやってそんなに詳しくなれるんだ
自信無くすぜ

Javaのプロファイラは余りいいものがないなあ。
キャッシュミスとか取れないし。

eclipseよりNETBeansの方がまだましか。

>>597
なーにが自信だｗ
このアマチュアがｗ

>>599
おまえ最低なやつだな。最低だ。

思ったことより大したこと無かった。が多いと思って突き進め。
学習曲線や効率のいい資料の探し方は重要かも。

fantomの方が良い言語なんだろうか

>>602
「良い」の定義にもよるが。

scala出来ますって言ったら内定もらえました！
一昔前のスマホ持ってるアピールみたいですね！

おかしいな
三年くらいScalaやってるのに一向に職が見つからないのだが

すっからかん

Scalaを叩いてる人が引き合いに出した言語ってのは確かに気に
なるところではあるが、マイナーだからいろいろまだ足りないんだろうな

>>605
つ　現実
http://www.dreamnews.jp/?action_Image=1&p=0000027847&id=bodyimage1

cがやたらと需要高いみたいだがどこで使われてるんだろ

組み込みとかデジタル家電とかじゃないかな
メーカー中心だし給料良さそう

>>579
> [U >: Int](U)U ⊇ (Int)Int が成り立つか、という話になります(Uはメソッド
> 適用までインスタンス化されない点が重要です)。で、おそらくおわかりかと思う
> のですが、これは成り立ちません(リスコフの置換原則を思い出してください)。

なるほど。齟齬の原因が判った。

(a) [U >: Int] (U)U で表現可能な関数型の集合には(Int)Intを含む
(b) [U >: Int] (U)U で表現可能な関数型の集合には(Int)Intを受理しないものがある
は両方とも真。
俺は(a)を指して [U >: Int] (U)U ⊇ (Int)Int が成り立つと言っているのだが、
◆CgacaMDhSQさんは(b)を指して [U >: Int] (U)U ⊇ (Int)Int が
成り立たないと書いているらしい。つまり、[U >: Int] (U)U は (Int)Int の
Liskov substituion principleにおけるsubtypeではないことを書いているのだろう。

それには異論無し。
俺ならtype orderを表す時は⊇でなく≧を使うので、混乱した。申し訳ない。

齟齬が生じた原因は、想定した型推論のアプローチの違いだろう。

俺が想定していたのは、Cartesian Product Algorithm (CPA)のような、解候補集合の
うち制約充足解を選び出すconstraint-based analysisの方。だから、解は多数の
型の集合の中から制約で1つに絞れればいい。なので、(a)でＯＫという立場。

◆CgacaMDhSQさんはprincipal typeをunification-basedで求めたいので、
（ひとつの）解候補が無矛盾かどうかが興味の対象だと推測する。
だから、(b)なのでダメという立場。（正しい？）

ちなみに、constraint-based analysisアプローチは、
Demand-Driven Analysis with Goal Pruning (DDP)の提案者が
現在Scalaに適用チャレンジ中とのこと。
それ以上は知らないので、詳しい人がいたら教えてほしい。

>>579
長いので分割。

> > def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y
> の方が一般的というのは、技術的に誤りです。説明が若干ややこしいので、
> 一般的だと考えられた根拠を述べていただけると解説しやすくなります。

「一般的かどうか」については>>611で齟齬があったことが判ったので、落着。

残る点は、クラスAに、型(B)Cの+メソッドがあったとして、
def f(x, y) = x + y
というfの定義があって、これが
f(new A, new B)
を受理するためには、xとyが同じ型である訳にはいかないよね、
という単純な話。

# Scalaの言語仕様では、+には結合優先順序しか規定されていないから、
# 交換則などが利用できず、型推論には不利だよなあ。

>>611
> ◆CgacaMDhSQさんは(b)を指して [U >: Int] (U)U ⊇ (Int)Int が
> 成り立たないと書いているらしい。つまり、[U >: Int] (U)U は (Int)Int の
> Liskov substituion principleにおけるsubtypeではないことを書いているのだろう。はい。その通りです。
はい。それを意図していました。

> 俺ならtype orderを表す時は⊇でなく≧を使うので、混乱した。申し訳ない。
あー。なるほど。なんで、⊇使うんだろ…とか思いつつ、議論進めてたのがまずかったですね。
こちらも、その辺りについては意識を合わせておくべきでした。

> 齟齬が生じた原因は、想定した型推論のアプローチの違いだろう。

> ◆CgacaMDhSQさんはprincipal typeをunification-basedで求めたいので、
> （ひとつの）解候補が無矛盾かどうかが興味の対象だと推測する。
> だから、(b)なのでダメという立場。（正しい？）

正しいです。まさにprincipal typeを(unification-basedなアプローチで)求めようとすると、
Scalaの型システムだと死ねる、というのが私の言いたかったことです。

> ちなみに、constraint-based analysisアプローチは、
> Demand-Driven Analysis with Goal Pruning (DDP)の提案者が
> 現在Scalaに適用チャレンジ中とのこと。

おお。それは興味深い情報です。ちょっと調べてみます。

ところで、今更なんですが、その辺りのバックグラウンドをお持ちであったわけですし、
それを最初に明かしていただけたら、議論に齟齬が生じにくくて良かったと思います。
初学者の方が相手なのか、私などの門外漢よりも詳しい方 (:- が相手なのかによって
説明の仕方も自ずと異なってくると思いますし。

> f(new A, new B)
> を受理するためには、xとyが同じ型である訳にはいかないよね、
> という単純な話。

理解しました。

ちなみに、#コメントについてですが、SMLやOCaml、Haskellの言語でも、一般に2項演算子の交換則
などは仕様レベルの規定は無かったように記憶しています(つまり、conventionとしてそういうのが
存在するだけ)。

Spark: 高速なデータ分析のための新たな手段
http://www.ibm.com/developerworks/jp/opensource/library/os-spark/

>>615

おお、こういうScalaで実装したライブラリが増えてくると、Scala言語も安泰だよね。


ところで、これって、個人で使って面白いもの？ それともやっぱ企業の大規模プロジェクトで使うもの？

みずしまさんみずしまさん、

以前、ScalaのIO周りが未整備な点について弱点として挙げてたけど、
Scalaの特性を生かした感じでIOのAPIを作るとしたら、どんな方式があると思います？
（サードパーティで既にある、とかいうオチでも良いです）

>>617
https://github.com/scala-incubator

>>618
これ、さっぱり更新されてないんだけど、大丈夫なの？
標準に入るって噂だったけど、なくなったの？

ScalaIO開発してんのはこっち
https://github.com/jesseeichar/scala-io

>>617
私自身のもくろみは実はまた別にあるのですが、時間がなくてほとんど動けていないので、現在は
Scala-IO https://github.com/jesseeichar/scala-io
を使っています。これは、scala.ioと違ってバイト列の読み書きを含めた、「まともな」
機能郡が一通りそろっていますし、ドキュメント(scaladocだけでなく、チュートリアルが
かなり丁寧に書かれています)。まだ若干バグもありますが、そういうのを含めて
バグ報告/pull requestを送ってあげると喜ばれるのではないでしょうか。
また、プロジェクトページ自体は移っていますが、依然としてscala-incubator
プロジェクトの一つで、将来的に入る予定です(Scalaチームのプライオリティ
としてはまだそれほど高くなさそうですが)。

http://jesseeichar.github.com/scala-io-doc/index.html

また、Java 7が仮に使える環境なら(おそらく、プロダクションでJava 7を使えるところは
まだほとんどないと推測しますが)、Java 7のNIO2を使うのも一つのテかと思います。
http://docs.oracle.com/javase/7/docs/api/
ちょっとわかりにくかもですが、java.nio.fileパッケージ以下のやつです。これは、今までのjava.io
等と比べてかなり簡潔に書けるようになっています。

>>613
ああ、申し訳ない。
俺は本当にScalaも型システムも初心者なんだ。

初心者なりに「型推論」という問題を考えてはみたが、
それを簡潔に説明するための専門用語を全然知らなかった。

この数日で、それじゃあ全然話が通じないのが判った。
だから、◆CgacaMDhSQさんの使った用語を起点にして、
関連する主要な論文を何本か読んで、
なんとか会話が成立するスタート地点にやっと立ったというのが現状のレベル。

ここまでだけでもすごく勉強になった。ありがとう。
飽きてなければ、これからもよろしく。

とりあえず、この数日のやり取りで、
Scalaは他ができてることができないんじゃなくて、
他が踏み込んでいない領域に(Javaとの相性向上のため)敢えて踏み込んでいて、
そこには最新研究でも未踏の困難が広がっている、というのが判ったよ。

>>621
>時間がなくてほとんど動けていないので

天才と凡人の差がここにあり。

mizさんには、もっと大きいことをやって欲しいなあ。
つまらない論争に顔をだしてないで。


ただ、あちこちのBlogに顔出して技術サポートしているのは、結構助かってるので続けてほしい気も。
Scalaの話題でBlogあちこち見たりするんだけど、
内容が怪しいところにはたいていmizさんのコメントが入っているので、見ていて安心感がある。

>>621-622
なるほど、ありがとう。

みずしまさんって何者さんですか？

>>623
なるほど。最初からバックグラウンドをお持ちなのかと思っていました。
私は特に飽きてはいないので、またネタがありましたら、議論しましょう。

>>624
そうですね…。確かに、自分は天才ではなく、行動力が少しあるだけの凡人だと思います。
「もっと大きいこと」ができるか、に関しては、12月中にとある発表ができると思いますので、お待ちあれ

論争に関しては、顔を出す前にその「質」を見極めることが重要なのだろうと今は思っています
今回の件で特に痛感したのですが、議論するだけ無駄、という場合はやはり多くあるので。技術サポート
というか、無差別な訂正の方は、今となってはややC/Pが悪いかな…という気がしています。

>>626
何者でもない、新米社会人エンジニアで、Scalaが好きなだけの人です。コテやってるのは、単に後から
参照したときに自分がどういう風に議論してたか思い出すためと、もはやトリップつけなくても発言特定
されてしまうので、他の人がNG指定しやすいように、くらいで深い意味は無いです

くたばれゴミクズ

>>500
これの対応って型システムの拡張が必要なのかな？
結構ぶつかる問題なので、早めになんとかしてほしい…

>>629
実装上の問題(バイトコードレベルでのジェネリックスの表現に関する問題)で、型システムは拡張
しなくても良いです。ただ、これを修正することでどれくらい影響が出るか、ちょっと把握できていない
ので、必要なら公式MLで聞いてみるとかした方が良いのではないかと。

s/バイトコードレベル/クラスファイルレベル/ です。

>>630
ありがとう。
とりあえず、できるけど面倒ということで、
当分（下手したら永遠に）改善されないことがわかったw

>>627
> そうですね…。確かに、自分は天才ではなく、行動力が少しあるだけの凡人だと思います。

当たり前だ。誰がお前の事を天才だなんて思ってるんだｗ

日本の技術者だの研究者なんて99.9% が紹介屋なんだよ。

はやく Odersky　と一緒に並んで写真撮ってけ

いろいろ役に立つぞｗ

>>633
別に誰かがそう思ってるとは言ってなくて、単にまあ自分は凡人ですね、という同意レス返しただけですけど
それはともかく、Oderskyと一緒に並んで写真を撮る機会はこれまでもありましたが、それがどれほど役に
立つものでしょうか？そういう風な権威付けは実態が伴って無いものですし、すぐにメッキが剥がれるもの
じゃないですかね。

つーか、大学院生 or 研究者上がりだと、普通にその分野の権威と
飯食ったり酒飲んだりする機会が結構あって、エラい人と一緒に居たとか
そういうのに希少価値を感じないよな

>>634

633 は、マジレスする内容じゃないだろ。w


そんなことより、情報サイト充実させよーぜ。TIPS集がまだまだ足りない。

謙遜すらできないこんな世の中じゃ

>>635
程度問題でもあるんじゃないの
クヌースと飲み屋で飲み明かしたとか、それぐらいになれば
さすがに得難い経験だと思うｗ

「ジョブズと昔、川に行ってさあ」みたいな感じか

scalaプラグインはデバッガ周りが弱いなあ。
変数の値がほとんどみられないのはストレスだ。
なんか対策ない？

>>635
それはあると思います。いやまあ、自分はミーハーなんでファンとしてサイン
ねだったりすることがありますが、それはともかく。

>>636
マジレスしてすいませんorz
TIPS集とか足りない兼はなんとかします。ただ、私一人だとどうあがいても労力に
限界があるのも確かです。その辺の新しい動きは12/10(土)に発表しますんで、もうちとお待ちください

>>640
ちょっと今確かめたところ、エディタからの変数のインスペクションがうまくいかんですね。これ、以前の
バージョンでは機能していたような。ともあれ、Debugパースペクティブの「Variables」ビューで、ローカル
変数を含めた変数の値が取れます。あと、Window -> Preferences -> Scala -> Compiler で、デバッグ
用シンボル情報吐かないように設定してたりしません？

InfoQ: YammerがScalaからJavaへ移行中
http://www.infoq.com/jp/news/2011/12/yammer-scala

Scalaはオワコン

はじまってもいねーよ

InfoQは喧嘩売ってんのか
潰すか

>>645
知り合いのハッカーに泣きつくんですか？

>>646
kmizuとyuroyoroとxuwei_kをなめんなよ
InfoQなんて明日にはこの世界から消滅してるぞ

殺意の波動に目覚めたscalaちゃんがInfoQ潰してる絵はよ

>>647
何かを召喚できそうなトリオだな。

何でもいいからコード書けよカスども

よーしパパ糞コード量産しちゃうぞー

javaのstaticフィールドにはどうやってアクセスすればいいのでしょうか？

A.java
class A { static int si; }

に対して，scalaからA.siとやってもコンパイルエラーになってしまいます。

>>652
単にアクセス修飾子の問題
siをpublicにすればＯＫ
https://gist.github.com/144306
もちろん、クラスAが名前ありのパッケージに所属してるなら、package privateでも、
同じパッケージのScalaクラス/オブジェクトからアクセスできるけど、今回はそれに当てはまらない。

ありがとうございます。
逆に言うと、public にしなければ不可なんですね…

うーん、またjavaでラッパーを書くことになりそうです。

ちなみにgithubのコードはC++でしょうか？

>>654
あ、申し訳ない。なんか別のを貼ってしまったようだ。こっちが正しい
https://gist.github.com/1443062
それで、よくわからないところがちょっと。無名パッケージを使うときって、
使い捨てのコードくらいというのが普通の認識なんだけど、無名パッケージの
package privateなstatic 変数にScalaからアクセスしたいというのはどういう状況なんでしょうか？

仕事で使っているライブラリがちょっと特殊なんですよ…

しかしscalaとjavaの相互運用はなかなか微妙なんですね。
ちょっと自分のscalaのレベルでは併用は早過ぎたようです。

>>656
>仕事で使っているライブラリがちょっと特殊なんですよ…
なるほど。しかし、それってちょっとというかかかなり特殊なのでは？
それでもあえてやるなら、リフレクション使う、という手はありますが…

scalaとjavaの相互運用が微妙かというと、微妙な点はいくつかありますが、多くの
ケースで十分に上手くいく、というのが自分の認識です。現時点すら相互運用
のために色々妥協しているのに、100%の相互運用を目指すのはScalaにとっては
自殺行為じゃないかと

みずしまさんAdvent Calendarは？

>>658
今確認しました。あれ、自己申告制だと思ってたので、12/07に割り振られてたのに
気づきませんでした。今日明日くらいに書くのでご勘弁を

というわけで、ちょっとテキトーですが、Advent Calendarの記事アップしました。
https://gist.github.com/1445310

scala使ってる人のことなんて言うの？scalaer？

スカリスト

Scala, Scaler, Scalistの順で位が高くなります。

Scalizerに変身できるようになると一人前。

スカラマニア

微妙だな。

スカリー

このスレ、コードがほとんど書き込まれてないんですが。

気付いたか…

どや
val fileText = io.Source.fromFile("data.txt").mkString
val (passed, failed) = List(49, 58, 76, 82, 88, 90) partition ( _ > 60 )

def prime: Stream[Int] = {
def prime1(n: Stream[Int]): Stream[Int] = n.head #:: prime1(n.tail filter (_ % n.head != 0))
prime1(Stream from 2)
}

素数を求めるプログラム
面接で書けと言われたらとっさに書けないよねｗ

コードはかけそうだが、計算量は？って聞かれたらつまると思う。

Streamって何？

止まらないことさ

嫁
http://eed3si9n.github.com/scala-collections-doc-ja/
http://eed3si9n.github.com/scala-collections-doc-ja/collections_14.html

大学の課題で少し質問させてください

val cmd = "val x = 0"
といった感じにscalaで実行させたいコマンドが文字列で格納されている場合に
簡単に格納されているコマンドを実行する方法はないでしょうか？
（Compiler APIは使い方がいまいち分かりません。。。）

今日は13時から第二回Scala会議
http://partake.in/events/7b7f6551-8683-4968-855f-f8a62ec4bc93
ust
http://www.ustream.tv/channel/scala-kaigi
ニコ生
http://live.nicovideo.jp/gate/lv72707765

てｓｔ

みなさんマサカリ投げすぎですよ

ｺﾈｰ

>>677
お昼寝してたら寝過ごしたけど、どうだった？

>>671
見た目は洒落てるけど、結局_ % n.head != 0なんだな。素数だから仕方ないか

>>676
val settings = new scala.tools.nsc.Settings { usejavacp.value = true }
val main = new scala.tools.nsc.interpret.IMain(settings)
main.interpret("val x = 0")
val x = main.valueOfTerm("x") //Option[AnyRef]で帰ってくるので適当に取り出す

……でいけるはずなんだけど、
2.9.1のREPLで試してみたらmain.valueOfTerm("x")がNoneになっちゃうな
なんでだろ

大学の課題ってム板のネタなの？
こんな課題出るわけないと思うんだけどｗ
Twitterのutil-eval使うか参考にすれば？

>>683
ありがとうございます。
私も某ページに文字列をeval化するサンプルがあったので
それを参考にやってみたのですが、2.9.1で試したところ同じくNoneが帰ってきていました。。

>>684
さすがにこの内容そのものが出たわけではないですｗｗ
やはりutil-evalを参考にするのが正しいんでしょうね、ありがとうございます。

>>685
処理系自分で作れじゃなくて、Lisp系でもなくてそういう課題が出るってどんなせめた講義なのかきになる。

Scalaは死んじゃうの？

それが定めならね・・・

バルス

何度でもよみがえるさ
Scalaの力こそ人類の夢だからだ
って書こうとしたら先にオチが…

scalaのvalって定義時に前方参照してもコンパイル通るけど、
実行時に例外で落ちることがあるね。
PackratParserを使って構文定義を書いてはまった。

ただ、常に落ちるわけではないのがよくわからない。
どうもval x = yみたいな単純コピーは危ないみたい。

「Scalaが難しい」という批判がある時に、
1. 書きたいことを冗長あるいは複雑にしている。
2. 学習・教育コストが高い。
の二つがある。

言語オタクは1ばかり語りたがるが、一般人は2にしか関心ないよ。
エヴァンジェリストの諸君は、そこを勘違いしちゃダメだ。

言語オタクはその二つしか語りたがらないから駄目だ

他に何かあるか？

>>691
そういう覚え方は逆に危ないです。valが危ないわけではなくて、パーザコンビネータでは、その性質上、
val同士の相互参照が発生し得るので、それを意識してないと問題になるという話です。普通にvalを書く分に
何か危険があるわけではないです。ちなみに、そういう理由もあって、パーザコンビネータの規則には
lazyを付けることが多いです。

そのときは、valの順序を変えただけで解決したので深く考えませんでした。
val の順序を変えることで相互参照が断ち切れたのでしょうか？

板移転してたのか

第二回Scala会議のタイムシフト見てるけど、コメントのレベル低すぎだろ
スキーマが何なのか知ってるやつが誰もいないとか
そこらのプログラマはXMLとか触ったことすらないのか

？

>スキーマ
何のだろう？
>XMLの

XMLのデータ定義なんて
あんまり気にしないだろう。

SOAPのWSDLやCouch/MongoみたいなDBというキーワードが出ない限り。

あの放送を見たら普通はコメントより先に発言者のレベルを心配するだろ

だな

発言者が駄目でも何を言ってるかはわかるだろ
この間のドワンゴ勉強会より内容の難易度は落ちてると思うが、見てるやつのレベルはもっと落ちてた
Scalaを難しいと言ってるやつの程度がよくわかったよ

Scalaは間違いなく難しいと言っていたきしださんの発表が
一番まともなだったというのは皮肉だなｗ

勉強会なんてあんなもんでしょ
期待してない

格下蔑んでる暇があったらコード書けよカスども

scalaの終焉が近いというのはinfoQのあの記事から感じること

お、おう・・・

一人Scalaz Advent Calendar
http://partake.in/events/4b3afdc8-e4ec-4010-b8ec-31b89210dda0

これ一通り読んだけど、すごくわかりやすくて勉強になった
プログラム例がしっかりしてるのと、簡単なものから順番に紹介してくれてるのがいい
Scalazが結構わかった気がする
残りも楽しみだ

やっぱりアニヲタなのかw

Scalaで4,10,32,50,94っていうリストがあって
入力として72と100という数値があったとして
72は、リストの値の範囲
１００は、リストの値の範囲外
という処理はどう書くのが普通なんでしょうか？

val list = List(4,10,32,50,94)
val inputs = List(72,100)
val (min,max) = (list.min,list.max)
for (input <- inputs) {
println(input + "は、リストの値の" + (if (min <= input && input <= max) "範囲" else "範囲外"))
}

(x:Int) => { val l = List(4,10,32,50,94); l.min <= x && x <= l.max }

def f(list: List[Int])(x: Int) = (list.min to list.max) contains x

sbtってもう0.11まで行ってたのね

>> 715
よくなった？

>>712が手続き的なのに対して、>>713,714は、どや顔で、元の問題の72は範囲内、100は範囲外という話を忘れている件

元のつまらない問題をいかに面白くするかが腕の見せ所だな。
>712-714はあんまり面白くないけど。

http://eed3si9n.com/ja/essence-of-iterator-pattern
おいこの記事読んでもさっぱり理解できないんだけど

sbt0.10.1→sbt0.11.1なら
scala-2.9.1に移行、2.7のサポート打ち切り
ディレクトリ構成が微妙に変わる
(プラグイン設定を /project/plugins/ に置いてたのを /project/ に置くように)
あと修正やら改良がいろいろ　詳しくは https://github.com/harrah/xsbt/wiki/Changes

まさかとは思うけど0.7系使ってるのならはよ切り替えた方が。
0.10系からはコンパイルも早くなってるし。

>>719
Read original paper.

>721の翻訳

「原論文を読め、このクズ。
ちなみに俺は英語が得意だ、hahaha!」

突っ込むなら定冠詞抜けてるのを突っ込まないと

⊛　
→
>>=
⊙
⇓
⇑
∧
これ何？

>>=はわかるだろ

>>722
>>721のように書くなら、Read the original paper. だよ。

単数形でいいの？

"Applicative programming with effects"も合せて。
というか、その論文、5年以上かかってるのね。

どうでも良い話広げようとするんじゃねえよ

誤爆

同意
ApplicativeとかIterateeとかどうでもいい
ハスケラーに騙されてるだけ

ApplicativeわからないとScala本当に理解しているとは言えないな

>>732
すべってるよ、君

小難しいことをさらに複雑にやろうとしているというのがなんとなく分かる。^^;
それがscalaなんだろうな。

haskellのapplicativeは便利なんだがな。

これだよ、これ
だからハスケラーに騙されてるって言ってんだよ


悪いハスケラー「Applicativeなら綺麗に書ける！Iterateeは次世代IO！」
↓
馬鹿なスカラー「よーしそれならScalazとか作っちゃうぞ」
↓
さらに馬鹿なスカラー「なんか難しいけど流行ってるみたいだしScalaz勉強しよう」
↓
悪いハスケラー「ギャハハハほんとに作ってる！なにこの汚ねえコード！猿真似ｗｗ関数型の面汚しｗｗｗ」
↓
一般ジャヴァー＆シーシャーパー「Scalaって複雑そうだから触れないでおこう。あとなんかキモいし」
↓
馬鹿なスカラー「あれ？世界中から馬鹿にされてる？それによく考えたらこのライブラリ使い道ないな…」


完全に嵌められてる

valとパターンマッチと便利なコレクションとimplicit parameterと型推論があるだけの
better javaとしてしか使えてない俺大勝利

ApplicativeわからないとScala本当に理解しているとは言えないな

Applicativeを無視する奴＝OOPにおいてデザパタを無視するstaticおじさん
使わなくてもプログラムは作れるが使えばもっと抽象化できるということだろう

デザインパターンってOOPの敗北の結晶だよね

>>739
どういうことかもう少し詳しく聞かせて

>>740
個人的な感想だけど
デザインパターンってOOPでは直接表現できないことを、どうにか解決してるという感想をもってる

例えば新しいプログラミング言語の機構を作ったときに、その評価としてデザインパターンが解いてる問題を
直接表現できるかみたいなのもある

visitor パターンはクラス階層に操作を追加できるようにするパターンだけど
裏をかえせば、OOPでは操作の追加が難しいという欠点があるということだし


あんまり真面目に取らなくていいですｗ

そういうのは専用スレでやれよ。

別に大した話題もないしここでもいい

Scalaではどうなるのか？ってのはおもしろいかもね。
singletonは直接サポートしてる。
そういう文章はどこかにありそう。

Applicativeって本当に理解しないとダメなの？

たぶん、知らなくてもプログラムは組めるよ。scalaは知らないけどな。
haskellも知らなくても組める。ファンクタの働きくらいはしっておい
ていいと思うけどな。

>>745
それすら理解せずにプログラマを自称するつもりですか？
恥ずかしい人ですね

>>745
この世に〜しないと駄目なんてものはない。
プログラミングしなくてもいいし。

http://learnyouahaskell.com/functors-applicative-functors-and-monoids
これの記述正しい？

>>741
何か勘違いしてるみたいだけどデザインパターンってのは
「可能にするためのトリック」ではなくて
「よく出てくるから名前を付けてみたので共有しましょう」
なんだけどな

>>741
OOP=中二病

>>749
3行でまとめてくれ

scala,java,c#,c,c++,ruby,python,php
これを難しい順に左から並べていただけませんか？

(その他大勢の複雑極まる言語), C

>>752
英語がわからないなら
読むのを
諦めろ。 ハイ３行。

Scala IDE for Eclipse 2.0がついに出たそうですが、どんなもんでしょ？

相変わらず遅いよ。
オートコンプリートをオフにできない（チェックを外しても復活する）のも相変わらず。
閉じかっこが文脈を読まずに挿入されるし、タブを使わない設定でもインデントにタブが入る。
デバッガは駄目だし、参照ジャンプもよく失敗する。

Scalaを新鮮に保つ
http://www.infoq.com/jp/news/2011/12/scala-fresher

InfoQしつけええええええええええええええ

infucku

Alex bullshitを叩けよ

ScalaがJVMの発展阻害しているから叩かれてるの？

>>762
ちょっと何を言ってるのかわからないですね

>>762
どういうことなのかもっと詳しくお願い

アホは放置で。

Typesafe、Scale向けのEclipseプラグイン「Scala IDE for Eclipse 2.0」をリリース
http://sourceforge.jp/magazine/11/12/26/0449214

はぁ〜giter8べんりすぎだろ
だれか冬休み中にsbt-coverageのテンプレ追加しといて
sbt0.11でよろしくおねがいします

なんだってwikipediaのFantomの頁は、ですます調なんだよ…

エバンジェリストって要するにステマってことだよね？

自分の身元や立場を明確にしたステマがどこの世界にあるんだよ
全然ステルスになってないだろ

裏で小田好に金もらってscalaはスゴイ！って言い回ってんだろ？

なんでSymbolのArrayから要素取り出すときはapply明示的に書かないとダメなん？
ClassManifest[Symbol]が無いから？

scala> Array(0,1,2)(0)
res0: Int = 0

scala> Array('a, 'b, 'c)(0)
<console>:9: error: type mismatch;
found : Int(0)
required: scala.reflect.ClassManifest[Symbol]
Array('a, 'b, 'c)(0)
^

scala> Array('a, 'b, 'c).apply(0)
res2: Symbol = 'a

>>772
Arrayオブジェクトのapplyの定義が違って
2つ目の書き方だと取り出す以前に配列を作成できていない

def apply(x: Int, xs: Int*): Array[Int]
def apply[T](xs: T*)(implicit arg0: ClassManifest[T]): Array[T]

implicit parameterでClassManifestを取るところを明示的にInt渡してるからエラーになってる

なるほどありがとう

↓をしないとimplicit parameterとして解釈されちゃうのか

scala> Array('a, 'b, 'c)(implicitly[ClassManifest[Symbol]])(0)
Array('a, 'b, 'c)(implicitly[ClassManifest[Symbol]])(0)
res19: Symbol = 'a

ここまでするならapply明記するかなーというのが妥協点として有力ですね

素直に生成と取得をわけるのが一番楽でないかい？
val a = Array('a,'b,'c)
a(0)

普通はそれでもいいんですが
mapの中なんで一時変数作りたくなかったんですよ

>>769
逆。ステマってのが要するにエバンジェリスト。

そこまでこだわるんならArrayはmutableなのでIndexedSeqにしようぜ

ステマよりスマタだよ アンタ

身持ちの硬いJavaのfinalクラスをpimpしてハッピーヒモ生活をenjoyしますぜ？

誰にでも継承させるビッチclassは怖くて使いたくない

scala.runtime.BitchString

Cygwin + Cygterm + Tera TermでREPLやsbtの行編集が使えてる人いる？

rxvtなら英語の情報があるんだけどTera Termは和製だからなぁ

Cygwinなんて捨てろよ

これか？
A Report from the Sewer Hole: Cygwin, JLine, rxvt, and the Scala REPL | Java.net
http://weblogs.java.net/blog/cayhorstmann/archive/2010/11/24/report-sewer-hole-cygwin-jline-rxvt-and-scala-repl

>>785
そう。そのrxvt用のパッチは既に公式のscalaシェルスクリプトに含まれている。
ただ、そいつがTeraTermと相性が悪いから、とりあえずその行はコメントアウトして凌いでる。

>>784
> Cygwinなんて捨てろよ
俺だってWin捨てたいよ・・・orz
まあ、rxvt用パッチが公式に入ってんだから、世界でもCygwinの需要はあるってことで見逃してくれ。

>>786
で、できたのか？
-Djline.terminal=jline.UnixTerminalとTERM環境変数を適切に設定すればいけると思うが

>>787
いや、rxvtとは端末特性が違うのでそれだけではダメ。
sttyをいじるだけで済めばいいが、jlineにパッチを当てる必要があるようだと面倒だな・・・

eclipseのScala IDEって、コンストラクタはOutlineに表示されないんだな。
しょぼっ

何も分かってないんだから諦めてrxvt使えよ。

jline外して、rlwrapのcygwin実装探してはどうだい？
http://www.google.co.jp/search?hl=ja&q=rlwrap+cygwin

>>791
ほむほむ。これは知らなかった。最後の手段に使えそう。さんくす！

Int => Int = <function1>

ってIntを引数にとって、無名関数がIntを
返すっていう定義であってる？

なぜこの２つは同じ定義なのでしょうか？
def a[Int]:Int => Int = b => b
def a[Int]: Int => Int = ((b: Int) => b)

bの型がaの型をもとにしてInt型と推論されるため

Int = b => bって記述がよくわからない
これってどう解釈すればいいの？
なぜ、型に変数代入できるの？

たとえば　def a: Int = 1　は
aが名前で:と=の間のIntが型で=以降が値の1
同じように　def a: Int => Int = b => b　は
aが名前で:と=の間のInt => Intが型でb => bが値

>>794
は型変数にIntって名前を使ってて紛らわしいな

前から思ってたんだけどさ
原監督に似てるよね

お腹をなんとかしないと

scalalaもscalaNLPもプロジェクトはもう死んでるのか。
いい数値演算と言語処理のライブラリ／バインディング知らない？

2.10.0-M1

2.10って何違うの？

Scala2.10って、 文字列中の式展開が導入されたんだっけ？

Included in this release are:

・Preliminary Reflection API
・faster inliner
・scaladoc improvements (Thanks docspree folks!)
・virtualized pattern matcher
・many more!
ってわかんねーよ

基本的にDSL作者向けがメイン？

きっとエロイ人が日本語で詳説してくれるに違いない

var s = immutable.Set[String]()
s += "item"

っていう例で、+=を自動で + とvarへの代入する言語仕様って、
+と-以外の演算子でも有効？

>>807
メソッド名が演算子のみで構成されてるならなんでもおｋ

l += rという表記は、
・変数lに入ってるクラスに+=というメソッドがない
・変数lがimplicit conversionで+=というメソッドを持っているクラスに変換できない
・l = l + rが型的に正しい（lがvarで宣言されていて、lがメソッド+を持っている）
以上をすべて満たしてる場合にl = l + rとして再解釈される　…って言語仕様の6.12.4に書いてあった

class A(init: String) {
　var str = init
　def *^-^*(s: String): A = { str += s; this }
}

var l = new A("left")
l *^-^*= "-right"
println(l.str) // => left-right

こんなのでもいける

>>808
Thanks! 完璧に求めている答えでした。
でも、ということは、list = x :: list というのは略記できないってことなんだね・・・

>>809
list = x :: list は

list = list.::(x) って意味なので

list ::= x と書ける

けど正直分かりにくいと思う

printfは使えるのに、Console.err.printfは
overloaded method value printf with alternatives: ・・・
とか言われて、使えん。なぜ？

format()とか付ければ回避できるけど、タイプ数がもったいない。

メッセージの通りだよ
引数に渡してるものの型が定義に合ってない

def printf(String, Object*): PrintStream
def printf(java.util.Locale, String, Object*): PrintStream

Object(AnyRef)の可変長引数だからIntとかはそのまま渡せないね

>>812
なんてこった！Predef.printfはAny*だったから動いてたのか！
可変引数にはautoboxingかからないんだな。
またひとつ賢くなっちまったぜ。
さんきゆーふれんず

　　テスト　テスト

以下のソースで、access()の中でnofifyListenersを実行して、その中では各リスナー(Actor)にChangedというメッセージを送っているけど、
これってリスナーのメールボックスにメッセージを送るだけで、処理が終わるのを待たずに次の行のcount += 1が実行されるという認識で大丈夫ですか？

case class Add(who:Actor)
case class Changed(what:AFoo, count:Int)
case object Access

class AFoo extends Actor {
private var listeners:List[Actor] = Nil
private var count = 0

def act = loop {
react {
case Add(who) => listeners = who :: listeners
case Access => access()
}
}

private def access() = {
notifyListeners
count += 1
}

private def notifyListeners() = {
listeners.foreach( a => a ! Changed(this, count))
}
}

半角スペースになっちゃった
ソースの続き

class AFooListener(afoo:AFoo) extends Actor {
　　afoo ! Add(this)

　　def act = loop {
　　　　react {
　　　　　　case Changed(f, cnt) => changed(f, cnt)
　　　　}
　　}

　　def changed(eventFrom:AFoo, count:Int) :Unit = {
　　　　if (count < 10) eventFrom ! Access
　　}
}

そういえばActorにJavaからメッセージを送るにはどうすればいいんだろう？

>>817
俺が答えるのもあれだけど、ラッパーメソッド？的なモノを用意すればいいんじゃない？

// コイツをJavaから実行
def sendFromJava(s:String) = {
　　actor ! s
}

クロージャをサポートしているオブジェクト指向言語での、yieldの存在意義がよくわからない。

>>819
クロージャって yield の代替になるの?

継続ならyield実装できるけど、クロージャではな。

このスレの278のサンプルだが、こうだ。

(1 to 10).map(i => "a" + i -> i.toString)
for(i <- 1 to 10) yield i => "a" + i -> i.toString

yieldを使わなければ出来なくて、有効なケースってどういうのがあるの？

>>822
そりゃ、yield じゃなくて for 式が map に置き換えられるって話でしょう。
言語仕様で for 式は他のメソッドに置き換えられて実行されると決まってるのだから、
当然 yield 無しに書けないコードは無い。ただ、そっちのが読み書きしやすいってだけの話。

scala-androidって使ってる人いないのかな。
今のScala-IDE(eclipseのプラグイン)と組み合わせてちゃんと動く気がしない。

>>824
sbtのほうは1.7ぐらいの時に動かしてみたけどeclipseは当時ひどくて試してないなー。いま簡単に動くなら試してみたいけどつらそうだね。

scalas が不可解。 https://github.com/harrah/xsbt/wiki/Scripts
sbt 固有のログがコンソールに出てきて鬱陶しいから次のような感じにしてんだけど、
"[info] Set current project to ..." ってのが最初に出てくる。どうしたらいいの?


#!/usr/bin/env scalas
!#

/***
scalaVersion := "2.9.1"

logLevel := Level.Error
*/

println("hoge")

スケーラブルで関数型でオブジェクト指向なScala入門
http://www.atmarkit.co.jp/fjava/index/index_scala.html

最近scala界隈落ち着いちゃったね

ScalaスレもErlangスレも過疎

Scalazに走ったあたりでネタ切れ感があったよね
Play2.0でまた活発になるといいね

scala、非の打ち所が無いまま、安定飛行に入る。
いま、ブレーク前夜に特有の静けさ。

JVM上じゃなくてHaskellのGHCみたいなのがあったら、話は大分違っていたのだろうか

ネイティブコンパイラがあったところで状況変わらんでしょ
単に言語のネタとして話すことがなくなってきたというだけでは

2.10.0-M1とかも出たけど、周辺ツールがバージョン番号で雁字搦めになってて、
試すのも面倒臭いんだよねｗ

バイナリのバージョン縛りは厳しいな。依存ライブラリをソースからダウンロードしてコンパイルまで自動化するツールが待たれる。

Play2.0-RC1来たよ

Finagleとかもわりと面白い。

linux環境（CentOS 5）でakkaを試してみたが、別ホストへのメッセージ送信が拒否されてしまう。
iptablesも起動してないのに誰がパケットを遮断してるのか…

分散プログラミングはwindowsの方が楽だな〜
単に自分がlinuxに無知なだけだけど

別ホストでnc -l -p xxxxってやっといて、telnet xxxx yyy とかでまず繋がってるか試してみては？

>>839
助言サンクス

838のあと、自前でポートスキャナを書いてチェックしてみたんだけど
同ホスト内でスキャンするとアクターの受信待ちポートがみつかるのに
リモートからのスキャンだと見えなかった。

きっとlinuxユーザなら常識的な何かを見落としてるんだと思う。

netstat -a の結果を貼れ

Play2.0-RC2来たよ

そろそろ出るの？

>839>841
ありがとう。おかげで解決した。

nc -l xxxx 50000で待つ場合と
akkaのアクターで同じポートで待つ場合をnetstatで比較したら、
前者はlocal addressが*:50000、後者はxxxx:50000
になっていた。

どうもakkaではホスト名で登録するとxxxxになるので
IPアドレスを直接指定しないと駄目みたい。

インターフェース固定でacceptかよ。だっさ。> akka

教えてください。
Javaで以下のようなBuilderパターンの実装があります。
Builderオブジェクトはサイズが大きいので
Builder.Resultオブジェクトを利用するときには解放したいのです。

|class Builder {
|　static class Result {...}
|　Result build() {...}
|}

それをScalaで実現するにはどうすればいいでしょうか？
(結果の型はBuilder.Resultにしたいという制約があります)

以下のようにすると、Builder.Resultオブジェクトが
Builderへの参照を持ってしまいます。

|class Builder {
|　class Result {...}
|　def build(): Result = {...}
|}

以下のようにすると、Builderへの参照は持ちませんが、
せっかく関数型言語にしたのに冗長ですし、
関連のあるコードが遠くに離れてしまい、保守性を低下させます。

|class Builder {
|　def build(): Result = {...}
|}
|object Builder {
|　class Result {...}
|}

object Builder {
class Result {...}
class Builder {
def build(): Result = {...}
}
}

- Javaのデザインパターンはバッドノウハウ
- Resultってクラス名が本質的な意味を持っているとは思えない
- Builderと言っている機能はコンパニオンオブジェクトで実現可能

Javaのクラスx.y.Cに対して

type A = x.y.C

みたいな感じで，クラスの別名を定義できますが，
x.y.CのstaticメンバをA.fと参照することはできないようです。

importせずになんとか別名経由で参照する方法はないでしょうか？

>>849
可視性が通ってないんじゃないの。

Effective Scala - Twitterのベストプラクティス
http://www.infoq.com/jp/news/2012/02/twitter-effective-scala

play2.0RC2でデフォルトの9000番からポート変更するのってどうやるんですかね？
stackoverflowに同じ質問があったんですがうまく設定できない…

Function数字.scalaとか
Product数字.scalaとか
Tuple数字.scalaとか
何でこんな名前なの？

scalaは型引数が違うだけの同じ名前のクラスは定義できないから

あーそれで数字が増えるに従って型引数も増やしてるってだけなんだね
マトモに中身見ずに聞いてました、ありがとう

動物本プログラミングscalaの1.5並行処理の味見、scala -cp . shapes-actor-script.scala
実行しても待たされた挙句に何も出力しないで帰って来る。

なんでじゃああああああw

なんか打ち間違えてるんじゃないのｗ

>>856
remoteでないのなら単純な理由だろうな〜
start()叩いてないとか？

start()は入ってました。shapes-actor-script.scalaそのまま。
打ち間違いは今のところ見当たらず。
-cpのパスを故意に別のパスにするとShapeDrawingActorがMissing dependencyだって文句言ってくるから
scalacしたクラスファイルは読み込んでると思う。

ﾉﾜﾜｰﾝ

>>858
「remoteでないのなら」ってのはどういうことですか？

オラからソースダウンロードして実行しても同じ結果でした。
こりゃ環境の問題でしょうね（Fedora16上でやってます）。

>>859
動物本を読んだ事が分からないんだけど、それってリモートアクター？
そうならば通信がどっかて止まっているのかも。

selinuxの問題だろｗ

暗黙のパラメータはimplicitを関数の引数リストの先頭に書くことで実現できますが、
何故引数一つ一つに付けられないようにされているのでしょうか？

逆になんで一つ一つに付けたいと思うのか

>>862
これは私の話のことですか？
気になったので一応/etc/selinux/configでSELINUX=disabledをセットして試してみましたが、変わりませんでした。

>>865
そもそもリモートアクターなの？

Scala IDE 2.0 - リファクタリングサポートを追加
http://www.infoq.com/jp/news/2012/02/scala-ide

Play2.0-RC3来てるよ

な、な、なんだって

PlayのRCは昔のScalaのRC並に信用できないね

2.8.0がRC7くらいまで行った時は吹いた

scala系は、バグなければリリースがRCではなく、機能追加が止まるのがRCだっけ？

http://www.playframework.org/2.0#features
https://play.lighthouseapp.com/projects/82401/milestones/122723-20
https://play.lighthouseapp.com/projects/82401-play-20/overview
1系から2系に足りないやつ持ってきて追加してるフェーズ？

2.9.1-1

はい

・原発は日本を滅ぼす、即時全廃せよ

・六ヶ所村再処理工場直下に二つの活断層

・耐震基準450ガルと、著しく耐震性に欠ける施設

・大事故が起きたらチェルノブイリを遥かに越す未曽有の大惨事が

・代替は天然ガス・コンバインドサイクルで十分

http://d.hatena.ne.jp/kensho01/20120208/1328718592

最近、このＳｃａｌａスレ過疎っているけど、どうしたの？

単に主要人物が２ｃｈから離れているだけ？
東京とか名古屋とか仙台とかのＳｃａｌａ勉強会は盛況？

さすがに話題がつきているのではないかな
言語仕様的には2.9って2.8とほとんど変わってないから、ずっと2.8時代が続いているようなもんなんだよな
2009年のBetaで盛り上がってるころからずっと同じ言語を見てると思うとさすがに言語ウォッチャー的には飽きてくる

応用に至ってデカイものを仕込んでるんじゃね？

ライブラリの話でもすれば良いのではなかろうか。

akkaのFSMってActor.context.becomeで置き換え可能かな？

Akka 2.0出てるね

abstract classとtraitの違いって
コンストラクタが持てるかどうかだけですか？

いいえ

はい

文字列に変数埋め込む方法はないんでしょうか？
軽くググッたらXMLリテラル使うといいかもっていうふざけた答えがみつかりましたｗ

標準ライブラリにはないとしても、例えばJavaでいうところのStringUtilsくらいの
メジャーなライブラリで用意されてたりしないんですか？
Javaしか使ったことないんだけど、LL言語で唯一憧れるのが#{foo}みたいな記法
これないと不便ですよね

あ、String.format() は存じております
文字列リテラル自体がそういう記法に対応してないのかなと思いまして
あ、これだとライブラリにないでしょうかっていう質問がおかしいか…

うーん、結局Scala界では、こう書けるんだから何も不便しないだろｊｋって感じでしょうか
"Lv.%d%n攻撃力 %,3d%n防御力 %,3d%n生命力 %,3d".format(lv, atk, deff, hp)

文字列中の式展開は2.10で入るかもって話だったな

- 予め整形した文字列同士を + で結合

- $を使ったインデックス参照形式での埋め込み
"SELECT name FROM tbl WHERE id > %1$s AND name LIKE %2$s".format(10, "Tom")

今の所これで事足りてるかな

みなさんご存知だと思いますが、Play2.0 Finalが出てますよ

あれ？ほんとだ！なんかサイトも綺麗になってる！
RC信用出来たじゃないですかー！やったー！

Play2.0のJavaの部分を担当している人は何をモチベーションに作業してるんだろう
誰も使う人なんていないのに

この言語は何がメリットですか

使うとクールでクリエイティブなプログラマーになれます

トレンディということですか？

はい、そうです

誰かPlayのIterateeの解説をブログで書いて

Scalaは仕事で使いますか？

使ってるよ。

使えるような手筈を整えてる最中だ。最近ようやくチャンスが巡ってきた感じ。

うちもそんな感じだ。
使える人、使いたい人も徐々に増えてきた。

Scalaで物理単位を扱うのに何か良い方法ってありますかね
HaskellのDimensionalのような

Spark によるデータ分析とパフォーマンス
http://www.ibm.com/developerworks/jp/linux/library/l-sparkdataanalysis/

http://msdn.microsoft.com/ja-jp/library/dd233243.aspx
F# 単位

http://code.google.com/p/lascala/source/browse/trunk/scala/data/Measure.scala
Scalaだと、こんなのはあった。

Play2.0のIterateeを理解したい
http://d.hatena.ne.jp/papamitra/20120318/Iteratee

papamitraさんありがとう！

google summer of code 2012
http://www.scala-lang.org/node/12565
プロジェクト案発表したみたい

あれScalaってまだオラクルに買収されてないの？

Javaと違って大学教授が作った言語なので買収とかは別に…

Typesafeが、どっかに買収されるということはありそうだけど。

java 8以降の普及に邪魔だからそのうち消されると思うけどね

消されるってw

それができるならオラクルはScalaの前にC#を消すべきだと思うの

androidはJ2MEのライセンス料が携帯端末から取れなくなる問題で、
MSのJava実装は他との互換性がなくなって囲い込みされる危険性に反応したんだとおもう。
JVM言語については、いまのところ否定的なコメントはないと思う。
マルチVMや特定JVMへの最適化や、Javaのコントロールに意味がなくなるに危険性を感じたら何かするかもしれない。
RHやIBMやMSが主導権握る事態になれば何かあるかもしれない。

>>914

難しい。

Scalaが大学で研究開発されている言語であるからOracleに買収されることはない話と、
914の話は何のつながりがあるのだろうか？


ところで、RHって何？

iterateeって何ですか？
どうやってこれ作っているのかよくわからない

良いボケが思い付かない

RedHat

Scalaって名前がかわいいな・・

>>919

検索すると、いっつも、とある会社がトップにひかかるのだが、、。

>>919
でてこないよ？wikipediaがトップ。

TIOBE のプログラム人気順位
http://news.mynavi.jp/news/2012/03/14/015/index.html

↑
Scalaは、まだまだ50位にも入らないのか。
このスレも過疎化がすごいし、みんなどこへ行ったんだろう。

みづしまさん来なくなったしね

転職先がブラック・・・

みんな働き始めればこんなもん。

Statelessなakka.actor.Actorの実装ってどうすればいいんだろ？
Actorじゃなければ case class にして状態が変わるたびに新しく生成すればいいけど
Actorだとメッセージの受け口であるreceiveがインスタンスに結び付いてるから作り直す事ができない。

↓のようにreceive関数をカリー化してbecomeで遷移するのかな？
def receive_with_state(x: Int): Receive = {...}
become(receive_with_state(1))

状態が増えるとカリー化してる部分が汚くなりそう...
なんか良い方法ないすかね

>>926 ご参考
Shows a simple request/response wrapper for Akka Actors
https://gist.github.com/1043056

>>925

でも、各地で開催されているScala勉強会はまだ続いているんだよね。

>>928
ScalaJPとかも動き始めたから、みんなそっち行ってるのかも。

Scala in Depthって良書ですか？

Functional Programming in Scala
http://manning.com/bjarnason/
っていう本の電子版が、クーポン番号知っていれば安く買えるとTwitterで知ったので
さっそく買おうとしてみたら、すでにクーポン番号は使用期限が切れていた。

manningならMEAP35%引き前後の常時クーポンがあったはず