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

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

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

前スレ
プログラミング言語 Scala 3冊目
http://pc12.2ch.net/test/read.cgi/tech/1261779856/

・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
乙

ほしゅ

ほしゅ ほしゅ

前スレの >> 943
CodeZineの記事の著者です。

> e.getProperty("user")では空文字列が返り、
> e.getProperty("members")ではNullが返ってきてしまう理由がよくわからないのですが、
> これはなぜなのでしょうか？
> [User]と[JList[User]]の違いなのか、それとももしかするとapp engine sdkの仕様なのでしょうか。

その通りで、"members"プロパティはListPropertyと呼ばれるもので、
keyに対してのvalueが一件もない場合はnullが返るのがLowLeveAPIの仕様です。
本来はList[User]()が返ってきて欲しいし、
そのようにimplcit conversionできればいいんですが、
ジェネリックスの仕様的に無理なんでnullチェックするしかないです。

記事のコードでそのへんのチェックが抜けていたのは
完全なバグですのであとで直します。

あと、LiftをREPL環境で動かすには、
LiftConsoleってのがあってそいつが便利です。

mvn scala:console
でmavenからREPLを起動した後に、

(new bootstrap.liftweb.Boot).boot

とREPLに入力することでLiftのBootStrapが読み込まれて、
Modelなんかにアクセスできるようになります。
GAE環境ではSDKがサポートするローカル環境をエミュレートする必要があるため、
LowLevelAPIを利用したModelはさわれませんが。
このへんは、Slim3とかことーじゃを参考にすればなんとかなるかな、
とは思ってますが手をつけてません。

最近はあまりLift追ってない。。。

sageまちがえたorz

どんまい‼

http://tryhaskell.org/
http://tryruby.org/
http://www.tryerlang.org/

Scala はこういうの無いん?

つ http://www.simplyscala.com/

ボクらのScala ~ 次世代Java徹底入門 浅海 智晴 (単行本 - 2010/6/25)

って、どうだろう？

別にお金出して買うのに抵抗はないけど、
部屋の本棚がオーバーフローしているので、本買うのは躊躇してしまう。。

次世代Javaって

>>11
さんきゅ

>>12
タイトルが釣りすぎる

Relaxerの人か
著者は悪くないね

おおお、yuroyoroさんご本人ですか！レスありがとうございます！
twitterでフォローさせてもらってますｗ

>>keyに対してのvalueが一件もない場合はnullが返るのがLowLeveAPIの仕様です。
やはりそうなんですね。
自分はまず前編を拝見させて頂いて、そのアプリでブラウザから操作をしてみて、
そのあと後編のソースコードを上書きしたんです。
前編でmembersプロパティがないeventエンティティをデータストアしてしまったので、
後編のソースコードに上書きしたらnullエラーが出るようになってしまっていたのでした。
途中ででそれに気づいてDBからデータを全部消したら後編のプロジェクトもうまく動くようになって、
それで今いろいろ勉強させて頂いているところです。

ちょうどScalaでGAEアプリを作ってみたいと思っていたところでyuroyoroさんの記事に出会い、
とてもラッキーでした。
とてもためになる記事を書いていただきまして、本当にありがとうございます。

せめて
次世代Java系スクリプト徹底入門
じゃないかと思うぜ

>>12
「次世代Java徹底入門」はかなり気が早いですね。
でもGroovyより速いペースで普及しているから
数年後には現実が本のタイトルに追いつくかもしれません。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Java
http://www.indeed.com/jobtrends?q=Scala,Groovy

>18
「次世代Java系スクリプト徹底入門」は問題外だと思います。
GroovyがJava系スクリプト言語とされるのは言語仕様に動的型付けを含むからです。
Scalaは型推論を取り込んだ静的型付け言語です。
Javaがスクリプト言語ではないように、Scalaもスクリプト言語ではありません。

動的型付だからスクリプト言語じゃないってのも違うような

動的じゃないや静的

インタプリタ的(ソースそのまま)に動かせるかどうかって所だと思うわスクリプトか否かって

明確な定義ないしどうでもいい

<-
の代わりに
←
が使えるけどみんな使ってる？

>>23

使ってないな。そうでなくてもたくさん矢印あるんだから、意味が一緒ならこれ以上増やすなと言いたい。
いわゆる全角ってのも受け付けない。

http://demo.liftweb.net/count
の

object CountHolder extends SessionVar[HashMap[String, Int]](new HashMap[String, Int] {
override def default(key: String): Int = 0
})
の文法についてなんですが、
new HashMap[String, Int] のあとにある　
{
override def default(key: String): Int = 0
}
って、なんなのでしょう？
これはHashMapクラスの default メソッドをオーバーライドしてるって理解で
いいんでしょうか？
[String, Int]のあとの
{
}
がよくわからないです。new したあとにクラスのメソッドをオーバーライドできる？
のでしょうか？

>>25

Javaの無名クラスと同じ。継承とインスタンス作成を同時におこなってる。
その場でHashMapのdefaultメソッドをoverrideしたクラスを定義してる。

(なおかつ、それをSessionVarのコンストラクタに渡し、さらにそれを継承したCountHolderというobjectを定義してる)

>12
そのうち、Scala自体が、Java好きな人達に叩かれるようになるんじゃないだろか。

>>27
でも、Scalaの周辺環境やツール類の問題(ビルドが遅いとか、IDEがJavaに比べて未成熟だとか)は
ともかくとして、言語としてのJavaがScalaに勝ってる箇所って無いに等しいから叩くにしても
言語仕様が複雑過ぎる〜とかそういうのになりそうな気がする

一番重要な実行速度はJavaが上だろ

実際の使用に差出るほどの影響はないんじゃないの。

なんでそう思う？

むしろ遅い方の実測値を出せ

なんともいえないけど、前より差が減った気がする。

64bit クワッドコア http://shootout.alioth.debian.org/u64q/scala.php
64bit シングルコア http://shootout.alioth.debian.org/u64/scala.php
Scala compiler version 2.7.7.final
jdk1.6.0_18


ところで、Actorsの競争はどうなってんだ。ベンチマークするのめんどい・・・
http://www.slideshare.net/jboner/akka-simpler-scalability-faulttolerance-concurrency-remoting-through-actors
http://www.malhar.net/sriram/talks/kilim-google.pdf
http://www.slideshare.net/VaclavPech/concurrency-on-the-jvm

Actor Frameworks for the JVM Platform: A Comparative Analysis
http://osl.cs.uiuc.edu/docs/pppj09/paper.pdf
一年前なのにもう古くなってるんだよな。

Actorの共有資源に対する制御はどうしてるの？

Javaと比較すると意外にコード量も実行速度も変わらないみたいだな
http://shootout.alioth.debian.org/u64q/scala.php

コード量は若干少なくなるけど、実行速度は若干遅くなるって所か

Javaと比べてコード量が変わらないっておかしくね？
計算アルゴリズム書くだけのベンチ？

そんなにおかしくもないだろ別に

入門書なんかは決定的にコードが減るパターンをセンセーショナルに取り上げてたりするからねぇ。
実際は書き方が変わるだけで、一つ一つのロジックレベルでは、
決定的にコード量が減るってもんでも無いと思う。
小さな積み重ねをすると、総合的に目に見えて分量が減るのは確かだけど。

一般論としては、数値計算系のベンチマークだとあまり言語による
コード量の差が出にくい。つーのは、よく知られたアルゴリズムが
既存の手続き型言語用のものだったりするので、それをベタ移植しても
あまりコード量が変わらないという…。あと、あまり数値計算系で
扱うデータ構造ってあまり複雑じゃないんで、高階関数とかの出番が
少ないんだよな…。一方、コンパイラとか言語処理系みたいな、複雑な
データ構造をいじりいまわすプログラムだと滅茶苦茶差が出る。

あと、shootoutのプログラムコード見るとわかるんだけど、全然Scala
っぽくなくて、ほとんどJavaみたいなコードが結構ある。Javaっぽい
書き方した場合、型宣言＋αくらいしかコード量が減らない代わりに
実行速度もほとんど変わらないから、まあ納得の結果だなあと。

普段はScalaが遅いとは感じないけど
Eclipseでデバッグ実行すると異様に重く感じる。

そりゃ普段は遅くは感じないと思うよ
単に素のJavaの方が速いってだけの話で

>>41
単にEclipseのScalaプラグインが重いとかその辺りだろう

>>42
なんでそうなる？
scalacがコンパイルしたコードを逆アセンブル or 逆コンパイル
してみりゃわかるが、原理的にほぼjavaと同等の速度が出るようになってるよ
Javaの方が速いってのは単なる先入観だ

違いが出るのは、暗黙型変換使いまくったり、高階関数使い
まくったりした場合だな。特に2.7だとspecializationが無いせいで
プリミティブ型のboxingでアロケーションが多発するので遅くなる。

要するに違いが出るんだろ

>>44
書き方に依存するって言ってる。
基本的にはJVMの上で動く以上、Javaと同じように書けば、同じような速度が出るし、実際そのようなコード
は書ける。Scalaっぽいコードっつうか、関数型プログラミングスタイルで書いた場合は、JVMの上だとどうしても
パフォーマンスが劣る傾向があるので、性能と簡潔さをトレードする感じになる。でまあ、もちろん0か1かの二択
じゃなくて、基本的には関数型で書きつつ、チューンしたい部分をJavaっぽく書くとかそういうこともできるわけ

やっぱ関数型的に綺麗に書くと遅くなるもんなのか

JVM上で動いてかつJavaとの互換性を高いレベルに保つってことで
一般の関数型言語ではやれる最適化手法の一部は使えなかったりするだろうし

>>45
要するに素のJavaの実行速度は超えることが出来ないんだからJavaよりは遅いで間違ってないだろ

>>48
え？
Javaと同じかそれより遅い、なら真だけど
Javaよりは遅い、は偽でしょ
Javaの速度≧Scalaの速度(実はこれも語弊があるけど。
JavaでScalaみたいに関数型プログラミングをやると同様に遅くなるはず
なので) ⇒ Javaの速度＞Scalaの速度
って意味不明だろ

厳密に言うとJavaと等価にはなりえんだろう。

>>50
等価ってのが何を意味するかにもよるが
Javaっぽく、というか副作用を駆使すればJavaと同じ(これは
*誇張ではなく*ほぼ同じ)速度が出るって点には納得してもらえてる？
もしそうなら、Javaより遅いってのは論理的に明らかにおかしいのが
わかると思うのだけど…。

ほぼ同じ＝同じ
ではないんじゃね？

Scalaを好意的に見たいってのは解るんだけど、
現実を見ると、どんだけ厳密に最適化したところで、最高はJavaと等価が限界で、
Javaの実行速度を越えることはできなんだし、
Javaと同じ速度が出る場面なんて殆ど無いんだから、
Javaと同じ速度が出るって公言していい訳じゃないと思う。

今時、言語の速度だけ語ってもしゃーなくない？

Javaより生産性が高くて、Javaに近い実行速度ができて、
生産性の高さのメリットがその実行速度の差のデメリットを埋めることができればいい、くらいで

ま、そんなの用途や既存や手持ちのライブラリにもよるんだけど、
Ruby(Rails)が一部で使われているのはそういうのが理由でしょ。
でないと、あんな動作速度でいえば最悪級(失礼)な言語誰もつかわないでしょ。


どうでもいいが、JRubyなんてさ実行速度はRuby並だわ、
起動の遅さはJava並、動かないRubyのライブラリあるわ散々でまさに誰得言語だと思わんかね・・・

その点、Scalaはいい線だと思う

>>52
「ほぼ同じ」ってのが、「ちょっと負けてるけど、比較できるくらい速い」
というニュアンスで受け取られたんだったら、それは俺の書き方が悪かった
「ほぼ同じ」っていったのは、Javaっぽく書いた場合でも、scalacが完全に
javacと同じバイトコード出すわけじゃない(命令列の配置が少し違う)から、
厳密な書き方しただけで、実用上は「同じ速度」と言ってもいい。

>>53
いやいや、まだ理解されてないのかもだけど、わざわざ頑張って
しなくても、Javaっぽいスタイルで書くだけでJavaと同じ速度出るんだってば
で、現実にJavaと同じ実行速度が出る場面なんてほとんど無いとか、測定
したことも無い(だろうと思われる)のになんで語れる？
実測値示してみせりゃ納得するのだろうか？
好意的に見たいとかそういう問題じゃなくて、単純に事実の話だよ

つーか、Scalaの速度について、Javaより遅いけど頑張って最適化すれば
Javaに近いくらいの速度が出るくらいの受け取り方する人って意外に多い
ことに驚いた。

たとえば、今Java 7に入る入らないでもめてるクロージャあるよね。
あれ多用したコードの性能は、ほとんど間違いなくScalaで高階関数を
多用したときと同じように落ちると思われるんだが、そうなったとき、
Java 7以前の速度は、Java 7よりも速いと言うのは正しいの？
自分が言っているのはそういうレベルの話。

ふつーにループ構文(whileとか)とJavaのAPI使って書けば性能はJavaと
同じだし、Scalaっぽく書けばより遅くなるというだけの話なんだけどなあ。
もちろん、Scalaがややこしい作業を色々肩代わりしてくれるおかげで、
つい、Javaよりも気楽に遅いコードを書いちゃうというのはあるんだけど、
それって言語処理系の速度評価とは独立な問題だよね

なんで全てのパターン試してきたら同じ速度出たのを検証したみたいな断言するのか解らん
そんな簡単に最適化できるわけでもなかろうに

同等可否レベルのパフォーマンスの話はバイトコードで語れっての。

普通にScalaっぽく書いたら速度差出るなら、
それは等速とは言わないよね。
Javaっぽく書いて最適化すれば等速出るって言われても、
もはやそれはJavaじゃん。

>>57
いや、全パターン試すまでもわかることもある。

Scalaのwhile --> ジャンプ文(goto,ifeqなど)
Scalaのif --> 条件分岐命令(if_icmpeq,ifeqなど)
Scalaのmatch --> 対象が整数でcaseの値が定数の場合はlookupswitchなど専用命令を使用。
　　　　　　　　それ以外の場合、if(...) ... else if(...) ...相当のコードを吐く。
Scalaのtry-catch --> メソッドの例外テーブルに情報を書き込む(Javaと同じ)
Scalaのthrow --> athrow命令
Scalaのメソッド呼び出し --> 単なるメソッド呼び出し命令(invokevirtual,invokestaticなど)
Scalaのオブジェクトの生成 --> new+invokespecial
Scalaのプリミティブ型(AnyVal)のメソッド呼び出し --> JVMのプリミティブ型に対する演算命令(iadd,imulなど)
Scalaの配列に対する演算 --> JVMの配列型に対する演算命令 --> (aaloadなど)
Scalaのclass,trait --> JVMのクラスファイル (ただし、traitが実装を持っている場合除く)
…

全部列挙するのは面倒なので避けるけど、こんな調子で、基本的にJavaと同じ
ような演算は同じ命令にマップされるので、Javaと同じように書いた場合には、
同じような速度が出る(いくつか例外はあるが…)。これは憶測じゃなくて、
自分で今までに色々なコードパターンに対してscalacした結果を逆アセンブル
した結果。別にユーザが「最適化」とか考える必要は基本的にはなく、単に
Scalaの暗黙型変換とか高階関数とか多用しなければ同じくらいの速度が出る
ようになってる。

ちなみに、こちらの方がまだ検証してなくて憶測になるのだけど、2.8.0.RC2
以降でジェネリクス使ったコードだと、specializeアノテーションでboxingの
コストが減らせる分、Scalaの方が速くなるケースもあるかも。

>>59
事実関係についてはおおむね同意してもらえたとして、そこまで来ると
もはや見解の相違としか。一応言っておくと、ScalaでJavaっぽく書くことは
特に努力が必要な作業でもないよ。ふつーにScalaの基本構文を使って書く
だけ。暗黙型変換使うなとか使う機能に関して縛りは出るけど、特にScalaを
熟知していないとできない作業でもない。

ただまあ、

・Javaっぽく書くこと自体は特に難しくないこと
・そのようにして書かれたコードはJavaと同等の速度が出ること

に納得してもらえたなら、それ以上、特に等速という言葉を使うことに
こだわりは無い。単に、「性能の上限はJavaと同じくらいだけど、それを
達成するためには頑張ってチューンしなければならない」みたいな認識が
広まるのが嫌なだけなので。

リスト+mapやforを使ったコードもただのループになったりすればいいのに。

>>61
いやだからそれってもはやJavaじゃん

>>63
そうとも言えない。
・型推論があるおかげで型を書く必要がある箇所がJavaに比べてかなり減る
・型の別名付けがあるおかげで、ジェネリクスを使ったコードがJavaに
比べて楽に書ける
・case classなどのおかげで、クラスの作成がJavaに比べて楽
・どこでもimport
・末尾再帰の最適化
・メソッド内メソッド
・パターンマッチ

などなど。これらの性能にあまり影響しない特徴を使うだけでも、
コードを書くのはJavaに比べて楽だよ。

んでそれで書くと等速になるって実際に確かめたの？

>>62
ただのループに変換するにはクラスを合成する必要があるから
クラス単位でコンパイルするScalaコンパイラでは難しいでしょうね。

Javaにクロージャが追加されたらJVMがクロージャを
ただのループに最適化するようになるかもしれません。
そうなればScalaの高階関数も同様に最適化されるだろうから
Scalaっぽく書いたScalaコードもJavaっぽく書いた場合と
同等の速度がでるようになると考えられます。
Javaにクロージャが追加されるのを期待しましょう。

>>65
>>55が何を実際に確かめたのかは>>60に書いてあるのでは？

>>65
あらゆるコードで、とは言わないけど、典型的なコードパターン
では結構試したかな。つか、さっきも書いたけど、Java的なコードは
Java的にコンパイルされるので、全部確かめる必要も無い。

あとは、>>36のリンク先の、regex-dna,n-body,binary-trees,fannkuch-redux
辺りのコードが参考になるかな。 Javaと同じような書き方してる
ベンチマークはほとんど同じ結果になってる。ちなみに、大きく差が出てる
k-nucleotideなんかはJava版とScala版でやり方が大きく異なってる点に注意ね。

机上の空論で議論しても仕方ない。
殆ど同じ、じゃなくて完全に同じかどうか聞かれてるんでしょ？

みんなtwitterのクジラは見たくないんだよ

全か無かでしか思考出来ないのは、認知のゆがみの典型的パターン。

>>68
んな自明なこと聞かれてたの？
完全に同じなんてことは、scalacがjavacのforkでも無い限り(
というかforkであっても「完全に同じ」なんてことはまず無いが)
ありえないってことは議論するまでも無く明らかだと思うのだけど。

俺は実際のコードでほぼ同じであることを説明すれば十分だと考えた
ので、scalaのコードがどういうバイトコードにコンパイルされるか、
や、shootoutのコードを示したわけなんだが、あとは何があればいいの？

素のJavaよりも速いのか、遅いのか、全く同じなのか、ってことでしょ？
ちょっとでも遅いのなら、Javaと等速っていうのは過剰評価じゃね？ってことだよ
細かな速度は重要じゃないって言ってる人が、何故か一番Javaと
等速であることに拘ってるよね

>>55
実行速度に関する情報提供ありがとうございました。
大変参考になりました。

ベンチマーク的な事じゃなくて、実際に実務でどうなるのかが唯一重要な希ガス

速度なんて関係ねーよとは言いつつ、殆どの人がこだわるのが速度だからねぇ
Rubyの人を除く

さすがAKB大好きなだけありますね。

>>72
いや、だからその三択がおかしいんだってば。
「全く同じ」なんて言い方するなら、Javaと全く同じ速度が
出るのはJavaそれ自身しか現実的にありえないんだから、無意味
だよ(どんな入力に対してもjavacと「全く同じ」出力を出す
コンパイラなんて現実的に無理だし)
それと細かな速度が重要なんて一言も言ってないんだが…
単に、「Javaと全く同じ」なんて言明は無意味だからそんな
言い方はしないだけのこと。

もう一度言うけど、「Javaと等速」ってのは過剰評価でもなんでもない。
shootoutでも、Javaぽく書かれたコードは、Javaとの性能差はほとんど
誤差みたいなもので、Scalaが勝ってるベンチマークすらある。
つーか、実際にScalaでJavaっぽく書かれたコードで、Javaより有意に
遅くなるケース示してくれんと、もはや悪魔の証明を要求されてるような
もんでどうしようもないんだが…。Javaっぽくってのは、高階関数の
代わりにwhileループやvarを多用したコード程度の意味ね。

>>74
実務に関しては、答えは簡単で、典型的なScalaっぽく書かれたコードは、
典型的なJavaコードより遅い(どの程度遅いかは問題によるが)。ただ、
Scalaは静的型付け言語だけあって、それでも動的型付け系のスクリプト
言語よりは速い。あと、Scalaっぽさを捨てていいならJavaと同じ速度が
出るようにするのは難しくない。

つけくわえておくと、ほぼ同じって言葉の意図は、Javaに近いけど、ちょっと
遅い、じゃないからね。Javaっぽく書いたScalaのコードとJavaのコードの
速度差はほとんど誤差のレベルだから優劣を比較するのが難しいってこと。

そういう事じゃないのでは

だいたいJavaっていってもVMのバージョンやベンダによって全然違うわけだが
ある程度近いなら同じって言い切って構わないよ

なんか良く分からんが、
・C++は遅いから禁止。 Cで書け！
・ハードェアを叩きたかったら、既存のドライバ使うな！ドライバは自分で書け！
・OSなんか使うなよ。そんなのを介すると当然遅くなる。
・可能だったらアセンブラで書け！Cだと遅いからな。
という話と同じだな。
組み込みの分野では、未だにそういうプログラミングやるよ。

で、数年前、C++はCより速度が劣るからダメ！と拒否しまくっていた人が居た。
まさにデジャブだね。

最近は組み込みでもC++で書くことも多くなってきている。
当然、C++っぽい書き方をしまくるとCより遅くなるのだが、
速度よりも分かりやすさ優先な場合は、そういう書き方しても全然問題でない。


要するに頭を使って適材適所でプログラミングすれば、
組み込みの現場でも CとC++の速度は同等だし、かつ、C++は便利といえるんだよ。

ScalaコードをJavaにトランスコードすればいいんだよ。 javapを応用すれば出来るでしょ？

>>79
毎度毎度お前は。
twitterでつぶやいてろ。

>>81
駄目、使うな、って言ってるんじゃなくて
速度はJavaと全く同じは言い過ぎじゃね？ってだけの議論だろ

ScalaはJavaより速い！

兄よりすぐれた弟なぞ存在しねぇ!!

>>84
そりゃ二つの異なる言語処理系の性能が「全く同じ」なんて、
いかなる場合でも言えるわけが無いと何度言ったら…

とりあえず、同じような書き方した場合にベンチマークで有意な差が
出ないってのはshootoutのコードだけ見ても十分わかるし、原理的にも
「ほぼ」同じ速度が出る。で、無限にあるJavaプログラムと
Scalaプログラムの速度を比較するにあたって、同じような書き方すれば
速度が「ほぼ」同じだろう、以上の事はどうやっても言えないんだけど、
一体どうしろと言うんだ？そこまでして、Scalaの実行性能がJavaと同程度
であるってこと認めたくないわけ？Javaより少し遅いといえば満足なの？

とりあえず、反論してくる人が何を主張したいのかさっぱりわからんので
主張をまとめてもらえないか。自分の主張はシンプルで、原理的にも
実用的にも、Javaと同じような書き方(whileループやvarの利用)をした
コードはJavaとほぼ同じ速度が出る。以上、これだけ。

反論してくる人は、「全く同じ」という無意味な言葉を使わないで
主張の要点を説明してくれ。二つの異なる言語処理系の速度が「全く同じ」
なんてことはそもそもありえないし、こちらはそんな事言ってないんだから。

>>84
> 駄目、使うな、って言ってるんじゃなくて
> 速度はJavaと全く同じは言い過ぎじゃね？ってだけの議論だろ

そもそも、そんな議論はしていない。

誰が、「速度が全く同じかどうか」にこだわっているんだ？お前くらいだろ。
さっきからのその問題点のすり替えで、どうどうめぐりなので、辞めてくれるかな？


ていうか、お前、55氏の書いている内容を理解してないだろ？
これ以上愚問を繰り返すならば、せめて >60 の意味が分かってからにしようよ。

速度はJavaと全く同じは言い過ぎってのは間違いじゃないだろうに。

お前ら仲良くしろ
結局の所、>>33-36の結果を覆さないと堂々巡りになるんじゃないかね。
散々俺たちだってベンチマークの結果出して、RubyやPythonおせえｗｗｗって言ってきたわけだし

>>91
OK。>>33-36のベンチマークで、トータルでScalaの方が遅い理由については
説明つけられるので、ちょっと書いてみる。とりあえず、以下では、
>>36のベンチマークを基準にして話を進めるね。

まず、regex-dna,reverse-complement,n-body,fannkuch-redux,
binary-treesはほとんど有意な差が出てない(Scalaが勝ってる
ベンチすらある始末)のでまず除外。

残りは、spectral-norm,mandelbrot,fasta,k-nucleotideの４つなので
順番に検討していく。

>>90
> 速度はJavaと全く同じは言い過ぎってのは間違いじゃないだろうに。

君の主張は詭弁だらけだな。

とりあえず、
「全く同じ」 「言い過ぎ」 「間違いじゃない」
って言葉を使うのは辞めておけ。


で、もう一度、スレを読み直してごらん？君は、いったい何を言いたいの？

>>90
誰もそんなこと言ってねーって。
JavaとかScalaの前に日本語勉強した方がいいよ。

まず、spectral-normだけど、これは差は比較的小さいけど、少しScalaが
遅い。いくつか原因はあると思うけど、たぶん、Scala版は
for(i <- ...) で、foreach、つまり高階関数を多用しているのに対して、
Java版は普通のループ構文を使ってる。それ以外大きな違いが無いので、
この辺りが原因になってると思われる。

次に、mandelbrotだけど、これはアルゴリズム部分はScala版もJava
っぽく書かれてるけど、スレッドがらみで、Java版はAtomicInteger
使ってるところを、Scala版はsynchronziedやnotifyを使うなど、
より効率が悪くなる書き方してる。

次、fastaだけど、これはプログラムの書き方が結構違っちゃってる
ので比較が難しい。実際にfastaのJava版をベタ移植してみるのが
手っ取り早そうだけど、めんどいな。ここはとりあえずpendingという
ことで。

最後に、k-nucleotide、これは、Scala版はActor使ってる一方で、Java版
はjava.util.concurrent駆使してるしで、完全に別物と言っていいくらい
組み方が違ってるので、処理系の速度比較としてはかなりアンフェア。
これも、Scala版でJavaと同じようにutil.concurrent使った場合と比較
しないとまともな比較にはならんだろう。

まあ、はっきりしないやつについても、Java版のコードを全部Scalaに
ベタ移植してみればはっきりするんだけど、そこまで手間かけるのも
面倒なので、誰か気が向いた人がやってくれれば。

コードはざっとしか読んでないので、ゆっくり読めばもうちょいまともな
分析ができるだろうけど、とりあえず、Java版とScala版で差が出てる
ベンチはコードの書き方がそれなりに違ってるという事は確か。

55のレスの合間って不自然に口汚い援護射撃入るよな。
55がいない時間には入らないのに。

煽ってる奴もマジレスしてる奴も、意見の辻褄がおかしくなってるから
もういい加減落ち着いて辞めた方が双方のためだと思う。

jvm上のシステムはgcがどんだけ使われるかによってスピードがきまる。
言語ではない。

それはない

このスレ一番のトンデモ理論出ました

gcが使われると遅くなるだろ
どこが、とんでもなんだ？

>>99
お前はtwitter かはてぶしてろ

>>96
あーあ、言っちゃったｗ

>>96
話の筋を理解しないレスに突っ込みたい人は何人もいるでしょう。
私も突っ込みましたが私は>>55なんですか？

>>55
同じ内容を繰り返しているレスはスルーしてくれませんか？
不毛なやりとりでScalaスレが埋まるのはうれしくありません。

>>104
スルースキルが低くて申し訳ない。納得いかないとつい書いてしまう性質
なもので。確かにどうどう巡りになってて、不毛だったかも。

長島雄一郎入っちゃった

>>104
> 話の筋を理解しないレスに突っ込みたい人は何人もいるでしょう。
> 私も突っ込みましたが私は>>55なんですか？

俺も、問題点をすり替えて、何度も同じ主張をするやつに文句言ったが、
別に、66でも、55でもないぞ。

他にも、コイツにツッコミ入れたやつは、あと4人くらい居るみたいだ。

なんで急に弁解しだしたんだ。

疑われたからだろ。

大嶽親方「今は言えない。時が来たら話す。」

とりあえず、「全く同じは言い過ぎってのは間違いじゃない」という発言のアホさに
ようやく気付いたみたいだから、彼も進歩したようだ。

でも、複数の人からアホ認定されているのは認めたくないようで、
現実から逃げて自作自演とかって騒いでいるから、まだまだアホのままだな。

>79, >90 のその後の発言は、>106, >108 ,>109 , >103, >96 , >99 なのだが、
アホの発言ってアホ丸出しだから本当分かりやすいよなあ。

2chでは行間開ける人はまずいないことを、
こうなる前に早めに教えてあげるべきだったろうか。

ダブルスペースで書く奴はいないけど、
話の区切りに行間を開ける奴はいるだろ。

てか、同一人物認定したところで、アホがアホである事実は変わらない。

話の区切りが必要な長文書くヤツもまずいないって教えてあげなきゃだな

そりゃ、ニュース系の話だろ。

2ちゃんねるといえばニュース系しかないと思ってる頭の弱い人もいるってことだよw

・俺の意見ではない。みんなが言っているんだ。
・自分を批判するレスを全て妄想のイコールで結び始める。

>>112
マジレスすると、むしろもうちょっと早い段階で皆スルーすべきだった
>>77 あたりで

この人もしかしてあの入門の人じゃね

それ指摘したらヤバいだろ。

この流れを見るまでにscalaとjavaの速度差が気になるって人が
いることに思いがよらなかったよ。

スクリプト言語よりは遙かに速いんだし
Scalaで物足りないときはCでカリカリ書くものだと思ったよ

なんだか悪い意味で盛り上がるきっかけになってしまって申し訳ない…
とりあえず、55以降のレスは全て名前欄に55つけてるので、(なんだか
疑いをもたれてる書き込みについて)同一人物ではないとだけ言っておく。
信じてもらえるかはわからんけど。

気にしてるんじゃなくて、
JavaがScalaに勝ってる箇所って無いに等しい
って話が出て来て、速度は多少劣っているのではって話になって
そんなことは絶対にないって荒れ始めたのでは。

まさにcとcppの差だね
一番の弱点はjavaライブラリを使うときに色々気を使う必要があることじゃね

色々って何だ？

Option[T]を前提にできないとか、
Tupleが帰ってこないから、参照渡ししないといけないとか

ttp://d.hatena.ne.jp/kwatch/20100618/1276818038
これってこのスレに関係ある話？

Scalaの話なのこれ？

>>127
このスレには関係ないと思います。
そこのblog主は言語処理系の速度とアプリケーションの速度は関係ないと主張しています。
スクリプト言語処理系が遅いからと言ってアプリも遅くなるとは言えないと言いたいのでしょう。
このスレはScala言語処理系はJavaと比べて遅くないという話で盛り上がりました。
どちらも実行速度の話ですが論点が違います。

>>122

このグダグダの中でも、>>60 のような非常に参考になる資料が書き込みされて良かったです。

しかし、これってどうやって調べられたのだろうか？
javapで 逆アセンブルだろうか？

気になるルーチンは逆アセンブルすることで、scalaｃがどのようにコードを変換したか分かって面白そうですね。

>>130

はい。javapで片っ端から逆アセンブルです。逆コンパイルもありなのですけど、対応する命令や
クラスファイルの構造を正確に調べたい場合には不向きなんですよね…。ただ、逆コンパイルでも、
おおまかにどのようにscalacがコードをコンパイルしているかはわかるので、バイトコードは
よくわからないって人は逆コンパイラ使ってみると良いかもです。

水島氏は自演疑惑にも負けず、晒しエントリーにも負けず、これからも素直なままでいてほしいものである

>>55あらため、みずしまです。トリップのキーをうっかり忘れてしまったので、別のトリップで。
>>132
素で>>55 = みずしまである事がばれたのにちょっと驚き。いや、別にあえて隠してたわけじゃないんだけど、
以前使ってたトリップのキー忘れてしまったので、コテをやめてただけなんですが。まあ、文体とか見れば
わかるのかなあ…。見抜いた>>132氏はよくわかったなあ。

あー、やっぱりそうだったの？
なんとなくそんな感じはしてた。

次はRC6かなぁ・・・finalはいつ？

http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_RC6

JVM上の言語に早いも遅いもあるかボケども
命令が丸見えなんだから書き直せ！

なんか酷い感じになって来たな…
もうやめようよ

まだRC3のままだったけどRC6まで来てたのか
finalﾏﾀﾞｰ？ﾁﾝﾁﾝ

clojureにはRCなんぞないズラ...たしか

Planet Scala、火曜日で止まってるけどそういうもんだっけ？

blog以外も集めてるよな？
そして、手動じゃ無いよな？

>>140
> PlanetScala's crontab has apparently
> broken orbit and departed for deep
> space.
twitterから
やっぱり止まってたみたい、自分の早とちりじゃなければ…

そして、Planet Scala 軌道回復のお知らせ

質問です
関数funcで2つめの引数がオプションだったとするとオーバーロードを使って
def func(i: Int, s: String)
def func(i: Int)
みたいに書けますけど

2.8だとデフォルト引数とオプション型を使って
def func(i: Int, s: Option[String] = None)
みたいにも書けますよね

どっちがいいと思いますかね？

>>143
互換性を考えるならオーバーロード。

互換性を考えないなら、s を取るか取らないかによって、
実装が大きく変わる => オーバーロード
あまり変わらない => デフォルト引数

じゃあなかろうか。

>>143
二つ目のfuncの意味がどうなるかが問題じゃないかな
二つ目のfuncで、実際には単にデフォルト値を与えて(たとえば"")、一つ目のfuncを
呼び出しているだけなら、

def fun(i: Int, s: String = "")

みたいにした方がいいと思う。

一方、意味的に両者が大きく異なるなら、オーバーロードを使うべきだと思う。

RC6でたぉ〜

http://www.scala-lang.org/node/6743

ワシのRCは百八式まであるぞ

ふむ、たしかにfuncの例じゃあ意味的にどうとか全くわかんないけど
思い付かないからしょうもない例だけどたとえば
class Person(name:String, age:Int, child:Option[Person]=None)
とかなら問題ない感じかな？

自分はなんかクラアント側の使い勝手はどうなのかなぁみたいなことばっかり考えてた
デフォルト引数バージョンのはただ呼び出すだけならSomeでラップしなきゃダメでちょっとうざい
val x = func(10, Some("a"))

でもクライアント側から呼び分けたい場合はオーバーロードバージョンのはメンドイな
val s: Option[String] = ...
val x = s match {
case None => func(10)
case Some(s) => func(10, s)
}

こっちならそのまま渡せるな〜
val s: Option[String] = ...
val x = func(10,s)

みたいな感じで

yuroyoroさんがオプショナルな引数はカリー化して定義するのが2.8のAPIの流儀とつぶやいておられる
def func(i: Int)(s: Option[String] = None)

>>148
どうやら、
＞ オプショナルな引数はカリー化して定義するのが2.8のAPIの流儀に見える。
＞ def func( i:Int )( s:Option[String] = None)
て、○○家の祖母がいってた。

orz

なんか勝った！

しかし、これ、なんか違和感があるなあ
どういう意図があるんだろ

うーむ、それじゃあ呼び出すときに
func(10)()
みたいにする必要があるみたいだ
implicitが抜けてる気がする
def func(i: Int)(implicit s: Option[String] = None)
でも俺の脳じゃどういう利点があるのかはよく分からないな

>153
利点は、シグネチャがどんどん複雑になって、Java厨にはったりをかませるとこ。

そういうのいらない

あんまりそういうのは関数原理主義者みたいで気が乗らないなぁ

ループを再帰に書き換えるのもそう思う。

むしろ、これは関数型的なセンスではないよね
カリー化しておいて部分適用で使うわけじゃないんだから
Scala流ってことなんだろうなあ

>>157
Scalaのカリー化って他の関数型言語のカリー化とだいぶ意義が違うんだよねえ
部分適用したいだけなら、 _ 構文使えばいいだけだし、カリー化とかする意味が無い
どちらかというと、implicit parameter使うためとか、function typeの型推論するためって
のが大きい。function typeの型推論するためってのはどういうことかというと、

def map[A, B](list: List[A], f: A => B) = list.map(f)
map(List(1, 2, 3), x => x + 1)

だと、

error: missing parameter type
map(List(1, 2, 3), x => x + 1)

になってしまうけど、カリー化して、

def map[A, B](list: List[A])(f: A => B) = list.map(f)
map(List(1, 2, 3))(x => x + 1)

だとOKとか。

>>158
正直それダサいと思うんだけど
関数リテラルの型推論ってよくわかんない
んだよね
怒られたら型を書くようにしてるけど、
なんで失敗するのかわからないと気持ち悪い

>>159
まず、前提として、Scalaは、(...)という引数リスト(確かこういうのを言語仕様ではセクションと言ってた)単位で
「前から順番に」型推論をしている、というのがある。たとえば、カリー化された
def map[A, B](list: List[A])(f: A => B) = list.map(f)
の場合、先に
(list: List[A])
の部分に関する推論が行われて、それから
(f: A => B)
の部分に関する推論が
行われる、といった具合。で、関数リテラルに関する型推論規則は実は簡単で、関数リテラルの
パラメータ部分(x => x + 1だったら、xの部分)の型が、関数リテラルの型を推論するまでに確定していないといけない。
で、
def map[A, B](list: List[A])(f: A => B) = list.map(f)
だと、先に(list: List[A])で、Aの型がたとえばIntとか推論された後に、(f: A => B)の部分の型推論が行われるので、 A = Int
とわかるけど、
def map[A, B](list: List[A], f: A => B) = list.map(f)
だと、list: List[A]の部分とf: A => Bの部分の推論は「同時に」(という表現が適切かどうかは微妙なところだけど)行われる
ために、関数リテラルの型推論をする時点で、関数リテラルの引数の型が確定してないので、エラーになる。

ちなみに、「前から順番に」ってのは、言語仕様書でそのように明示されてるわけじゃないんだけど、引数リスト単位で
型推論が行われてるってのはほぼ確実だと思う。

なるほど、括弧を分けることで、先に型をバインドさせるわけね
ダサいという印象は拭えないが、
でも、テクニックとして、型パラメータを使って関数を引数にとる場合は、
カリー化させて関数の引数を後ろに回したほうがいいということはわかった
実際、foldLeftなんかもそうなっていると
しかし、結局これは関数の引数を常に分けるようになるよな
またRubyっぽい雰囲気になるな

>>161
ダサいというのは自分も同意。たぶん、もうちょっと頑張って推論すれば>>160の前者のような場合でもうまく
推論できそうだし。ただ、そうすると、推論できない場合とできる場合の境界がよりわかりにくくなるって
デメリットもあるといえばある。
現在の関数リテラルの型推論規則は割と簡単なので仕組みさえわかってしまえばそこそこ理解しやすいんだけど、
頑張って推論した場合の規則はかなり複雑怪奇なものになりそうな気がする
完全な型推論ができればいいんだけど、Scalaの型システムだと原理的に無理があるし…

今からでも遅くない これから始めるScala（前編）
ttp://codezine.jp/article/detail/5193

Hello worldがコンパイルエラーになる解説記事を見たのは久しぶりだ。

codezineか

とりあえずyuroyoroさんが日本語キーボードを使っているということはわかりました

なおったみたいだね

Mission Complete !! ですって？
←も使えるぐらいだから、全角スペースも認識する。とかはなかったか。
ソースファイルのほうは日付古いままだったけど、試したら問題なく動いたよ。

codezineの記事、修正しました。ご指摘有り難うございます。
恥ずかしくて体中の穴という穴から汁があふれそうになりました。

昨日は規制中で書き込めなかったので。

codezineって、どういうノリで記事が決まるの？
編集部が「今はScalaが売れる！」って感じで企画立ててるの？

ScalaとSpring：両世界のベストを一体化
http://www.infoq.com/jp/articles/scala_and_spring

scalaはC#のイベントみたいな言語が標準で提供してるObserver パターンのやつはないの？

>>171
言語レベルでというのは無い
でも、C#のeventのほとんどの機能はライブラリレベルで十分エミュレートできそうな気がするけど
どうなんだろう

「はじめてのScala」 っていう本を本屋でちらりと見た。
http://www.kohgakusha.co.jp/books/detail/978-4-7775-1510-3

前半は、「はじめての〜」という内容で、飽き飽きした内容かもしれないけど、
後半2/3くらいが、「Rails風データベース・アプリケーション」 で、
XMLファイルの読み書きなど。

著者は、主婦らしい。


だれか、買った人いる？

ボクらのScala ~ 次世代Java徹底入門 浅海 智晴
本屋で売っていたのでパラパラ見てみた。
まったくの初心者向けとしては悪い本では無いと思うが
それ以外の人はコップ本を読んだほうがいいと思った

>>173のは作りながらみたいなよくある入門書だけど
>>174のはコップやScalaプログラミング入門の劣化版でしかなくてかなりどうでもいい感じだと思う

やさしいなんちゃらの二の舞になりそうだな

主婦頑張ってるな

主婦はわりかし有名で評判がいい
工学社のシリーズが地味すぎてマイナーだけども

Scalaの本、増えすぎだろ
仕事で使ってるやつはどんだけいるんだよ

増えたらなんか問題あるのか

馬鹿向けのScala本たくさん出して
そんなに需要あるのか？

プログラム初心者が一番最初の言語としてどマイナーなscalaを選ぶケースは
ほとんど無いから実際は入門書はいらない。いきなりコップ本を読めばいい

コップ本の内容が難しくて理解できないならばscalaを学ぶための
周辺知識が欠けていると思われるのでscalaの入門書でなく
javaや関数型プログラミングの本を読んで基礎を固めたほうがいい

確かに他言語の経験がある人の独学はコップ本で良いですね。
でも前提知識を要求するコップ本は教科書には向いていません。
ボクらのScalaはScala教科書の定番になると予想します。

俺は一番難しい本が理解できる
それが解らない奴はバカ

こういうアドバイスはいらない

翻訳が理解できない本が素晴らしいとか本末転倒してるよな
翻訳自体は、その本の価値をがんばっても保つくらいにしかできず、普通は減ずるというのに

入門書たたいてる奴は、入門書がないからいつまでたっても玄人向けのマイナー言語だという発想はないんだろうか。

>>185
日本語で

素人向けにするにはまだちょっと早いと思う

そうやって言い訳して排除排除かね

結局足の引っ張り合いなんだよな、日本人は

じゃあ、今度ニュー速にプログラミング入門スレが立ったら、
「スカラっていうのが簡単でVBよりもいいらしいよ！」とか
しれっと書いてくる！

はいはい
ワッフルワッフル

むしろコップ本より詳しい本を誰か書いてくれ

言いだしっぺの法則

いや、2.8用コップ本が先だろ。

そいやオライリー・ジャパンからはscala本まだ出てねーんだな

オライリーは偏ってるから
PHPやPostgreSQLなんかも日本語のはずっと出なかった

オライリーは表紙に悪意を込めたりするねｗ

個人的には、ScalaでDSLとか簡易言語を実現するような本が欲しい。

すいません、質問させてください。

http://pomu0325.blogspot.com/2010/04/scalagae-dispatchoauthgae.html
ここのコードをそのままコンパイルしようとすると
URL型が見つからないと言われたので
import java.net.URL
を追加したものをコンパイルしてみたのですが、

[ERROR] src/main/scala/demo/model/TwitterOauth.scala:20: error: type mismatch;
[INFO] found : dispatch.Request
[INFO] required: java.lang.String
[INFO] Note: implicit method dispatch2gae is not applicable here
[INFO] because it comes after the application point and it lacks an explicit result type
[INFO] val g = new HTTPRequest(new URL(r), if (isPost) HTTPMethod.POST else HTTPMethod.GET, FetchOptions.Builder.withDeadline(10))
[INFO] ^
[ERROR] src/main/scala/demo/model/TwitterOauth.scala:21: error: type mismatch;
[INFO] found : org.apache.http.Header
[INFO] required: com.google.appengine.api.urlfetch.HTTPHeader
[INFO] Note: implicit method dispatch2gae is not applicable here
[INFO] because it comes after the application point and it lacks an explicit result type
[INFO] r.req.getAllHeaders.foreach(h => {g.addHeader(h); println(h)})
[INFO]

のようなエラーが出てしまってコンパイルできませんでした。

色々いじってみたのですが解決せず・・もし分かる方いらっしゃったら
ご教示いただけないでしょうか。
お願いします＞＜

ttp://stackoverflow.com/questions/2731185/why-does-this-explicit-call-of-a-scala-method-allow-it-to-be-implicitly-resolved

>>200
201のurlにも書かれてますが、implicit defで戻り値の型明示するか、implicit defを宣言しているobjectのimportを後で書けばよいようです。

>>200
すみません…　dispatch.Request -> Stringにするimplicit defを他で書いていたのですが、それも必要でした。blog直しておきます…。

/**
* convert dispatch.Request -> String
*/
implicit def r2s(r: Request) = {
r.host.get + r.req.getRequestLine.getUri
}

org.apache.http.Header -> com.google.appengine.api.urlfetch.HTTPHeader
するimplicitも要りそう。

implicit 使う奴って、保守性とか考えてんの？

>>205
保守性を考えないのが、関数型プログラミングだ

んだよねー
俺もScala勉強し始めてから気がついたわ
Perl並だってのに
まぁ昔ちょっとSchemeやってたんだけどそんな長いの書いたこと無かったし

そんな事言い始めてもどうしようもないだろ。スクリプト言語なら型が動的に変わるのが当たり前なんだから。だからって、それがダメてわけじゃない。

誰もスクリプト言語とか動的とかの話してないけど
関数型言語の保守性が悪いってだけの話で

>>206
>>209

なんで関数型だと保守性悪い(悪くなる)の？
最初205でimplicitと使うやつは保守性考えているのか？って言う話だったのに。
議論が全く見えてこないんだが・・・。implicitと関数型の関係は？

問題点が混ざってる気がする

１．implicit conversionを多用したコードは保守性が悪い
２．implicit parameterを多用したコードは保守性が悪い
３．関数型で書いたコードは保守性が悪い

これらはそれぞれ独立してる問題で、１または２が真だったとしても、３が真だということにはならない

ってのを踏まえた上で根拠を省いて私見を述べるなら、１．については、implicit conversionを、特にメソッドの追加目的で使う場合は、
その事をわかりやすい形でドキュメントに書かないと保守性が下がる傾向はある。Twitterのコーディング規約で基本的に
implicit conversion禁止なのはそういう事を考慮してだと思う。２．については、implicit parameter
はimplicit conversionよりは害は少ないけど、2.8のコレクションライブラリみたいにトリッキーな事やる場合は、
implicit parameterの型とそれに対応する実際の型の対応関係など、やはり十分なドキュメントが必要。３．については
関数型で書いた方が保守性は高い傾向があると思う。特に、mutableなオブジェクトが共有される事について悩まなくて
済むのは大きい。

いや、関数型の保守性はいいとは言えんだろ流石に。
Perlよかマシだけど。

>>211
2.8のコレクションライブラリみたいにトリッキーな事

あれは一体どうなっているんだ？
ある程度ソースコード追ってみたけど理解出来ない・・・org
別に使う分には全部理解する必要もないのか？

implicitを多用してDSLっぽく使えるライブラリがあるとして
そのライブラリ自体のコードの保守性はさがるけど
そのライブラリを使用して書かれたコードは読みやすかったりして保守性が上がったりするんでそ？

関数型だから保守性がいいというのは妄想
規約がなければどの言語でもほぼ同じ

>>212
その辺の議論をすると話が長くなりそうだけど、関数型で書くことで、手続き型(OO言語服務)言語においてしばしば見られる
悪いコーディング方法(たとえば、mutableなオブジェクトを安易に複数のモジュールで共有するなど)を排除できる、という
のは、それだけでも十分価値があると思う。あと、プログラミング手法の話をしてるのにPerlという特定の言語名を例に出すのは
変じゃないかな？

もちろん、関数型で書いたらそれだけで良いコーディングができるなんて楽観的には考えてないけど、少なくとも(手続き型に
比べて)より良いプラクティスを提供してくれると思う。

>>213
おっしゃる通り、使う分には全部理解する必要は無い。で、あれをちゃんと理解しようと思うと少し面倒なんだけど、
あれがやっている事をかなり単純化したサンプルコードを以前作ってみた
http://gist.github.com/408693
ので、よければ参考にしてくださいな。ポイントは、引数の型(READ or WRITE or READ_WRITE,
CHARS or BYTES)によって、返り値の型(Reader,Writer,RandomAccessFile,InputStream,OutputStream)
が変化している(オーバーロードされている)点で、これは2.8で拡張された、implicit parameterの推論ルールに
基づいている。

>>214
DSLのセマンティクスがきちんと文章化されていれば、そういう可能性はもちろんあると思う。

>>215
言語というよりプログラミングパラダイムの話をしているつもりだったんだけど、違うのかな？言語の話を
しているのだったら、関数型言語だから保守性がいいってのは確かに妄想だと思う。でも、どの言語でも
同じってのは極論に過ぎるだろう。

関数型というかクロージャを多用した他人のコードは読みにくく感じる
名前が不足してるせいだと思ってる

>>215
規約があろうとなかろうと、
Prologの方がCOBOLよりは保守性はいいよ。

implicit conversionでドキュメント化されてないから訳分からんと言えば、
Liftの事ですな。

そこでCOBOL持ってくるのがなんというか

プログラム仕様書がない昨今、可読性が保守性を作用するという前提で、
関数言語の特徴である、構文拡張みたいな事を頻繁にされると、読みにくいのではと、
軽い気持ちでかいてしまいました。
すいませんでした。

>>221
関数型言語で(具象)構文拡張の機能を標準で持ってるのなんてごく一部だよ
そこそこ名前が知られてる言語の中だと
OCaml(Camlp4),Common Lisp(リーダーマクロ等)くらい？
Template Haskellは標準で持ってるかというと微妙か。あと、Common Lispを関数型言語扱いしていいのかはわからん。
いずれにしても関数型言語の特徴とは言えないのは確か。

で、関数型プログラミングの特徴はというと、色々意見はあるだろうけど、最大公約数的には
不変データ構造と高階関数を多用したプログラミングスタイル、というところだと思う。で、どちらもよほど
変な使い方しなければ可読性は下がらないというかむしろ上がると思うんだけどなあ。

関数型プログラミングの威力をみよ！

flip (.) h . ((.) . (f . g))

メンテナンス性わりー

>>216
例えばSICPでは銀行口座が取り上げられているが、
状態を明示的に操作するパラダイムのほうが、
自然なモデル化を実現できる場合もある

関数型で自然に書けるのであれば、関数型で書くことが勧められるとは思う
というより、効率とかの要求がない限り、わざわざ環境をいじる必然性がない
環境の破壊がないコードは挙動を推論しやすい

関数型かどうかと保守性はあんまり関係ないと思う……
むしろモジュールシステムとか、名前をうまく分ける機能が重要だったりするから

そういうのを保守性が悪いと思うなら、Javaを使っておけば良いんだ。

>225
他人のソースを読む時には名前、識別子が手がかりなのに、
一見しただけでは名前が出てこないimplicit conversionは超最悪ですよね。

関数型に文句を言いたいのか
Scalaに文句を言いたいのかはっきりしてほしい
>>225は関数型の話でしょ

あと、暗黙の型変換はObjectをimportしなきゃいけないから、そんな驚くようなことにはならないよ

文句を言いたいとかじゃなくてさ、どうしても必要な時以外は使うべきじゃない機能だ
って話でしょ？　gotoとか、演算子オーバーロードみたいなレベルで。

twitterさんもコーディング規約で禁止してるの？

そろそろEffective Scalaが欲しいな

Liftでセッション毎の情報を持たせるのって
どうやったらいいですか？

>231
net.liftweb.http.SessionVar でいいんじゃないの？
javax.servlet.http.HttpSession を直に呼び出す事も出来たはずだけど。

RC7きたぁ〜〜〜w

http://www.scala-lang.org/node/6881

>>232
ありがとうございます。
SessionVarでできました。

2.8.0 finalまだぁ〜待ちくたびれた(ry

次は、確実にRC8

開発者はRCの意味解ってるのか

>>237
Remainder of Cloverでしょ。
そんくらい、中卒の俺でも知ってるw

>>237
当然わかってるだろうけど
ユーザ数が増えてきて今までのプロジェクトの運営方法ではうまく回らなくなってるんだろう(たぶん)
RCの番号が増え続けてるのも、RC出た後に大きなバグが見つかる→フィックスの繰り返しが起きてるからだし

あとは最初のRCがScala Daysにあわせたものであって品質があまり良くなかったのが響いてるというのもあるかも

RCはReleaseCitainaの略

>>240

(とりあえずバグあるけど) ReleaseCitemimasita の略

業務で使いたいんだが…まだ早いかな？

>>242
どうなんだろうねぇ

社内でのJavaで作ったシステムに、ちょっとscalaを混ぜて使ってるけど。

正直、コンパイラのバグが怖いなあ

国内でのそれなりの規模の採用例って
特許を検索するやつ？以外にどこかあります？

一定規模以上だと長期のメンテナンスが怖いな。
結構仕様変わってるし。
自分用の小規模コード用なら好きなんだが。

>>244
コンパイラのバグについては、特定のコード書くとコンパイラがクラッシュする系の
バグはたまに見つけることがあるけど、計算結果が間違ってるとかそういう系のバグは、安定版(2.7.7)では
まず遭遇しないと思う。0ではないけど、実験的な機能(-Yオプション系の奴)やよほど変態的なコード書かない限りは
それほど恐れることも無いかと。2.8も正式リリースが出たら、安心して使って大丈夫じゃないかな。現状のRC7
でもまず大丈夫だとは思うけど。

あとは、既に国外ではTwitterとかLinkedInとかFoursquareとか結構有名なサービスが採用してる
事例もあるし、EDF Tradingみたいな、ちょっとミスが多大な損失につながるクリティカルな現場での採用事例も
あるので、その辺もまあ安心材料になるかな。どちらかというと問題は採用したとしてScala技術者をどんだけ確保
(育成)できるかってところじゃないかねえ。パテントビューロ(上の特許を検索するシステム作ったとこ)の人の
http://qcontokyo.com/pdf/qcon_TakashiMiki.pdf
発表スライドは、実際にScala導入してみようかと考えている人にとっては結構参考になると思う。単なる宣伝だけじゃなくて
実際に採用してみてリプレース前の既存システムでコード量にどれくらい違いが出たかとかの比較もあって結構面白い。

こういうのもなんだがll言語よりはちゃんと動くイメージがある

実際にはライブラリのバグの方が日常茶飯事だから気にならない

>>249
LL系言語は実行環境も自前で持ってるから、足回りはJVMという安定した実行環境が使える
Scalaなどの言語に比べるとどうしても劣る部分はあるだろうねえ。Twitterがバックエンドを
RubyからScalaに切り替えたのもGCの性能が悪いのが問題の一つだったらしいし。

Lift 2.0 age

細かいところばっかりだけどね
gcもそうだけど
llだとcと連動するところでトラブルが起きがちなんだよね
文字列をうまく処理できない場合があったり、リソースロックしていたり
それがjvm内で完結しているとトラブルが少ないしデバッグもしやすい

foursquare.comでも、LiftのAjaxによるGC回避のpingをやってるんだね。
200秒ごと？
あれは、大きなサイトでも大丈夫なのかなとちょっと心配な仕様だったんだけど。

>251
LiftScreenとWizardは面白そう。
タグレベルで細かくいじろうとすると、めんどくさいのかもしれないけど。
http://liftweb.assembla.com/wiki/show/liftweb/Lift's_Screen

アンドロイド上でscalaのインタプリタって動くの？

動くよ

お礼遅れてすいません、レスありがとうございます。
ブログの記事の方までレスくださったようで・・ありがとうございましたｍ(_ _)ｍ

>>org.apache.http.Header -> com.google.appengine.api.urlfetch.HTTPHeader
>>するimplicitも要りそう。

これがやっぱり必要なようですが・・まあ分かってません。
自分でも調べていますが、分かる方いらっしゃったら教えてくださると幸いです。
ありがとうごじましたｍ(_ _)ｍ

>>257
implicit def h2h(h: Header) = new HTTPHeader(h.getName, h.getValue)

試してないけどこれを追加したら動くかも。
間違ってたらごめん。

Scalaは短命だったな
覚えて損したわ

次の言語、頑張って覚えてね

すげー期待してたのにD言語みたいになってきてちょっとショック

なにいってるんだ
D言語はバイブルが出てこれから大攻勢に

出るといいな

>>261
D言語みたい、ねえ…どのへんが？

既に翻訳も含めて日本語のScala本が５冊出てるし
Twitter,foursquare,LinkedIn,などそれなりに知名度があるサービスのScala乗り換え事例
も増えてきてるしそんなに悪い状態とも思わないけどな

知名度が出たときに一気にブレイクできなかった言語は衰退するのみ

いいんじゃないの、Lispみたいにしぶとく生きてれば

>>263
仕様変えてRC出し続けてるところが

>>267
2.8の仕様はもうfixされてるはず。RC上がり続けてるのは主としてバグ修正目的
RC1→RC2で継続プラグインが入ったりspecializationが入ったりしてるがこれは元々
2.8で入る予定のものでRC1でまだ入ってなかったというだけの話だし

そんなんでRC出しちゃったのがまずかったというならその通りではあるんだが

Scalaの求人と普及中のスクリプト言語の求人を比べてみました。

Scalaの普及が始まってからまだ1年ちょっとしか経っていません。
http://www.indeed.com/jobtrends?q=Scala
Groovyの普及はScalaより1年半ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy
Rubyの普及はGroovyより4年半ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby
Pythonの普及はRubyより2年ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby,Python

Scalaの普及は続いており、短命だったは事実に反します。
一気にブレークできなかった言語も普及が続き、衰退していません。
プログラミング言語の普及には何年もかかるのです。

他のヒットしなかった言語も同じ事言われてたけどね
本当に必要とされてる言語はJavaやPHPみたいにグイっと来るんだよ

Cは普及するまでにかなり時間かかったけどな
本格的な普及がANSI C以降とするなら20年前後ってとこか

PHPの普及はPythonより2年ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby,Python,PHP
PHPは安定成長を続ける事でシェアを取りました。

Javaの方は確かに一気に普及しました。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby,Python,PHP,Java
Javaが一気に普及したのは主要プレイヤーがJavaを支持したために
Javaが次の主流言語になると信じた人たちがたくさんいたからでしょう。
LinuxもIBMがRedHatに出資したのがきっかけで普及しました。
JavaよりScalaの方が間違いなく生産性と保守性が高いとされるようになれば
Scalaが大手の支持を受けて一気に普及する目もあるでしょうね。

Scalaは保守性が低いからなあ。

>>273
煽るわけじゃないけどどの部分が？

Javaが急速に普及したのはWebという新しいプラットフォームが登場した事による
UnixでC、WindowsでVBが普及したのと同じ
Linuxが普及したのは十分な性能を持ち安価な1Uラックマウントサーバが登場した事による
同じ土俵で生産性や保守性を理由に後発の言語が普及した例はほとんどないのではないか
DelphiはVBより評価されていたようだがVB以上に普及することはなかった

数少ない例外がC→C++かな
Scalaもそうなればいいけど

>>275
Rubyがここ数年で普及したのは、Perlと比べたときの生産性や保守性が理由
(もちろん、Railsというフレームワークがあったのが大きいけど)だと思うけど、どうなんだろう…

>Perlと比べたときの生産性や保守性

あんま変わらんな
フルビルドだとインストール失敗するし
gemとか糞だし

> フルビルドだとインストール失敗するし

そういう問題があるならバグレポートしてくれよ

>>276
Cの普及時期から見るとC++の登場は後発と言うほど遅れていない
ANSI C制定(89年)と同時期にARM(The Annotated C++ Reference Manual, 90年)が出された
特にWindowsでは普及期(3.1〜95)にVisualC++の影響でCをやらずにいきなりC++の方が普通だった

>>277
非エンタープライズという意味でのWeb2.0というプラットフォーム(というより顧客／マーケットか)の
登場(拡大)が影響したのではないか

現時点で新しめのプラットフォームというとクラウドとスマートフォン
もしiPhoneアプリがScalaでしか作れなかったら・・・
クラウド特にGAEはまだチャンスがあると思う
GAEに特化した有力なフレームワークがあればScalaは普及するのではないか

>>281
言う通り、GAEは狙い目かもね
Scalaの表現力を生かして、BigTableへのアクセスとかが簡単にできる良い
Webアプリフレームワークがあれば…

GAEならScala + Slim3でどう？

Slim3はAPT使ってるせいでScalaと相性が悪い

おまいら GAE に夢見すぎ

まぁGAEが現状のScalaよりも遙かに普及してくれないと意味がない話ではあるな

>274
「有るから使う」程度の理由でimplicit使う奴が大量に居るから。

このスレってずっと暗黙の型変換で粘着されてるけど、そんなに嫌なら使うの禁止すれば？としか言いようがない

上のほうでgotoに例えられてるけど、よく知らないやつの怯えっぷりは似てるかもしれない
暗黙の型変換はgotoほど必須ではないと思うが

>>288
確かに。なんでこんなに(implicitに)怯えてるのか不思議でならない。
まあ使い方間違えれば可読性に負の影響を及ぼすことはあるけど、別にんなのはimplicitに
限った話じゃないしなあ…

怯えるとかそういう大げさな話じゃない。
濫用気味でしょと言ってるだけ。

そんなやつが大量にいるようには感じないけど
どちらにせよ規約で縛ればおｋな話だな

rubyとかで動的にメソッドがばりばり作成されたりするのとかと比べれば
implicitなんか明快すぎて楽勝だろ
変だなと思えば、簡単に調べられるし

まあ、怖がっているのはJava層かPHP層だろうな
PerlとかRuby使っているやつがこんなんでうだうだ文句言うとは思えない

C++やJavaはimplicit is evilって思想だからなぁ

そこでできるだけexplicitにしてみたらキーパンチが多すぎて収拾が付かなくなったってのが
ここ10年の歴史だとは思うんだけどね。

C#の変化の歴史を見ても、「外向けにはexplicit、内向けにはimplicit」が
今の流行じゃないのか？

一方歴戦のVBプログラマはoption explicitを使った

>>293
Rubyでもevalやリフレクションの濫用が問題になってた（なっている）
強力な機能は使い方を誤るとエライことになる
そこで最近は「ここぞという所にだけ使え」って原則が普及してきたように感じる

まあScalaについては、まずは濫用が問題視されるぐらい
普及してからの話じゃなかろうか

もしそう言うのが大々的に問題になったらIDEの機能でimplicitな所は分かりやすく色を変えたりして表示したりみたいな機能がつくんじゃね？

だから怖がりすぎだって
evalとかそういう次元じゃないから

>>277-278
Rubyメインで使っているけど、言語の良し悪しを置いておくなら、
ライブラリが数そろっててメンテされてて、
優秀な技術者がやとえる(というかもうそういう人しか残ってない予感がする)であろうPerlは
まだまだいけるように見える

RubyはRailsである壁を超えて広まりはしたけど、
ぶっちゃけると他にいいフレームワークがあったら移るような人たちばかりだろ、今使っているのはｗ

Perlの優秀な技術者どこで見つけてくるんだよって？Rubyも似てるだろ？ｗ

保守性？依存性ごっちゃなgemやらバージョンあげるとすぐに動かなくなるgem郡、
下位互換性もすぐに切り捨てられ常に変わり続けるRailsや周辺プラグイン

「Railsの生産性が高い」と行った場合、結局はwebアプリの開発にどのくらいなれているかで決まってくるし。
(公平に既存の資産がない、という前提)
少なくとも、ふだんRuby書いている奴が、Rails使ったからって簡単にwebアプリ作れない。
だからといって他の言語から乗り換えたい奴は、よっぽど不満なやつだけ。
そういう奴らも、すぐに目移りする。


ようするに仕事だとphp最強！！

Rubyメインでのくだりが繋がってないな、失礼。独立した別の行段落と考えてくれ

仕事メインはC++で、
週末にrailsで遊んでみたが
毎週gemは動かないし、アップデートするのに半日つぶれる
かといってバージョン固定したらバグやセキュリティーホールは直らないし
で、使うの諦めた

かと言ってC++でwebやる気は起きない
なのでscala+liftに逃げてきた

Rubyの話題はもういいよ
ここで長文書くことないでしょ

次はRC8？それとも正式リリース？

>>304
scala-internalsを読んだ限り、これ以上クリティカルなバグが報告されなければ
正式リリースされそうな感じ。

scala1のeclipseプラグインって現状galileoかGanymedeしか対応してなかったという認識だが、
Heliosに対応する予定はあるのか？
もしくはHelios飛ばしてM4のほうが先とか？

>scala1のeclipse
なぜかscala1とかいうわけわからないタイプミスしたが気にしないでくれ

公式サイトにもうすぐへリオス対応するって書いてある

>308

そうなのか。ありがとう

現時点でScalaを書くのに一番良いIDEって何かな？
自分はIntelliJのCEを使ってるんだけど。

このスレの人たち的にはrustってどうなの

最近EmacsでENSIME + sbt使ってるよ
・補完
・定義ジャンプ
・カーソル位置の変数の型推論
・flymakeっぽい自動コンパイルチェック
くらいはできるよ
Emacs派にはおすすめ

>>312
EMSIME、割と評判いいねえ。EclipseのScalaプラグインの出来が
イマイチだから、いっそのこと乗り換えようかな…

typoしたorz EMSIME→ENSIME

scalaでスクリプトを実行するときの起動時のオーバーヘッドを減らすのってどうやるんでしたっけ？
2年ぐらい前に記事で読んだことがあったような気がして本家を探してみたんですが、見つからなかったです。
もしよろしければ、やりかたかリンクを教えてもらえないでしょうか。
よろしくお願いします。

ちょうど昨日見てたけど、URLがみつからない。
Xshare:dumpとかコンパイルしたらどうだみたいな話だったよね？

とりあえず。

Javaアプリを高速起動する方法「JRubyテク」
http://journal.mycom.co.jp/news/2010/03/04/009/index.html

nailgunは、scala-2.8.0-rc5だと、いまのところ使えてない。
Xshare:dumpは、32bit -client用みたい。

http://www.scala-lang.org/search/node/nailgun
これだった。

-savecompiled の話か

下記の、どれが存在する言語なのでしょうか？
Ｃ＋−、Ｃ−＋、Ｃ−−

>>316-318
ありがとうございます。
nailgunはちょっと面倒で、-savecompiledは初回が遅いこととjarファイルが作られてしまって邪魔なのが欠点ですね。
ちょいnailgunについて調査してみます。

nailgunで、コンパイル後ならOKかな。

clojure書いてる人が用意したnailgun用のclasspath-managerというのを使ってみてるけど、
これを使うと、ng-cpせずに動的に呼び出すので、
・クラス名の重複が避けられる
現時点だと、
・逐次にclasspathというファイルを用意する必要がある
・classpathに書いた、ディレクトリ内のclassファイルを上手く読みに行かないので、jarやzipにしたほうがよい
・scala-library.jarを上手く呼び出せない
・他にも呼び出せないものがあるっぽい

http://github.com/stuartsierra/classpath-manager

今は、こんな感じでためしてる。
java -verbose -Xms32m -Xmx128m -server -cp lib\nailgun-0.7.1.jar;lib\classpath-manager-1.1.0.jar;lib\scala-library.jar com.martiansoftware.nailgun.NGServer
ng ng-alias cm com.stuartsierra.ClasspathManager
classpathファイル用意
ng cm メインクラス名

test

>>294
そんな歴史は無いだろ。
吠えてたのはLL信者だけじゃん。

にゃー

タプルを引数に渡したいとき、どうするですか？
val xy = (1,2)
def f(i:Int,j:Int): Int = i+j
f(xy) //ここ！

>>325
その場合、残念ながら直接渡せないので、
f(xy._1, xy._2)
のようにするしかない。タプルを直接渡せるメソッド(関数ではなく)を定義するには、
def f(ij: (Int, Int)): Int = ij match { case (i, j) => i + j }
みたいに書くしかないけど、これはこれでめんどいし。

タプルを引数に取るメソッドと複数引数を取るメソッドが同じじゃないのはJavaの
calling conventionにあわせた結果なんだろうけど、うっとおしいよねえ。

あと、
val (x,y) = (1,2)
ならいいのに、
private val (X,Y) = (1,2)
は
not found: value X
って怒られるのはなぜですか？

なにー！
大文字と小文字で違うのかっ！

とりあえず326さん、ありがとうございます。

>>327
パターンマッチングの仕様。
パターンの名前が大文字で始まる場合、未束縛の変数ではなく、その名前の値が
既に存在しているとみなされて、その値に対するパターンマッチが行われる。
つまり、
val (X, Y) = (1, 2)
の場合は、Xと1、Yと2が同じかどうか比較されるってこと。

>>330
何故にこんな仕様？

def f(a: Int, b: String) = ...
val tuples = ...
tuples.map { t => f(t: _*) }

みたいなことできればいいのに。

>>331
何故かという事に関しては直接は知らないのだけど(MLを検索すると出てくるかもしれないが)、
この仕様のメリットとしては

１．構文解析が簡単にできる
２．パターン名のtypoが検出できる

という二点があると思う。たとえば、仮に存在しない変数名がパターン部に記述されたら変数パターンだ
という仕様だったとする。すると、match式などの構文解析をするために構文解析時にいちいち変数表などを
もって回るか、構文解析の処理の一部を意味解析に回すことになる。一方、大文字小文字かで区別する
なら、そのような面倒な処理なしに変数パターンが値パターンかを簡単に区別できる。これが一点目。

二点目としては、たとえば、
x match { case R => ... }
のつもりが、誤って
x match { case T => ... }
としてしまった場合、大文字小文字で判定している場合、Tという値は存在しないというエラーを
出すことができるが、存在しない名前が現れたら変数パターンとみなすという仕様だと、Tという
変数が新しく定義されて正しくコンパイルされてしまい、エラーに気づかない可能性がある。

>> 325

Function.tupled(f _)(xy)

でどうでしょうか

シングルトンオブジェクトを
その名前の文字列から取得するにはどうしたらよいでしょうか？

>>335
こんな感じ？
object Refl {
def getSingleton(name: String): AnyRef = {
(Class.forName(name + "$").getField("MODULE$").get(null))
}
def main(args: Array[String]) {
val singleton = getSingleton("MyObject")
val klass = singleton.getClass
klass.getMethod("hello", Array[Class[_]]():_*).invoke(singleton)
}
}
object MyObject {
def hello { println("Hello, MyObject") }
}

>>336
ありがとうございます。完璧です。

予想以上に難しくてびびりました。
REPL で
> object A
> Class.forName("A$")
てやって、できないなー、とかやってたレベルなので。

>>336

技術的にできるのはわかるけど、

objectの実際のclassファイル名が、"名前+$"になっているとか、
"MODULE$"と名前のフィールドが存在しているのって、
言語仕様で規定されてたりするんだっけ?(そもそもそういった厳格な言語仕様ってあるの？)

scalaのソース上での表記と、classファイルにしたときの実装がどうなっているかってのは別の話だよね？
(いわゆるCRubyとJRubyみたいに標準の実装以外に別の実装があってもいい?)

もちろん、実用で使うには普通やるべきではないよね？ていうかやる必要ないよね？

まぁこういうふうにリフレクションつかってみるのは勉強にもなるし、楽しいけど。

あと、
object ++{}
みたいに記号名のobject定義できるけど、その場合って
$plus$plus.class
ってファイル名になるよね？それの変換まで実装したら大変だな・・・

>>338
おっしゃる通り、objectの名前と実際のclassファイル名の対応関係とかは、言語仕様では
規定されてなくて、あくまでも現在のScala実装に依存した話なので、それを承知でやるならアリかと
思うけど、普通はやるべきじゃないとは思う。

記号名は、各文字ごとに単純に表引きで変換できるから、そんなに大変ではないと思うけど、多少手間は
増えるね。

下のが実行時に
scala.MatchError: null
で落ちて困っているのですが、どうしたらいいのでしょうか。
ちなみに型パラメータをやめて[Double]とべた書きすれば大丈夫なのですが。

class Matrix[T](n) {
var mat = Array[Array[T]](n)
def init(v: T) {
mat=mat.map(_=>Array.fromFunction(_=>v)(n))
}
}

>>340
MatchError以前にそれだとそもそもコンパイル通らない
Array.fromFunctionの第二引数がIntだからnはInt型じゃないといけないが、
それだとArray[Array[T]](n)のところでエラーになるし…。推測すると、

class Matrix[T](n :Int) {
var mat = new Array[Array[T]](n)
def init(v: T) {
mat=mat.map(_=>Array.fromFunction(_=>v)(n))
}
}

が書きたかったコードじゃないかと思うけど、あってる？で、そうだとして仮定して
話を進めるけど、Scala 2.7では、ジェネリックな配列に関しては、内部的にBoxedXXXArray
(XXXは型名)というクラスのオブジェクトに変換して扱ってる。で、mat.map(_ => ...)の、
無名関数(_ => ...) の中で、最初に引数をBoxedXXXArrayに変換しようとするんだけど、配列の
要素がnullなので変換できずに失敗する。不具合といえば不具合かな。2.8では、Arrayは必ず
Javaの配列にマッピングされるようになったので、このような問題は起こらなくなってる。

class Matrix[T:ClassManifest](n :Int) {//2.8でしか動かないコード
var mat = new Array[Array[T]](n)
def init(v: T) {
mat=mat.map(_=>Array.fromFunction(_=>v)(n))
}
}
object MatrixMain {
def main(args: Array[String]) {
val x = new Matrix[Double](10)
x.init(20.0)
println(x.mat)
}
}

すげー。聞かないとまったく分からなかったです！
（通らないコード書いてすみません。ご推察の通りです。）

あと、v2.8では多次元配列の生成はfromFunction((i,j)=>...)が廃止されているので、
質問したケースではtabulateかfillを使えばいいみたいですね。

というわけで
class Matrix[T:ClassManifest](n:Int,value:T) {
private var mat = Array.fill[T](n,n)(value)
override def toString = mat.map(_.mkString(" ")).mkString("\n")
}

val thanks = new Matrix(10,3.14)
println(thanks)

こんどはこれで引っかかった・・・。
初めて数日なので、エラーに対してまったく勘が効かなくって困っています。
しばしご教授願います。
検索するに、java.lang.StringとDoubleで似たような話があるみたいなのですが、
x.toDoubleとかできないし。。。

$ cat point.scala
case class Point[T](x:T,y:T) {
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
}

object Run {
def main(argv:Array[String]) {
val p,q = Point[Int](3,5)
println(p+q)
}
}
$ make point
scalac-2.8 point.scala
point.scala:2: error: type mismatch;
found : T
required: String
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
^
point.scala:2: error: type mismatch;
found : T
required: String
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
^
two errors found
make: *** [point] Error 1

>>343
ひょっとしてC++ or D系の言語から来た人かな？
JavaやScalaなどの言語では、型パラメータが持っている演算を
制約として明示しないといけない事になっている。この例だと、型パラメータTが+メソッド
を持っていることを、コンパイラは知らないので、怒っちゃうわけだ。required: Stringって
出るのは、T + Stringという文字列連結だと解釈しようとしてそれに失敗しちゃうからだね。

で、解決策だけど、大きく分けて二つあって
１．implicit conversionを使う
２．implicit parameterを使う
のどちらかになる。

まず、１．の場合だけど、+メソッドをもった型Addible[T]みたいな型を定義して、
TからAddible[T]へのimplicit conversionを必要な型ごとに定義する。次のような感じ。

trait Addible[T] {
def +(that:T): T
}

case class Point[T <% Addible[T]](x:T,y:T) {
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
}

object Implicits {
implicit def intAddible(i: Int) = new Addible[Int] {
def +(that:Int) = i+that
}
implicit def doubleAddible(i: Double) = new Addible[Double] {
def +(that: Double) = i+that
}
}
import Implicits._
object Run {
def main(argv:Array[String]) {
val p,q = Point(3,5)
println(p+q)
val r,s = Point(3.5, 4.5)
println(r+s)
}
}

この方法だと、足し算するごとにPoint以外にも余計なオブジェクトが生成されるので、
メモリにあまり優しくない。

次に２．の場合だけど、2引数を取るplusメソッドをもった型PlusOp[T]みたいな型を定義してやって、
PlusOp[T]をimplicit parameterとしてPointのコンストラクタの渡すようにしてやる。こちらの場合、
余計なオブジェクトの生成は避けられるが、x + yと書くことができず、num.plus(x, y)みたいに書かなければ
いけないのでちょっと美しくない。

trait PlusOp[T] {
def plus(x:T,y:T): T
}

object PlusOp {
implicit object IntPlus extends PlusOp[Int] {
def plus(x:Int,y:Int) = x + y
}
implicit object DoublePlus extends PlusOp[Double] {
def plus(x:Double,y:Double) = x + y
}
}

case class Point2[T](x:T,y:T)(implicit num: PlusOp[T]) {
def +(that:Point2[T]): Point2[T] = {
Point2[T](num.plus(x,that.x),num.plus(y,that.y))
}
}

object Run {
def main(argv:Array[String]) {
val p,q = Point2(3,5)
println(p+q)
val r,s = Point2(3.5, 4.5)
println(r+s)
}
}

ちなみに、今回の例の場合、Scala 2.8ではNumeric[T]というtraitが定義されているので、自前で
PlusOpみたいなtraitを定義する必要は無く、以下のように書くことができる。

import scala.math.Numeric

case class Point2[T](x:T,y:T)(implicit num: Numeric[T]) {
def +(that:Point2[T]): Point2[T] = {
Point2[T](num.plus(x,that.x),num.plus(y,that.y))
}
}

object Run {
def main(argv:Array[String]) {
val p,q = Point2(3,5)
println(p+q)
val r,s = Point2(3.5, 4.5)
println(r+s)
}
}

implicit conversionとimplicit parameterそのものに関する解説はここですると長くなってしまうので、
必要であれば、Web上にあるドキュメントを読むなり、Scala本を買うなりしてください。

> ひょっとしてC++ or D系の言語から来た人かな？
はい、その通りでございます。
Swing使いたいけど、Javaはヤダっていうわがまま。

def +(that:Point[U]): Point[T] = Point[T](x+that.x,y+that.y)
と書いてみて「Uなど存在しない」と怒られたり・・・（トホホ）。
やっぱJava系の型計算をよく分かってないせいでしょうかね。
標準で使えるオブジェクトの種類が多すぎて的を絞れていないです。

> で、解決策だけど
手元にコップ本はあるので、そこら辺をよく読んでみます。
毎度大変助かります。

うわ、返信書いてる間に・・・。
親切すぎる！

おぉ、コップ本21章は必読ですね。implicitマジックやな、これは。

implicit def 名前テキトー(x:Double) = x.toInt
を勝手に探しにいったりするわけですか。
・・・うかつな使いかたをするとエラーの所在を当てるのが難しくなりそうですね。

コップ本の31章の一番最後(573ページ)に、

>パーサー生成でLALR(1)のような効率のよい解析アルゴリズムが使える。・・・(途中略)
>誰かがそのようなジェネレーターを作れば、それは標準Scalaライブラリーに簡単に統合できるだろう。

とか書いてあるけど、誰か作ってる人いるの？(もしくは実はもう出来てるとか？)

これは著者は作る気ないけど"誰か作ってくれないかなぁ〜"ってことなのかな？

もうすぐ2.8が正式リリースされるだろうけど
コップ本の内容って役に立つよね？
買おうかどうか悩んでる。

>>352
9割以上はそのままじゃなかろうか。

>>352
ほかにいい本ないしね。買ったほうがいいよ。

ついにキタ！
Scala 2.8.0.final
http://www.scala-lang.org/node/7009

ついにfinal RCか。

(*￣∇￣)/゜・:*【2.8.0 final】*:・゜＼(￣∇￣*)

(*￣∇￣)/゜・:*【2.8.0 final】*:・゜＼(￣∇￣*)

(´･ω･｀)人(´･ω･｀)

一番にキターしたかったのにorz

寝る前にチェックしたときはリリースしてなかったのに(´･ω･｀)

Helios対応 Scala-IDEまだぁ〜待ちく(ry

(;^_^ /゜・:*【2.8.0 final】*:・゜＼(;^_^

次の、2.8.1または2.9または3.0はいつでるの？w

>>354
> ほかにいい本ないしね。買ったほうがいいよ。

「ボクらのScala ~ 次世代Java徹底入門 」
を買ったけど、思ったより良かった。

・日本人が書いているから、変な和訳はないので、読みやすい。
・洋書にありがちな、分かりやすいようで分かりにくい例え話は、ない。
・日本の出版社の本は、図とかレイアウトが丁寧で分かりやすい。
・だけど、本の題名で損している。
「ボクらの〜」という題名で敬遠している人は多いかと思うけど
「たのしいRuby」とかと同じ系統の本で、なかなか良い。
「次世代Java入門」っていう副題は、意味不明。内容的にほとんど意味なし。

Scalaは自称次世代Javaだから

自称してるのは、「次世代javaの先取り」だけどな

先取り次世代Javaならまだよかったのに

なんでmutableなのにListBufferはvalで宣言して、
しかも+=ができるの？
意味わかんなくて理解できなくて睡魔に襲われたんですけど

+=っていう名前のメソッドが定義されてるから

>>>365
ん〜〜〜・・・初心者にはいいのかもしれないが、ある程度Javaとか知ってるなら、コップ本以外ありえないと思うんだけどなぁ。
自分的は、コップ本で理解できるから、他の本は内容薄くて、まったく買う価値が見いだせないっていう感じ。

>変な和訳、分かりやすいようで分かりにくい例え話、
この辺はどんな洋書の和訳でもそういうものだし、別にコップ本はそういうのあまりないと思うけど。
っていうか、そういう翻訳されたものとか結構読んでるから、洋書独特の例え話とか慣れてしまって、意識すらしてなかったな。

>>369
オブジェクトがmutableということと変数がmutableということを混同している
valは、あくまでその変数に再代入不可ということを保証するだけで、その変数が指す先の
オブジェクトがmutableであるかどうかは関知しない。+=に関しては、>>370の言う通り、そういう
名前のメソッドがListBufferに定義されているからだね。

ListBufferはインチキしてるから。
インチキの実態は、コップ本に詳しく書いてある。

外向きには関数型言語っぽいけど、ライブラリ内部は全然そうじゃない、ってとこが
Scalaの特徴のひとつだろう。これには幻滅する人も何割か居そう。

ScalaでのSymbolってどういうときに使えばいいの？

記法上は組み込みで特別な構文があるけど、Rubyとかと違って、
実態は単なる普通のクラスと何ら変わりないわけだし、
パフォーマンス考えたら、JVMの仕様上、Stringで代用したほうが、速そうな気がするんだけど。

(比較するのは速いかもしれないけど、生成するのにコストがかかる？
JVMはStringは特別扱いするけど、JVMから見ればSymbolは単なる普通のクラスでしかないよね？)


コップ本にも1ページ分くらいしか載ってないし・・・

>>373
>外向きには関数型言語っぽいけど、ライブラリ内部は全然そうじゃない

パフォーマンスのこと考えてるんだろうから、それは正しい選択だと思うが・・・
幻滅する人はHaskellでもやればいいよ

>>375
Dみたいにconst(final)とimmutableを区別できるのはメリットがあると思うけどな

>オブジェクトがmutableということと変数がmutableということを混同している
なるほど…！理解した

val x = numbers.head
val y = numbers.last
val r = numbers.tail

ﾎﾞｸらのScalaでListの変数名を r にしてるんだけど、
これってどういう意味合いかわかりますか？
range の意？
(挫折した) Haskellだと複数形の　s　つけて xs ってしてたような

restですかね
いやさっぱりわかりませんが

>>378
一時変数で適当につけてるみたいだし意味ないんじゃないの？
そもそも、rのいみわからなくて、そのxとyの意味あいはわかった？

ループ変数のi,jに意味求めるようなものだろう。元の意味や語源はあるけど意識してはつかってない

真意は著者に聞いたほうが早いと思う

i, j, k とか x, y とか n は数学的なものでしょ
意味合いも理解できるし、なによりいろんなプログラミング言語でも使われてる

i,j,kはFORTRANから。初期のFORTRANは整数型の変数名にI,J,K…しか
付けられなかったためいまだにその名残がある。

それよりscalaはすごく遅いのだがそういうものなんだろうか？

>整数型の変数名にI,J,K…しか付けられなかったため

宣言しなかった場合だけだろ

初期のFORTRANには宣言が無い。

restの頭文字とったんじゃないの
head/tail = first/rest = car/cdr

(ﾟДﾟ)ｸﾀﾞｰ

>>385
追加
head/tail = first/rest = car/cdr = x/xs

本当はX|Xsと書きたい

>>387
> 本当はX|Xsと書きたい
しかし、こういう命名をすると次にXsをheadとtailにわけるとき、名前に困るという罠が

yとysでおｋ

つーか再帰して今のXsが次のXとXsに分けられるだけだろ
なんで違う名前が必要なんだ？

著者にTwitterで聞いてみたら、
書いたときは remainder のつもりだったんじゃないかなと思います。 とのこと

著者に気軽に質問ができるなんて、ホント便利な世の中になったもんだ

javaの
static class X {
static { ... }
}
（staticオブジェクトが初めて起動されたときだけ実行される）
と同じことをScalaでやろうとすると、

object X {
{
println(new java.util.Date())
}
def exec() = println("world!")
}
X.exec()
X.exec()

これで良さそうですが、
def init() { ... }
みたいなマジックワードがあったりするのでしょうか？
（初期化し直したかったりする場合のため）
初期化コードが長い場合に他のメソッドが埋もれないように、
とりあえず上のように中括弧いれてみましたが、それ以外で。

>>393
def init() { ... } みたいな初期化時に呼ばれる専用メソッドは特に無いので、
object X { ... } の中に初期化コードを直接入れるのでOK.ちなみに、{}をいれずに
直接初期化をobject直下に書いた場合、初期化コード中でしか使わないローカル変数を宣言しようと思っても、
フィールド扱いになってしまうので、そういうのを避ける意味でも初期化コードが長くなるなら、初期化
コードを{}で囲むのは良いと思う。

マクロ機能はいつサポート予定ですか？

これ以上複雑にされると、もうついていけない。

>>391
乙乙
疑問が解けた

特に習慣的に決まっていて書いていたわけでもないのねｗ

>>396
>これ以上複雑にされると、もうついていけない。

scala の cheat sheet でも。
http://www.bing.com/search?q=Scala+cheat+sheet

>>396
なにがサポートされようが便利なら使えば良い便利でないとか判定できないなら
無視すれば良い。それで困ることがあるはずない。

もっと複雑になればJRubyの需要が高まるね(ﾆｯｺﾘ

val xs: List[Int] = eval("List(3,2)")
みたいに、リスト限定でevalをしたいのですが、
正規表現、パーサー作る、以外の簡単な方法はありますか？

import scala.tools.nsc.Interpreter
val xs = (new Interpreter).evalExpr[List[Int]]("List(1,2,3)")
一応こういうのはあるけど、こう使うものなのかよくわからない

実は正統なやり方もよくわかっていません。
Cだとsscanfで簡単に3と2を切り出せるのですが、
こういう修飾された文字列からTokenizerを使って読めるのでしょうか？
（検索するとCSVのサンプルはたくさんあるけど、あれは余計なゴミがついてないから・・・）

なんかいじめとしか思えないのですが、
findInLineを使おうとするとmatchが使えないという・・・
ttp://webcache.googleusercontent.com/search?q=cache:YmIStkq4fN8J:ja.doukaku.org/170/nested/

sscanfでは配列を読めないんじゃ…
まあ、なにをやりたいのかわからないけど、
特にこだわりがないなら内部DSLにするのがScala的なんじゃないかな
その次はパーサーコンビネーターを使う
evalはScalaではかなり邪道でしょう

ちなみにList[Int]を読み込むだけなら
パーサーコンビネーターでこのくらいで書ける
この程度なら書いたほうが早いでしょ

import scala.util.parsing.combinator.JavaTokenParsers
val parser = new JavaTokenParsers {
def list = "List" ~ "(" ~> repsep(decimalNumber ^^ (_.toInt), ",") <~ ")"
}
val xs = parser.parseAll(parser.list, "List(1,2,3)").get

自分のケースについては完全に動作しました。ありがとうございます。
ただ、パターンの部分は勉強しないと読めませんね・・・。

Google Web ToolkitをScalaでやるのって可能なの？

あれって、Javaソースコード(.java) => javascriptソースコード(.js)
へコンパイルしているんだろうけど、
Scalaソースコード(.scala) => Javaソースコード(.java) へのコンパイラがあれば、
Scalaソースコード(.scala) => Javaソースコード(.java) => javascriptソースコード(.js)

ていう感じでできるかな？(コンパイルすごく時間かかりそうだけどw)

ところがだ
Javaソースコード(.java) => javascriptソースコード(.js)
にとって意味のあるコードは
Scalaソースコード(.scala)
としてはまったく無意味なコードになるであろう

ちなみに以前読んだ記憶では一旦JavaのASTにはしてるけど
Javaバイトコードに落ちる前だった。

>>407
原理的にはできるし、現状でもexperimentalなjava-srcバックエンド使えば一応できないことも無いけど
現状では十分に実用的とは言い難いってのが正直なところだと思う。一応こんなプロジェクトも
あるけど、どこまで使えるのかはちょっとわからない。
http://scalagwt.gogoego.com/

>>410
一応プロジェクトもあるのかぁ。ありがとうございます。

packageと、実際のソースがあるフォルダが対応してなくていいのって、
なんでこんな仕様になってるの？
使うときなくない？
対応してなかったら紛らわしいだけだと思うんだが。

http://d.hatena.ne.jp/yuroyoro/20080809/1218253532を参考に、
下記を実行しても、コンソールには「value:world :: Empty」と出力されてしまい、
S.param("whoField")の部分が「Empty」となってしまいます。
「value:world :: :world」にならないのは何故でしょうか。

class Test {
object who extends RequestVar(Full("world"))

def show(xhtml: NodeSeq): NodeSeq = {
bind("hello", xhtml,
"whoField" -> text(who.openOr(""), v => who(Full(v))) % ("size" -> "10") % ("id" -> "whoFieldText"),
"submit" -> submit("Send", () => {println("value:" + who.openOr("") + " :: " + S.param("whoField"))}),
"who" -> who.openOr("")
)
}
}

<lift:surround with="default" at="content">
<h1>Hello Form2</h1>
<lift:Test.show form="POST">
Hello <hello:who/>
<br/>
<label for="whoField2">Who :</label>
<hello:whoField/>
<hello:submit/>
</lift:Test.show>
</lift:surround>

抽象型って抽象メソッドとかと違って実装しなくてもコンパイルできんだな、なんでこんなんなの？

trait Hoge {type A}
class Fuga extends Hoge　//コンパイルできる

>>414
抽象型はそれだけでも、「何だかわからない不明な型」みたいに型チェッカに扱われるので、コンパイル通る。

プログラムの実行ファイルってみんなどうやって作ってるんだろ？
eclipseとかnetbeansにそういう機能がついてんの？

416みたいな人（失礼！）でも使うくらい、scalaって知名度があるんだな。
少し見直した。

まぁ裏でMavenが何やってるか知っておきたい気はする

>>412

package scala.collection
package immutable

とした場合と、

package scala.collection.immutable

とした場合にスコープが違くなるとかそういう話？

scalaは書き方が好きなんだけどいざ使ってみるとすごく遅い。
単純なプログラムでも起動してから最初の結果を得るまでに1秒くらいかかるけど
インストールでへまやったんだろうか？　みんなもこんなに遅い？

>>420
eclipseとかつかってる？
コンパイル(と起動)が遅いだけで、実行スピードは、Javaと対して変わらないよ。
System.currentTimeMillisとかで、起動したときと、終了する前の時間調べればわかるけど

そんなあなたにfsc

起動が遅いのはJVM系言語の共通の弱点だね
コンパイルが遅いのは、もうちょっと頑張ってほしい

レスサンクス。
>>421
eclipseは使ってない。起動に１秒くらいかかるだけで処理が始まってからの時間は
lispと大きく変わらないようだ。

>>422,>>423
両方早いにこしたことは無いが実行時間が早くなってほしい。jruby,jython,clojureも
同じ状況なんだろうな。

質問です。

scala2.8で
val list = nw ListBuffer[(Int, String)]
list += (1, "a")
とすると、下記のようなエラーがでます。

<console>:8: error: type mismatch;
found : Int(1)
required: (Int, String)
list += (1, "a")
^

ちなみに2.7.7.finalだと正しく動作します。これってなんで。

list += Tuple2(1, "a")
だと上手くいきました。
なんか2.8で変わったのかな。

>>425
ListBufferのAPIドキュメント
http://www.scala-lang.org/docu/files/api/scala/collection/mutable/ListBuffer.html
見ればわかるんだけど、
def +=(elem1: A, elem2: A, elems: A*): Growable[A]
というシグネチャの可変長引数のメソッドがある(2.7では無かった)。そのため、
list += (1, "a")
というのが、可変長引数のメソッド呼び出しと解釈されてしまうため、第1引数がIntで第2引数がStringで、
という風になっちゃうわけだ。しかし、ListBuffer[(Int, String)]の場合、各引数は(Int, String)でないといけない
から型が合わなくてエラーになる。回避するには、
list += (1 -> "a")
のように->演算子を使うか、
list += ((1, "a"))
のように括弧を余計に入れて、可変長引数バージョンでなく１引数バージョンのものだと解釈させる
ようにする。個人的には、->演算子使う方が好みかな。

>>427
理由まで説明してくださり勉強になりました。
有難うございます。

この話、前もあったよね
意外とひっかかるポイントなのかも
タプルは->を使うというのがScalaの豆知識だね

lift使いの皆さんはストレージとのやりとりに
mapper and recordとJPAどっちつかってる？

jpaの方がejbにそっててなじみがあるので良いような気がするんだけどどうなんだろ。

>>429
要素が3つ以上の時は -> だと駄目だよね

>>422-424
Scala気になってるんですが、
こういうのってハックみたいなもので解決する方法ってあるんでしょうか？

Rubyなんかだと、素のRubyは速いけれどライブラリたくさんよむとやたら重くなって
テスト実行時にDRbだかRubyのサーバー？みたいなのを裏で立てておいてライブラリの読み込みを高速化する方法とかあったけど
webアプリは開発モードだと必要なものだけリロードできるし

いくら起動が遅いと言ってもインタプリタが動的に読み込むよりは早いんじゃないの

ブーチ「ただ、現在、わたしの興味を引く言語の1つとして、
Scalaを挙げることができる。なぜなら、伝統的な言語である
C／C++でもFORTRANでも隠ぺいできていなかった並行性の問題に
Scalaは光を当てているからだ。」
http://www.itmedia.co.jp/enterprise/articles/1007/28/news032.html

>>423-424
Groovyだとこんなのあるね。
ttp://d.hatena.ne.jp/nobeans/20100309/1268149199

>>432
fscはそういうアプローチなのでは。
実行はOSGiバンドルでやるとJVMの起動分は早くならないかな？

ターミナルもう一つ立ち上げてsbtで監視がFA

sbtのことサバトってよんでもいいかな

スブタにしようぜ

質問させてください

import scala.util.control.Exception.catching
def castToInt(v: Any): Option[Int] = catching(classOf[ClassCastException]) opt v.asInstanceOf[Int]

こういう関数を定義すると

scala> castToInt(24)
res1: Option[Int] = Some(24)

scala> castToInt("abc")
res2: Option[Int] = None

こういう実行結果になると思います。

def cast[T](v: Any): Option[T] = catching(classOf[ClassCastException]) opt v.asInstanceOf[T]

そこでこういう関数を定義して castToInt の汎用版を作りたいと思ったのですが

scala> cast[Int](24)
res3: Option[Int] = Some(24)

scala> cast[Int]("abc")
res4: Option[Int] = Some(abc)

こうなってしまいます。なぜこのような挙動をするのでしょうか？ちなみに、

scala> res4.get
java.lang.ClassCastException

となるので、get したときに初めて ClassCastException が発生しているようです。

asInstanceOfはコンパイラ向けであって、
実際にキャストしてるというわけじゃないんだろうね
Manifestを使ってクラスを取ってきて無理矢理キャストしてみるとか？
まあ、そんな関数作らないほうがいいよねｗ

>>439
JVMつかってることによるscalaの型システムの限界かな

こんなふうな関数つくって

def cast[T](t:T)(v: Any):Option[T] = {
try{
Some( t.asInstanceOf[AnyRef].getClass.cast(v).asInstanceOf[T] )
}catch{
case e:ClassCastException => None
}
}

第一引数に、castしたい型のオブジェクトの実態をいれれば
どうにかそれっぽいことできるけど・・・(´・ω・｀)カッコ悪い・・・


scala> cast(0)("abc")
res0: Option[Int] = None

>>440-442
ありがとうございます。Manifest 調べてみます。classOf[T] もできないんですね。
もともとやりたかったのは、例えば KVM のようなデータストアにアクセスする以下のような Java のライブラリがあったときに

interface Store {
　Object get(String key);
　void set(String key, Object value);
}

これに対して Scala らしいインターフェースのラッパーを作りたかったんです。そこで

class Wrapper(store: Store) {
　def apply[T](key: String): Option[T] = {
　　val value = store.get(key)
　　if (value == null) None
　　else catching(classOf[ClassCastException]) opt value.asInstanceOf[T]
　}
　def update(key: String, value: Any) {
　　store.set(key, value)
　}
}

というのはどうかなと思ったところうまくいかなくて、先ほどの質問をしました。
静的型の言語に慣れてないのでうまいやり方がわからないのですが、
皆さんだったらどのようなインターフェースにしますか？

そうか、Manifestでクラスを取ってきてもBoxingできないんだね
まあ、自力でテーブル作ればいいけど

>>443
いや、それはキャストエラーをNoneで潰しちゃ駄目なんじゃない？
見つからないのか、型が違うのか、区別したほうがいいと思う

manifest 使ってみました。こういうことでしょうか。

def cast[T <: AnyRef](v: AnyRef)(implicit m: reflect.Manifest[T]): Option[T] =
　catching(classOf[ClassCastException]) opt m.erasure.cast(v).asInstanceOf[T]

AnyRef を Any にしたければテーブル作れって事ですね。


>>445
確かにそうですね。
目的と違う型ならどうせ利用できないから無いも同然でもいいかと思ってこうしました。
少なくとも厳密なAPIは別に必要ですね。

静的型言語でキャスト失敗するって99%バグだからね
むしろ、そうやって型を活かすように書くべきというか
だからキャストエラーなんてそのまま上に投げちゃって構わない

確かにバグ以外は思い浮かびません。
catching の方は消すことにします。
アドバイスありがとうございます。

最初 Option[T] にせず T をそのまま返してたので気づかなかったんですが、
Option[T] にすると型推論も効かなくなるみたいなのでもうすこし考えてみます。

いつのまにやら、helios用のscalaプラグインがでていたようですな

(´・ω・)つ
ttp://download.scala-ide.org/
ttp://download.scala-ide.org/nightly-update-helios-2.8.0.final

>449 コレ使うと、liftのビルドおかしくなるのかな、やっぱ。

やっとheliosにscalaプラグインインストールできた＆かなり良くなってる

val a = new String("abc")
val b = new String("abc")

こうやるとa eq bはfalseになるんだけど

val a = "abc"
val b = "abc"

こうするとa eq bがtureになるのはなんで？

javaの仕様で同一内容のStringリテラルは同じインスタンスを参照することになってる。
リテラルの場合はaもbも同じインスタンスだからtrue
newした場合はそれぞれ別のインスタンスだからfalse

>>451
安定性はどんな感じですか？

>>453
サンクス

スレ違いでしたらすいませんが質問です
Scalaプログラミング入門を読んでScala初心者始めたのですが
触り始める前の、関数型言語とオブジェクト指向の自然な融合をした実用言語の印象が
それプラス強力なパターンマッチと再帰の組み合わせが新たなパラダイムを開けそうな言語
に見えています。
アクターとパターンマッチングは自分の使ってきた他の言語に見られない特徴なのですが
この機能はどの言語からの輸入なのでしょうか？
（アクターはSmalltalkのメッセージからっぽいのですが･･･）

アクターとパターンマッチを組み合わせた実用言語といえば
まずErlangを連想するべき

>456
触りはじめなら、F#と比較してみたら？

かつてEiffelのdefferdに憧れた俺が来ましたよと
>>456 アクターは昔からあった考え方ですね

Scala開眼に詳しい概説あり
http://www.h7.dion.ne.jp/~samwyn/Scala/scalaindex.htm

JVM以外のサポートってどうなってるの？.Netとか対応予定ってみたことある気がするんだけど。昔。

>>460

Scalaは、既に.net には対応しているんじゃないの？？



JVMは、SwingとかGUIもそろっていて良い面がある一方で
OracleのAndroid訴訟とかあるし、JVMの将来が不安だ。
技術面でなくて、政治的な面で、JVMの将来が不安。。。

だからといって、.netも将来的に不安だし。。

ttp://www.scala-lang.org/node/168
バージョンは1.4だけど

GJCみたくScalaも叩かれる訳か

Sun…じゃなくてOracleのリファレンスJVMなら大丈夫なんじゃないの？

質問させてください。

同名の method, property を持つ Java のクラスを継承し、
その method を override しつつ、
property にアクセスすることってできませんか？

J.java
public class J {
　protected int a = 0;
　public void a() { a += 1; }
}

S.scala
class S extends J {
　override def a { a += 2 }
}

こんな感じのことがしたいです。

scala.org がダウンしとる...
2.8.0.final-devel-docs 落としとくんだったお

>>465
継承するとprotected int a が見えなくなっちゃうふしぎ！

$ cat J.java
// J.java
public class J {
protected int a = 0;
public void a() { a += 1; }
}
$ javac !$
javac J.java
$ scala -cp .
Welcome to Scala version 2.8.0.final (Java HotSpot(TM) Server VM, Java 1.6.0_20).
...

scala> (new J).getClass.getDeclaredFields
res0: Array[java.lang.reflect.Field] = Array(protected int J.a)

scala> (new J {def f = this.getClass.getDeclaredFields}).f
res1: Array[java.lang.reflect.Field] = Array()

http://java.sun.com/javase/ja/6/docs/ja/api/java/lang/Class.html#getDeclaredFields()
> この Class オブジェクトが表すクラスまたはインタフェースによって宣言された
> すべてのフィールドをリフレクトする Field オブジェクトの配列を返します。
> これには、public、protected、デフォルト (package) アクセス、および
> private フィールドは含まれますが、継承フィールドは含まれません。

おお、なるほど こりゃ失敬しました
でも　super[J].getClass.getDeclaredFields もダメなんです
はい、頭固いってよくいわれます

!? わかった
this.getClass.getSuperclass.getDeclaredFields

できたじぇ

scala> val j = new J {override def a = {val sa = this.getClass.getSuperclass.getDeclaredField("a"); sa.set(this, sa.getInt(this) + 2)}; def geta {println(this.getClass.getSuperclass.getDeclaredField("a").getInt(this))} }
j: J{def geta: Unit} = $anon$1@1ad637e

scala> j.geta
j.geta
0

scala> j.a
j.a

scala> j.geta
j.geta
2

>>467-471
ありがとうございます。ここまでやらないとダメなんですね。

protected val _a = getClass.getSuperclass.getDeclaredField("a").get(this).asInstanceOf[XXX]

こんなふうに持つようにしたらうまくいきました。

あ、あれ？
素直にコンポジションにしろよってツッコミがくると思ってた…
斜め下の回答して、婉曲にあの人頭おかしいっていわれるのが得意です（キリッ

protectメンバのテストには無名クラス使えばいいんだけど
テスト対象がprivateの場合はどうしたらいいの？
Inspectorで権限書き換えるしかないのかな？

ScalaがJavaと比べて簡潔に書ける理由って具体的になに？
3秒考えてみたけど、リテラルが多いことしか思い浮かばなかった

パターンマッチ！パターンマッチ！

見た目が簡潔との観点だと
・関数オブジェクト
・多重継承の代用となるミックスイン
・シングルトン代わりのObject
とか

>>475
関数リテラルとＸＭＬリテラルと複数行文字列リテラルくらいじゃない？Javaに比べて追加されてるのって。
List(...)とかArray(...)は別にリテラルじゃないし。

個人的には、典型的なクラス定義が簡潔に書けるように考慮された文法(case classなど)、ファーストクラスの関数(高階関数)、
パターンマッチ、placeholder syntax、trait辺りがポイントかなあと思う。あと、packageの扱いが柔軟なのもなにげに嬉しい

・Actorで非同期並列処理が簡単に書ける
・遅延評価を用いたif,whileの独自拡張構文が書ける
・パーサーコンビネーターでらくらくDSL構築
・XMLリテラルでXMLパーサーいらず

・型推論によってコンパイラが型を特定できる場合は省略可能
・行末の";"がいらない
・Scala基本コンストラクタのパラメータは自動的にprivateインスタンス変数になる
---- Java ----
class MyClass {
　private int index;
　private String name;
　private MyClass(int index, String name) {
　　this.index = index;
　　this.name = name;
　}
}
---- Scala ----
class MyClass(index: Int, name: String)

　[Scala スケーラブルプログラミングより]

クラスのメンバでvalだとゲッタvarだとゲッタ＆セッタを作ってくれるってのがなんか感動した
短く書くためのC#の自動実装プロパティとかよりさらに短く書ける上に自然だし

・引数が無い関数呼び出しの()を省略できる
・Option[T]でnullチェックいらず
・Javaのfor文の入れ子⇒ジェネレータ"<-"で一つのfor{}にまとめることができる
・複数の結果を返す関数などちょっとした入れ物が欲しいときには括弧でくくるだけでタプルになる

よし、まだ忍者は来ていないな。

呼んだ？

にゃるほど
コピペで記事にできそうだな

Scala+Liftによる超実用開発
http://www.infoq.com/jp/interviews/Scala_Lift

GroovyServってのは、nailgunとなんか違うのかな。

遅延評価つかうとVB.Net の With statementのような事ができるのかな？
dataout.writeInt(data.length)
dataout.write(data)
dataout.flush()
↑こういうのを↓なかんじに
with(dataout) {
_.writeInt(data.length)
_.write(data)
_.flush
}
できたらうれしく……ないか
とりあえずdef withでscala/srcをgrepしたら一杯出てきてどうしよう←いまここ

>>488
そういうことしたいなら、
{
import dataout._
writeInt(data.length)
write(data)
flush
}
で、どうかな？

スコープを {} で括るのってJavaでもできるけどダサくないっすか

Scalaの開発では、1つのソースコードに1つのクラスを書くのが基本ですか？（内部クラスみたいのは除く）
もしそうなら、ソースコードのファイル名も、1文字目が大文字っていう慣例がありますか？

ITProのアクターの記事は1ファイルに数クラス書いてるけど、
これは閲覧者がコード内容を理解しやすいからって認識で良いのかな
書籍はインタプリタでScalaを解説してるから、なんかこういう細かいことで疑問が生じた
　

そんな縛りないよ

設計管理じゃなくて"ハック"がしたいんだよ

ScalaはJavaで散見された紋切り型の記述が必要ないので、普通のclassも規
模が小さいし、その周りに粒度の小さいcase classとかtraitとかがわらわら
出てくるのでそんなのにいちいちファイル作ってたらきりがないってのがあ
る。

リファクタリングのコストが高くなって不要なクラスを故意に見逃すくらいな
らそんなファイル作らないぜよ

「ThoughtWorks アンソロジー」のオブジェクト指向エクササイズのように徹
底してやりたいならリリース直前の最終段階で小分けにすればいいやん。
多分みんなそこからブランチつくってプロジェクトが枝分かれするねｗ

とりあえず >>491 はScalaインストールして実際に手動かすべきだと思う

んじゃあ１モジュール１ファイルにするってことでいいのかな
１ファイルにインタフェースと、それを継承した複数の実装を書いちゃう感じでいいの

なんとなくこのスレみてて
仕事で使うことは無いだろうなと思ってたら
scala使う案件担当することになったわｗ

くらしき行きたかったなぁ…

Scalaの案件…

最近、技術力を求める案件が増えてる気がするなあ

Scalaいいたいだけちゃうんかと、ヒゥイッヒヒー

>>489
おお、こんな機能あったんすね(2.8まだ入れてなかった...)

- Package objects

Packages can now contain besides classes and objects also methods,
fields or type aliases. These are added to a package by declaring a
package object. More capabilities might be added to package objects
in subsequent releases.

>489とpackage objectは関係ないし、2.8じゃなくてもできる

ありがとうございます
さっそくつかってみます

以下のコードは通らないのですが、常套手段があったりするのですか？

######################

case class X(x:Int)
class Y[T] {
val p = T(1)
}
val y = new Y[X]
println(y.p)

常套手段ではないと思うけど頑張ってやるとしたらこんな感じかね

case class X(i: Int)

class Y[T](val companion: (Int) => T) {
val p = companion(0)
}

val z = new Y[X](X)
println(z.p)

Scalaの糖衣構文をまとめた資料ってどっかにない？

割と頻繁にJAVAコードを追ったりJVMの動作を考えさせられるのが鬱陶しい

確かにJavaの仕様に依存するところも多いがJavaを知っていれば問題はない
Java詳しくないのであれば、Javaの勉強もできて一石二鳥なんじゃね？

そりゃプログラムを完成させるだけなら問題ないだろうよ。
俺は暗号化されたようなJAVAコード読みながらちまちまパフォーマンス
を詰めるのが苦痛で仕方ない。
関数型言語ってのは流儀にのっとって書けば効率良いバイナリを
吐いてくれるという幻想が見事に打ち砕かれたわ。

>>506

JavaとかScalaとか言う以前に "The 90/10 Rule" を知らないのかよｗ

デフォルト引数使いたいのに、
case class window(width:Int,height:Int=width)
これが通らないのはダメじゃないかと思うのだが・・・。

参考：
http://www.scala-lang.org/node/2075

オーバーロード

あれ、どうして？

case class window(w:Int,h:Int) {
def this(w:Int) = this(w,w)
}
window(3)

>> error: not enough arguments for method apply: (w: Int,h: Int)window in object window.

classだとできるのにcase classだとできないっぽい。
なぜだ・・・？

case class Window(width: Int, height: Int) {
def this(i: Int) = this(i, i)
}

object Window {
def apply(i: Int) = new Window(i)
}

Cool!!

なんかたらい回してる感もあるけど、現状ベストでしょうね。
ありがとうございました。

def f(x:Int):Stream[Int] = {
return if (x<0) Stream(-1) else Stream(x)++f(x-1)//++f(x-1)
}
println(f(1<<10).take(10).toList)

上のプログラムで、コメントアウトを外すとOutOfMemoryErrorになってしまいます。
一方で、
(Stream.from(0)++Stream.from(1)) take 10 foreach println
なんかは大丈夫なので、ダメな理由が分かりません。

>>516
f()の計算のどこかで名前渡しのパラメータを使う関数を介さないと
計算が止まらない。

def f(x:Int):Stream[Int] = {
return if (x<0) Stream(-1) else Stream(x) append f(x-1) append f(x-1)
}

>>517
ありがとうございます！感謝しきれません。
自分のコードでも、一カ所変更するだけでうまくいきました。

どういう機構でそうなるのか理解したいですが、
あいにくコップ本には遅延Streamの記述が見当たらない・・・。

>>518
＞どういう機構でそうなるのか理解したいですが、
>>517がほとんど答えだけど、もう少し詳しく解説すると、

Streamの++は引数を遅延評価しない。つまり、++が呼ばれる前に++の引数が評価される必要がある。ここで、
def f(x:Int):Stream[Int] = {
return if (x<0) Stream(-1) else Stream(x)++f(x-1)//++f(x-1)
}
の定義を見てみると、++の引数にfの再帰呼び出しが生で渡されてる。つまり、
f(x)をx >=0なるxに対して呼び出すと、x <0になるまで一気に評価されてしまう。コメントアウトしたままの
コードだと、たかだか1024個分の要素があらかじめ生成されてしまうだけなので大丈夫だけど、コメントアウトを
はずすと、fの呼び出し回数が指数関数的に増えていくので膨大な数の要素が生成されてしまうので、OutOfMemoryError
が起きる。

>>519
自己レス
誤：1024
正：1026
アホなミスしてしまったorz

atmarkitに書いてあるけどなぜScalaってゴミ機能満載にしたの？

Java厨が悦ぶから

糞言語なんだろ

糞サイトはどうでもいいけど、どっかの糞言語開発者も毎回同レベルのイチャモンをつけてくるから困る

Scala糞だし

お金稼ぎに使わない教養を積むために勉強する言語なんだから
いろいろ面白い機能が実装されてるほうが良い。
Scalaはちゃんと目的を果たしてるし、ゴミとか言われる筋合いはない

>>526
教祖様が起業したのはお金のためでしょ？

立場が違うと思うの。

>>526
Odersky先生は前からはっきりとScalaは実用のために作った言語だって言ってるよ
実際、そうじゃなかったらJavaとの互換性にここまで気を使わんだろうと思う

このインタビュー読むといいと思う
http://www.artima.com/scalazine/articles/origins_of_scala.html
純粋にアカデミックな言語(だけど実用的でない)であったFunnel(Scalaの祖先)と、実用的だけど
制限が多いGJ(Generic Java)の中間のアプローチを取ったのだと。

>>527
お金のためっつうか、それだけ本気でScalaを普及させたいんじゃないかと。なんつーか、これは
MLとか各所でのOderskyセンセイの言動を読んでの、あくまで個人的な感想だけど、関数型プログラミングを
産業界に本格的に持ち込むことに強い意義を見出してるんじゃないかという気がする。Scala VS. Clojure
みたいな喧嘩があったときも、関数型プログラミングコミュニティで内輪もめしてる場合じゃねえ(意訳)
みたいな事書いてたし。

そうだね。Cに対するC++のようなもんだ。Javaに対するScala。
関数型の眼見ればまあいろいろ筋の悪さはあるけど、
ぶつくさ言われつつもやはり広く使われると思うよ。
というかそういう筋悪なものでないと広く使われるようにはならないんじゃない。
そのうちC++に対するJavaのような、Scalaの後を襲う言語も出てくるだろう。

ISO申請せずに実用的と言われてもなぁw

規格化は時間がかかるし、そもそも規格の意味があるだけ
流行って処理系含めて周辺環境が多様になるのかも
まだ分からんでしょ

Java本体すらISO化しとらんのに

Javaのように書けて、JavaVM上で動いたらそれはScalaだよもん。

http://scalaza.com/?%C2%E81%B2%F3+Scala%BA%C2

http://www.y-adagio.com/public/standards/std_lst_jtp.htm
Javaだと、こんなのはあるよ。JIS TR X 0005

Scalaも安定して利用機関が増えたら、下記のパターンやる日が来るんじゃないかな。
http://www.ecma-international.org/publications/standards/Ecma-262.htm
http://msdn.microsoft.com/en-us/netframework/aa569283.aspx

Scalaで、対話型のサーバとコマンドをやりとりするクライアントを書こうとしてるんだけど、
何かそういう用途にうってつけの機能とかライブラリとかないかな。

ARM

EclipseのHeliosにPlugin入れてScalaの勉強はじめてみたんですが、
importの補完って自動でやってくれないんでしょうか。

コードをEclipseでスラスラ書いて、
ビルド→テストはsbtって感じがよさそうだったんですが…

>>539
Ruby勉強しなさい

importの自動補完ができるかどうかと、何の関係があるんですか？

SS本を見ると「例外は使うな、Optionにしろ」って書いてあるけど、
Noneにはエラーの原因とか入れられないよね。こういう場合はどうすれば？

nullは使うなの間違いじゃないか？

Optionより、Boxおすすめ。

Some以外つかうな
今後の互換性がない

どっかで例外をEitherでラップできるぜみたいなの見たことあるけど
どんなメリットあるんです？

EitherでMaybeモナドっぽいことやろうとしたら、

a.right.flatMap(...) みたいなことになってしまったのだが、
もっとスマートな記法はないのだろうか。

一方私はEclipseでスラスラという部分になんとも言えない違和感を感じていた

そんな私も今ではすっかり『Emacs + ENSIME + sbt』
なぜなら小指とCtrlは決して切り離せない特別な存在だからです。

>>545
BoxはLift使う限りでは問題ないのでは？

>>550
Box的なものをScala標準ライブラリに取り込む予定はないのだろうか。

BoxはLiftから分離されたでしょ？

>>552
知らなかった。今はどこが管理してるの？

sclala未経験募集してる求人ないの

Scala業務経験者なんて日本に何人いるんだ。

>>554
Scalaどころか、未経験者募集すら大変だといいうのにｗ

>>521-530
この記事の話ですよね？
http://www.atmarkit.co.jp/news/201009/13/spell.html
>「ScalaもClojureも非常に有望な言語だと思います。
>ただ、Scalaは機能が豊富すぎて、
>たくさんのゴミが詰まっているというのが個人的な印象ですね。
>Clojureは美しくてシンプルです。
>でも誰もWebアプリを書くのにClojureなんて使いませんよね？
>Railsがあるんだから、Railsでやればいいじゃんって話です。
>計算や重たい処理が必要な部分でClojureを使うなど、今後は、
>1つの言語が特定の1つのことを上手にやるという方向で進化していくのだと思います」

同じ事をやるのに元からあった方法と追加された方法があって
言語仕様が複雑というのはC++とScalaの共通の欠点ですね。
でもHaskellより実用に使われているからこの方針は正しいのでしょう。

ややこしいゲームシステムのほうがユーザが燃えるってのと似てるのかな

じゃあゴミを取り除いたシンプルなScalaのサブセットを考えようって思考実験すると
俺には取り除けるものが思いつかない

直行した機能一つ一つの存在感がでかいからゴチャゴチャしてるように見える

>>521-530
>>557
ここでいってるScalaのゴミってのは、Javaとの互換性の話なの？
だとしたらそれはゴミじゃないと思うんだけど

腐れ＠の記事を見ると言語自体が
糞って書いてあるなw

そういう大雑把な批判って、静的型フォビアか、関数型を理解できないか、なんだろうな
どうせOCamlとかHaskellのこともよく知らんのだろう

けどRailsの作者の話だろ？

いくつかのRubyのコードをリプレースしてみて分かったがやっぱりメンドイ。
respond_to?を大量に書かなくても済むようになったがそれでもメンドイ。
せめてif __FILE__ == $0 thenみたいなのが使えればテストが書きやすかっただろうに。
JVMの立ち上がりの遅さも手伝ってインタープリタの部分は使い物にならん印象。
betterJavaとして見ればとても良い言語だと思うけどね。

まー、Rubykaigi(カンファレンスみたいなもの)の記事ですのでねｗ

> なぜRubyだったのか？
>
>　Rubyで性能や安定性に不安はなかったのかという聴衆からの問いに対して、
> 「むしろMySQLやOracleが先にボトルネックになることがありましたね」と、
> Rao氏はエンタープライズ用途でもRubyが活用できるとした。
> また、なぜRubyを選んだのかという問いに対しては、
> 「色々な側面がある。巨大なコミュニティがあるのが大きい。
> Rubyなら、困ったことがあっても聞けば答えてくれる大きなコミュニティがある。
> Javaにはそれほど大きなものはない」と話した。
> 「それにJavaで書いたとしたら、もっとプロジェクトは長引いただろうね」。
>
>　DSLをRubyで設計したことについては、
>
> 「“ip.assign”というように、読めば分かるように書けるのでとても自然に感じるものができた」としている。
>　きちんとテストを書く文化とツールがRubyコミュニティにある点も重要だという。
>
>　「Rubyのようなオブジェクト指向は振る舞いをテストしやすい。
> Rubyには、非常に成熟したテストの文化とツールもあります。
> テストを書かなかったら、君は本当にRuby開発者かと言われてしまいますよね。
> テストが書きやすいというのは重要で、PerlやPHPだと“うん、テストね。後で書くね”となりがちです」
>
>　Scala、Clojureなど、JVM言語は候補にならなかったのか？ 講演が終わった2人に聞いてみた。
>
>　「ScalaもClojureも非常に有望な言語だと思います。ただ、Scalaは機能が豊富すぎて、
> たくさんのゴミが詰まっているというのが個人的な印象ですね。Clojureは美しくてシンプルです。
> でも誰もWebアプリを書くのにClojureなんて使いませんよね？
> Railsがあるんだから、Railsでやればいいじゃんって話です。
> 計算や重たい処理が必要な部分でClojureを使うなど、今後は、1つの言語が特定の1つのことを上手にやるという方向で進化していくのだと思います」
Rubyの魔術 − ＠IT
http://www.atmarkit.co.jp/news/201009/13/spell.html

>>565
テスト用のフレームワークくらいあるんじゃないのか？
Rubyでも今時、f __FILE__ == $0 ではテスト書かないでしょ？

>>565
SpecsやScalaTestみたいなテスティングフレームワークは使わなかった？
立ち上がりの遅さに関しては、sbtみたいなVM常駐型のビルドツールでカバーするのが良いかと思う
あと、インタープリタってREPLのことかな？あれは立ち上げっぱなしにしておいて必要な時にファイルをロード
する使い方が良いと思う

ScalaTestは使った。特に不満はないが俺がやりたいのはもっと簡単なことさ。
例えばEmacsで編集中の関数の断片をちょっと動かしてみる・・・とかね。
REPL立ち上げっぱなしの使い方はunloadの仕方が分からずに敬遠してた。
Emacsからスムーズに渡せるとなおいいんだが・・・
今度調べてみる。サンクス。

もっとScalaz使えよ

Ruby使いってのはeval-regionも知らずにEmacs使ってるもんなのかねえ
それともruby-modeにしかないと思っているのか

ensime使ってる場合は↓を.emacsの(require 'ensime)の後ろに追加
(define-key ensime-mode-map (kbd "C-c C-r") 'ensime-inf-eval-region)
(define-key ensime-mode-map (kbd "C-c C-b") 'ensime-inf-eval-buffer)

Scalaの内部DSLが読めないってRubyの作者がよく言えるな。鏡見ろよ。
って誰か言っておいて

ThoughtWorks社のMunjal BudhabhattiとSudhindra RaoってRubyの作者なの？

批判記事をRubyの作者にしたいやつがいるだけだろ

ttp://twitter.com/yukihiro_matz/statuses/25098333248
これのことじゃね？
matzにとって困難とは思えん
scala叩きたいがためにアホなフリしてるように見える

またやってんのかよw

Rubyはメタプログラミング始めるとわけわからなくなるけど、
Scalaは素でわけがわからないときがある、と
Scalaスケーラブルプログラミングのサンプルコードを見て思た。
(一応通読はした)
var a, b = new Hoge が
var a = new Hoge
var b = new Hoge
と解釈されるのは何の冗談かと……。

aが初期化されてない変数になるよりよほどいいと思う

Dim a, b As New Hoge

>>578
ぶっちゃけscala.Enumerationのためにあるような機能なので、正直不要と言えば不要な気がする。
実際Scalaプログラミングしてて、この機能使う必要があるのってscala.Enumerationのときくらいだし。
2.8の限定継続使い出すと、ときどきこれがあると便利な場面が無い事も無いが、そもそも限定継続自体
ごく一部のマニアプログラマ除いてまだほとんど活用されてないからな。標準ライブラリでambとかgenerator
みたいなのをサポートしてくれると嬉しいんだが…。

なるほど
val a, b = (1, 2)
と
val (a, b) = (1, 2)
で動作が違うわけね
これは確かにRubyから来た人は混乱するかもしれないな

つーか、val a, b = 1という記法があることに今気づいたけどｗ

最近Mとかいうのがところ構わず噛みついて
Rubyいいだろ？な？な？言えよほらいいだろ？

って喚いているのがひどくうざい

まー、「まとめて代入」は誤解とバグの元なのでC時代から使ってないな。

Scalaはいろんな機能を過剰に一般化してるように思う。

メソッドの演算子表記+演算子の結合順序ルール
+プレースホルダ構文
+implicit conversion
+case class+パターンマッチ+抽出子
+traitのスタック
+for式のわけのわからない構文

と、これだけ並ぶと、もはや脳のパーザが限界を超えてハングアップする……。

>>583
本人がRubyについて全く言及していない※にもかかわらず、
RubyがRubyがと騒ぐお前のようなやつの方がよほどうざい。

※今回の件限定で言えば、Rubyのことは知り過ぎてるから評価不能、
と最初に棚に上げてる。

>>585
真面目に「全て把握」しようとすると辛いんだよなー。
普段、「逆引き本」の類は馬鹿にしているんだが、
Scalaに限ってはそういうものが必要なのかもしれない。

Rubyについては持ち上げてるようで実際は貶してる書き込みが多いですよ

>>585
そんな難しい抽象化をやめて、二項演算子があって、Auto boxingで、継承はインターフェースで
パターンマッチがなくて、for構文はC互換にした素敵な言語ができるといいのにね！

ちょっと聞きたいんですが、
C言語やVBみたいな言語は構造化プログラミングを当たり前の時代にしましたよね
JavaやC#(Rubyでもいいです)でいえばOOPを当たり前にしたように見えます。

Scalaは何を当たり前にする事ができる言語なものでしょうか？
もちろん流行ったら、という前提で・・・

>>585

>>メソッドの演算子表記+演算子の結合順序ルール
言語仕様嫁

>>プレースホルダ構文
言語仕様嫁

>>implicit conversion
言語仕様とcategories typesの本1冊嫁

>>case class+パターンマッチ+抽出子
言語仕様嫁

>>traitのスタック
言語仕様嫁

>>for式のわけのわからない構文
言語仕様嫁

以上

>>591
それぞれの機能や表記がわからんなんて言っとらんわい。
そいつらを組み合わせて出てきたソースコードがカオス過ぎて、
1センテンス毎にドキュメントをひっくり返さないと分からなかったり、
検索キーワードすら分からなくて途方に暮れたりするのが問題なんだ。

591は何がしたいのやら

>>592

> それぞれの機能や表記がわからんなんて言っとらんわい。
> そいつらを組み合わせて出てきたソースコードがカオス過ぎて、
> 1センテンス毎にドキュメントをひっくり返さないと分からなかったり、
> 検索キーワードすら分からなくて途方に暮れたりするのが問題なんだ。

具体的に何がわからないの？それぞれの機能や表記がわかれば
組み合わせても一緒でしょ。つまるところ、理解した気になっているだけで
簡単なコードすら書けないんだよね？

Javaしかやってないとか、Rubyしかやってないみたいなやつが面喰らってるだけだと思うがね
一回Haskellやってカルチャーショック受けてくればいいのにと思うよ
そうすればScalaなんて、なるほどねーよくできてるねーって感じになるから

わけわかんない機能や概念が糞多いから、
初心者はぼくらのScalaから読み始めたほうが馴染み易いぞ

記号のオペレータがググれなくて困ることはまれによくある。

2.8.1 RC1 age

>>595
頑張ってるのはよく分かるつもりだが、
よくできてるかどうかは……悪く言えば、型理論と泥臭い現実のギャップを埋めるために
あれこれ仕様を追加したキッチン言語がScalaだという印象

まあ言語設計は決して間違ってはいないのだろうけど、
SMLやHaskellにある、単一パラダイムがゆえの優美さは当然残ってないね

機能がたくさんあってわけわかんないって人は、
全部の機能とか構文を等価値だと思って、全部覚えて使おうとしてるからよくなくて、
慣れている人は、ここはオブジェクト指向的に書きたいとか、
関数型的に書きたいとかの目的があって使う機能を選ぶわけで
先にそういう感覚を身につけるべきなんだよな
その点ではマルチパラダイム言語のScalaより先に機能が特化されている言語に触れたほうがいい

(´・ω・｀)

また自演か

Lift勉強したいけどいい本ある？
解説サイト全然ないし不安だけど

>>603
和書、洋書含めてもこれしか出てないんじゃないかな。
http://www.amazon.co.jp/dp/1430224215

>>603
概要とか設計思想を知りたいなら、この質問にマジレスしてるDavid Pollak本人の投稿とか参考になると思う。
http://stackoverflow.com/questions/2683914/why-would-i-use-scala-lift-over-java-spring

リクエストにGUIDを振ることのセキュリティ的な利点とか色々書いてあって、結構面白い。

全然面白くない

モノリシックvsモジュール
なんてデジャヴュ

どうでもいいが疲れていると記号が顔に見えてきて困る
特に_と<の組み合わせがヤバい

m< _, _ >m

(_<_)
逆さにすると顔っぽい

b(0,0);

(T,_.T)

>>604
それだと
本にない細かい部分に詰まったら即終了になりそうだね
使ってる企業はどうしてるんだろ

>>613
LiftのMLで質問するとか？

>>613
ソースを調べる。

>>591 はサーバーリソースの無駄だから圧縮したほうがいいと思う

これで↓

>>585
言語仕様嫁

以上

^^ まゆげ演算子(eyebrows)をこれからもよろしくね！

このトレイトを継承するならクラス、コンパニオンオブジェクト両方つくらなきゃだめだよ。
という制限をかけたいのですが、どうすればよいですか。

例えば、とあるDTOがあり、クラスの方でtoXml, validateを実装し、
オブジェクトの方でfromXml:Dtoを実装するというルールを作りたいのですが。

>>618
もちっときちんと書きなさい
曖昧だ

>>618
なぜimplicit conversion使わないの？

ごめんなさい。

trait Dto {
def toXml: Node
def validate: Option[ValidationException]
def fromXml(node: Node): Dto
}
class HogeDto extends Dto {
override def toXml: Node = {}
override def validate: Option[ValidationException] = {}
override def fromXml(node: Node): Dto = {}
}
てな感じなら問題ないけど、
できるならHogeDto.fromXml(node)てな感じで使いたいのでコンパニオンObjectでfromXmlを定義したいのです。
そうすると私の中では
trait Dto1 {
def toXml: Node
def validate: Option[ValidationException]
}
trait Dto2 {
def fromXml(node: Node): Dto
｝
class HogeDto extends Dto1 {}
object HogeDto extends Dto2{}
となってしまい、Dto1を継承するならDto2を継承したコンパニオンオブジェクトを作らなければいけないというルールを定義したいと思い
こんな質問をしてみました。

>>620
implicit conversionはまだ私の理解不足のためか、この場合（どの場合もそうですが。。）使いどころがわかりません。
もう少し御教授いただけますか。

trait DtoBase {
abstract class AbstractDto {
def toXml: Node
def validate: Option[ValidateException]
}
type Dto <: AbstractDto

def fromXml(node: Node): Dto
}

object HogeDto extends DtoBase {
class Dto extends AbstractDto {
def toXml = ...
def validate = ...
}

def fromXml(node: Node) = ...
}

コンパニオンを作らなきゃダメとはちょっと違うが
こんな感じで？
HogeDtoはDtoの実装とfromXml両方作らなきゃダメ

レスありがとうございます。
そのやり方は私にはなかったので、勉強になります。
只、ちょっと実装側にとって複雑な感じがします。

とりあえず、コンパニオンオブジェクトを使用しないで、
trait Dto {
def apply(node:Node): Dto
def toXml: Node
def validate: Option[ValidationException]
}
にしようと思っています。

scala+LiftでMySQLのDBとやりとりしたいんですが、
scala2.7.7からdbcって無くなってます？
もし無くなってたら、DBアクセスの方法を教えて頂けませんか？

net.liftweb.mapper.DBを使う事で解決しました。

trait Hoge {
val i: Int
}

class Fuga extends Hoge {
val s: String = "1"
implicit def s2i(s: String) = s.toInt
val i = s
}
だとコンパイラは通らないのに
trait Hoge {
def i: Int
}

class Fuga extends Hoge {
val s: String = "1"
implicit def s2i(s: String) = s.toInt
def i = s
}
だと通るんだがよくわからない、理由を教えてくれ

>>626
前者はプロパティのオーバーライド扱いだからNG
後者はメソッドのオーバーロードだからOK

ごめんやっぱりよくわかんない
> 前者はプロパティのオーバーライド扱いだからNG
プロパティのオーバーライドだとimplicit conversion働かないの？
> 後者はメソッドのオーバーロードだからOK
オーバーライドされてないかな？abstract無くてもコンパイル通るけど…

上の例
val i: Int = s
だと働くっぽい。
型推論の問題の気がしてるんだが違うのかな？

型推論の結果
val i: String = s
でオーバーライドしちゃってる

defの場合は型推論の結果
def i: Int = s2i(s)
にしてくれてますよね、その違いはなぜ起こるのでしょうか？

パラメータが
s: String
戻り値が
i: Int
のメソッド扱いだからじゃないかな？

多分trait側だと
パラメータなしの
戻り値が
i: Int
のメソッド扱い

ﾜｶﾝﾈ
traitの　def i: Int　が
> 多分trait側だと
> パラメータなしの
> 戻り値が
> i: Int
> のメソッド扱い
で
classの　def i = s　が
> パラメータが
> s: String
> 戻り値が
> i: Int
> のメソッド扱いだからじゃないかな？
と言っているの？（これがわからん）

つまり馬鹿は使うなってことだ

>>632
短縮型で書きすぎてて
class側でシグネチャ(引数と戻り値)の違う新たなメソッド定義してることになってる
だからオーバーロードになってる

Source.fromInputStream(System.in).getLines().collect
本のサンプルコードがコンパイルできない。オワタｗｗｗｗ

traitの　def i: Int　は抽象メソッドだから
> class側でシグネチャ(引数と戻り値)の違う新たなメソッド定義してることになってる
だとコンパイル通らないんじゃないですか？
うちの環境だと
val fuga = new Fuga
fuga.i
はStringの"1"じゃなくIntの1を返してるけど

じゃオーバーロードじゃなくて普通に抽象メソッド実装してるってことじゃね？

うむ、でもvalの場合は実装してくれなくて
valとdefでどうして型推論に違いが出るんだぜ？って質問してたような気がするが
もう眠いからいいやおやすみ

>>632
今度から仕様書熟読してから質問しろ。仕様書7.3見ろ

implicit def s2i(s: String) = s.toIntを定義したことにより
暗黙の型変換を持つ関数が定義された。
traitのiの型がdefなので上書き可能なため、implicit conversionが
成立しコンパイルされる。
しかし、型変換された新しいオブジェクトが代入されるが、コンパイラ
の最適化により元のInt型にされている。

これを裏付けるように、def iとdef s2iを逆にすると定義がないって
怒られる。明らかにimplicit conversionの影響を受けているはず

class Fuga extends Hoge {
val s: String = "1"
def i = s
implicit def s2i(s: String) = s.toInt
}

私は気が付いてしまいました。
Ruby の動的型付けは多くのエラーを引きおこすことに。

そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。
95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。

その上、Rails では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。
高いテストカバレッジを確保しているにも関わらずです。

これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。
それなのに開発コミュニティはそのことに見向きもしません。

私は他の言語も見てみようと思うようになりました。
そんな時に Scala と出会いました。
Scala を使ってみて、これこそが私が求めていた言語だと思いました。

仕様書とか読んだことないなぁ。何ページくらいあるんだろ。

そして私が部下に教える言語もScala
なぜなら私の部下も大切ないやなんでもない

大切な部下でScala。

>>640
http://www.infoq.com/jp/news/2008/03/liftweb

JavaOne プレビュー：Javaの関数プログラミングについて、GridGainのCEOであるNikita Ivanov氏とインタビュー
http://www.infoq.com/jp/news/2010/09/functional-programming-and-gridg

DB接続のとこ調べてんだけど、
https://docs.google.com/fileview?id=0B5FoA4ICfkLjZTJhMDZhZGItODY0Mi00OTBhLTkxNzAtMzZiNjJiZmVmMjc2&hl=en
http://scala.sygneca.com/libs/dbc

APIにScala.dbcとかdbc2ってないんだけど、なんで？
http://www.scala-lang.org/api/current/index.html

ごめん自己解決した
まだ検討中の段階で公表はしてないってことがちゃんと書いてた
dbc2も策定中だから今はJavaと同じやり方でやっときます

javaのメソッドで可変長引数を扱うものがあって、
かつオーバーロードしてるメソッドをscalaから呼ぶことってできるの？
なんか曖昧な参照でダメって怒られてしまう。

>>648
どういうので駄目だった？
そういう場合もありえるかもしれんが、たとえば以下のようなコードはＯＫだった

public class Overload {
public void foo(Object a, Object... args) {
System.out.println("foo1");
}
public void foo(String a) {
System.out.println("foo2");
}
}

あ、呼び出し側のコード書いてなかったけど、こんな感じね
scala> val x = new Overload
x: Overload = Overload@15e6691

scala> x.foo("foo")
foo2

scala> x.foo("foo", "bar")
foo1

public void validate(final Object validatedObject)

↑ミス。すまん。

java側
public void foo(final Object obj)
public void foo(final Object obj, final String... strs)

scala側
foo(obj)

ってやると「ambiguous reference to overloaded definition」と怒られるのだ。

2.7.7の頃だけどここで話題になってるね
http://stackoverflow.com/questions/2159248/spurious-ambiguous-reference-error-in-scala-2-7-7-compiler-interpreter

ま、そもそも可変長引数のメソッドをオーバーロードするのは余り好ましくないってのがSunの指針っぽいけど
http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/language/varargs.html

2.8.1 RC2 age

ScalaはJavaの置き換えにはならないけど、
Java8までずれ込んだJavaラムダ式までの代替には有用だろうね。
Java7にクロージャが入らなくなった事で逆に市民権を得たかな。

>>655
別にクロージャ云々は別の言語でもできるし
どうでもよい。型推論やもっと他のことを
見なさい

見なさいって非ユーザからはそれくらいしか注目されて無いような・・・

Javaでクロージャ導入されたらScalaいらないよね。そうだよね。わかるわかる。













次の方どうぞレベル

非ユーザと言えばどんなトンチンカンな主張も許されるなんてわけがないだろう？

関数型と手続き型の違いなんてそんなもんだ

確かに言語としてのJavaがC#程度に強力ならScalaこんなに注目浴びてなかったろうな

>>661
F#がScalaに比べてそれほど注目を集めていないのもその辺に原因があるんだろうね
テキトーな印象としては、ScalaとJavaの力の差を10とすると、F#とC#の力の差は3くらいな感じ
パターンマッチングとかも便利なんだが、ファーストクラスの関数とかに比べて強力さを少し説明しづらい
んだよなあ。

F#が遅延評価だったりしたらそれはそれでびっくりだったんだが。

F#にtraitみたいなのある？
あるならちょっと勉強しようかな

いまだにtraitをextendするのには違和感がある。
そこはincludeか何かだろう・・・

>653
ありがと。
http://stackoverflow.com/questions/2159248/spurious-ambiguous-reference-error-in-scala-2-7-7-compiler-interpreter
で対応してる方法でクリアできたよ。

scala-armについてググってたら、「あれってモナドじゃないよね」とか
「for内包記法の悪用なんじゃないの（英語）」的な声を散見したんだけど、
実際のところどうなの？

教えて識者の人！

>>667
モナドじゃないよねってのは、たぶんscala-armがモナド則を満たしてないって事かと
モナド則ってのは、Scalaっぽい表記で言うと
1. unit(x).flatMap(f) == f x
2. m.flatMap(unit) == m
3. m.flatMap(f).flatMap(g) == m.flatMap{x => f(x).flatMap(g))
の三つを満たしているいことを指すが(unitはモナドのインスタンスを構築する
ための1引数メソッドだと思ってくれ)、これのどれかあるいは全てをscala-armが満たしてない
とかそういう話ではないかと。確かめてないからほんとにそうかわからないけど
for内包記法の悪用じゃないの？ってのは、おそらくモナド則に従ってないものをfor内包
記法で書けるのは良くないってことなんじゃないかな。実際の批判読んで無いからこんな
ことくらいしか言えないけど。

>>668
このへん。
http://twitter.com/okomok/status/24398921185
http://polyglot-window.blogspot.com/2009/03/arm-blocks-in-scala-revisited.html

モナド則を満たしてないと、具体的にはどういう弊害があるの？

>>669
モナド則みたさないとかありえないだろ
この糞ライブラリ作った奴だれよ？

scala-armは
http://github.com/jsuereth/scala-arm
これのことだね。ソース見てみると、ManagedResource[+R]#flatMapのシグネチャが
def flatMap[B, To](f : R => B)(implicit translator : CanSafelyFlatMap[B,To]) : To
になってて、確かにモナド則満たしてないっぽい気がするなあ。ただ、そもそもドキュメント自体に
"It is monadic in nature, although not a monad, and provides several combinators to use with other managed resources."
と書いてあって、一応、モナドそのものじゃないよと明言してるので、その事自体を責めるべきではないと思う。後はこの事が
for式で使う上でどのような問題をはらんでいるかだけど、これは使ってみないとよくわからないなあ。

あ、ごめん。s/ドキュメント自体/ソースコード自体/

>>671
『「モナドっぽく」使えるモナドじゃない何かだけど、他のmanaged resourcesと連結する
便利機能があるんだよ』という訳であってるかな？

モナドは最近少し勉強をしてるけど、モナド則に従ってないモナドっぽいもの、
みたいのがなぜ「ダメ」なのか、みたいなのがまだよく分からない。
他のモナドと特定の組み合わせ方ができない、とかそういう感じなのか。

ちなみに、上の指摘をしてた方もARMライブラリを作ってるぽい。
こっちはきちんとモナドになってるのかな。
http://github.com/okomok/mada

ゼノブレイドスレかと思ったら違った

擬モナド

山本モナド

モナドグランプリ

　　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣￣￣
　　（　´∀｀）＜　モナドってなんか美味しそう
　　（　　　　） 　＼＿＿＿＿＿＿＿＿＿＿＿
　　｜ ｜　|
　　（_＿）＿）

食べ物だとしたらまんじゅう系だな。

モナドセレクション

Scalaで異常系ってどう書くのが正しいんだろう？

Box使って、既存ライブラリの例外をラップしつつ、Failureをチェーンしていけばいいのか、
と思ったんだけど、Failure[Int]を ?~! してFailure[String]で返す、みたいなことをやろうとすると
（当たり前だけど）型が合わないって怒られるし、そもそもJVMがやってる例外を投げる処理を
自分で書いてるのも同然なので本末転倒感が。

例外のいいところって、例外を投げたコード位置と説明をパッケージできるところだと
思うんだけど、Option/Boxを使って似たようなことを（スマートに）できないのかな？

？？
「異常系処理を正常系処理と明確に分けて記述できるのがいいね」って誰かが
言い始めたから取り入れられたんですよね？

関数型で処理を実行している場合、正常系の一形態としてエラーを無視すると
いうケースが有用な場合があるよという例が一人歩きして混乱を招いている感じがあるます

例外処理って
>「異常系処理を正常系処理と明確に分けて記述できるのがいいね」って誰かが
>言い始めたから取り入れられたんですよね？

>>682
その辺をもうちょい掘り下げて説明していただけるとありがたい。

IntとDoubleを割り算するのをジェネリックにしたいのですが、Fractionalを使うのは無理ですか？

Doubleは当然OKです。
scala> implicitly[Fractional[Double]].div(3,2)
res14: Double = 1.5

Intはぞのままじゃダメっぽいです。
scala> implicitly[Fractional[Int]].div(3,2)
<console>:6: error: could not find implicit value for parameter e: Fractional[Int]

欲しいのは、切り捨てた結果です。
scala> 3/2
res15: Int = 1

自分でTruncate[T]みたいなのを定義するとしても、
どうするのが筋がいいのでしょうか？

http://www.scala-lang.org/node/114
を参考に自分でつくってみましたが、無駄に長い・・・。

++++++++++++++++++++++++++++++
trait Truncate[A] {
def div(x: A, y: A): A
}
object Test extends Application {
implicit object DoubleDiv extends Truncate[Double] {
def div(x:Double,y:Double):Double = x/y
}
implicit object IntDiv extends Truncate[Int] {
def div(x:Int,y:Int):Int = x/y
}
def test[T](x:T,y:T)(implicit num:Truncate[T]) = num.div(x,y)
println(test[Int](3,2))
println(test[Double](3.0,2.0))
}

あと、Fractional[Double]に対応するのはIntegral[Int]だと分かったのですが、
上の文脈でうまく使えない・・・orz

これですが。

scala> implicitly[Integral[Int]].quot(3,2)
res0: Int = 1

>>687,688

こんな感じでどう？

import scala.math._
import Numeric._
object Test extends Application {
implicit val DoubleIsIntegral = DoubleAsIfIntegral
def test[T:Integral](x: T, y: T) = implicitly[Integral[T]].quot(x, y)
println(test(3, 2))
println(test(3.0, 2.0))
}

>>689
前回も助けていただいたのです。ありがとうございます。
DoubleAsIfIntegralとかうさんくさいですよね・・・。
多重定義できれば一番いいのですが、

def test[T:Integral](x:T,y:T) = implicitly[Integral[T]].quot(x,y)
def test[U:Fractional](x:U,y:U) = implicitly[Fractional[U]].div(x,y)
println(test(3, 2))
println(test(3.0, 2.0))

これが通らないのです・・・。

あと、実装をみるとBigDecimalにキャストしてるのもむかつきます。
http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_final/src//library/scala/math/Numeric.scala

>>690
ややトリッキーだけど、

import scala.math._
object Test extends Application {
sealed abstract class FractionalOrIntegral[T]
case class IsFractional[T](ev: Fractional[T]) extends FractionalOrIntegral[T]
case class IsIntegral[T](ev: Integral[T]) extends FractionalOrIntegral[T]
implicit val IntIsIntegral = IsIntegral[Int](implicitly[Integral[Int]])
implicit val DoubleIsFractioanl = IsFractional[Double](implicitly[Fractional[Double]])
def test[T:FractionalOrIntegral](x: T, y: T) = {
val ev = implicitly[FractionalOrIntegral[T]]
ev match {
case IsFractional(ev) => ev.div(x, y)
case IsIntegral(ev) => ev.quot(x, y)
}
}
println(test(3, 2))
println(test(3.0, 2.0))
}

という風にすれば一応できないことも無い。ただ、ここまでする手間に見合うかは疑問だが。

x match { x:Int => ...; x:Double => ... }
とか、ダメダメなパターンマッチは思いついてましたけど、ここまでやるか・・・（笑）
この「できそう」と「できた」のギャップの著しさはC++のそれと似てて、初心者に厳しいですね。

>>692
はFractionalOrIntegralのインスタンスにするために、いちいち個別に
implicit val IntIsIntegral = ...
とかしなければいけなかったのを改良してみた。これで、implicitなIntegral[A]や
Fractional[A]のインスタンスがあれば自動的に取り込めるようになった。

import scala.math._
object Test extends Application {
sealed abstract class FractionalOrIntegral[T]
case class IsFractional[T](ev: Fractional[T]) extends FractionalOrIntegral[T]
case class IsIntegral[T](ev: Integral[T]) extends FractionalOrIntegral[T]
implicit def AIsIntegral[A](implicit ev: Integral[A]) = IsIntegral[A](ev)
implicit def AIsFractional[A](implicit ev: Fractional[A]) = IsFractional[A](ev)
def test[T:FractionalOrIntegral](x: T, y: T) = {
val ev = implicitly[FractionalOrIntegral[T]]
ev match {
case IsFractional(ev) => ev.div(x, y)
case IsIntegral(ev) => ev.quot(x, y)
}
}
println(test(3, 2))
println(test(3.0, 2.0))
println(test(3.0f, 2.0f))
}

2.8.0-finalで、正規表現マッチを大量に並べたパターンマッチを作ったら
コンパイラが固まったんだけど、この現象って既出？

>>695
tracに関係ありそうなキーワードで検索かけた限りでは引っかからなかった。
現象再現するコード提示してくれれば、代わりにバグ報告しても良いよー

>>696
ありがとう、ではお言葉に甘えてお願いします。

http://www.geocities.jp/dryad_saddle/shogi/AkaraLogParser.scala.txt
汚いコードでお目汚し恐縮ですが、@tailrec def parseAkaraLog()とこです。
orElseで分けてあるところをつなげて、全て一つのmatch文に収めてやると、
scalacでのコンパイルが途中で沈黙したり。再現しますかね？
どちらかというと何かの計算量が爆発してる感じがしますが。

あと、実はもう一つあって、これを最初にスクリプトとして書いていて、Windows XP上で
　scala AkaraLogParser.scala < akara2010.log > akara2010_jp.log
みたいに実行したら、実行完了後も、何かのjavaプロセスが_jp.logの方をロックし続けて、
二回目以降に「プロセスが占有して」云々というエラーが出て実行できなくなる
現象がありました（タスクマネージャから強制終了してやるとなおる）。

なんかこっちは既出そう。。

>>697
現象再現できました(Scala 2.8.0.final on jdk1.6.0_20 on Windows 7)。少なくとも、数分以内にはコンパイル
が終わらない事を確認しました。どっかで無限ループしてるのか、あるいは、なんかの理由で指数関数的に
計算量が爆発して、終わらないように見えてるのか…。現象を再現できる最小のコードにしぼる必要があるので、
多少時間かかりそうですが、報告しときます。

>>694
実際の目的に合わせて修正してみました。

object Divisible {
case class IsFractional[T](ev: Fractional[T]) extends Divisible[T]
case class IsIntegral[T](ev: Integral[T]) extends Divisible[T]
implicit def XIsIntegral[X](implicit ev: Integral[X]) = IsIntegral[X](ev)
implicit def XIsFractional[X](implicit ev: Fractional[X]) = IsFractional[X](ev)
def impl[T](x:T,y:T)(implicit ev: Divisible[T]) = ev match {
case IsFractional(ev) => ev.div(x, y)
case IsIntegral(ev) => ev.quot(x, y)
}
}

trait Divisible[T] {
def div(x:T,y:T)(implicit ev:Divisible[T]) = Divisible.impl(x,y)(ev)
}

class Test[T](a:T)(implicit num:Numeric[T], ev:Divisible[T]) {
def get(b:T) = ev.div(a,b)
}

val t = new Test(2.0f)
println(t.get(3.0f))

なんかextends Divisibleがぐるぐる回ってる感じで、大丈夫かよ、と思いますが一応通ります。
もっと言うと、 RichNumeric = Numeric with Divisible
というmixinしたtraitが欲しい訳ですが、なかなか難しくて・・・。

ていうか、みずしまさんなのですね。
『Scalaで型レベルプログラミング』の最後に
「本格的にScalaで型レベルプログラミング するのは現時点では時期尚早」
ってあるのに見事にはまってます・・・トホホ

2.8.1 RC3

RCの意味が解ってない。

きちんとバグはバグで修正しろ

ベータでいいだろ普通にこれ

ListからVectorに変換したいのに、toVectorというメソッドはありません。
要素ごとに自分で構築するしかないのでしょうか？

たとえば下は通りませんが、コレクションのどれかを経由すれいいとか。
val v:Vector[Double] = List(3.2,1.2).toIndexedSeq

>>705
val v = Vector(List(3.2,1.2): _*)

構文が変態すぎて意味わからん
Lisperなら普通に理解できたりすんの？

Lispの構文はむしろ単純だよ……ただ、S式はあまりに単純すぎるので
逆に読みづらいとも言われるだけ

>>707
>>706のは、可変長引数を取るメソッドにコレクションを渡すために
:_*という専用の記法があるというだけの話だが、変態という程のことか？むしろ
簡単な話じゃないか

短く書けた方がいいと記号を使いだすと、ろくなことにならない
ってのは歴史が証明しまくってるんだけどねぇ。

展開構文なんて他の言語にもあるだろう
まさかScala特有だとは思ってないよな

Scala特有だろうとなかろうとそれはどうでも良くて

C系の言語と比べて、構文もそうだし、概念にしても想像つかないやり方ばかりなんだ
コード数行読むだけで行き詰まる

構文逆引き辞典つくれ
おまえに毎日このスレに5個づつくらい貼る作業を与えてやる

:_* でぐぐって結果が出れば良かったのに。

レス遅くてすみません。706です。
自分はこの記法知ってましたが（思いつかなかったけど）、
「要素ごとに自分で構築する」のシンタックスシュガー
って感じがします。

要素数が巨大な場合は不自然な感じがするので、きっと他のやり方があるに違いないと思っています。
他に思いついたらまたお願いします。

今のところ、ひとつ思いついてるのは
val vec = Vector.empty[Int]++List(1,2,3).toIndexedSeq
です。

間違えた。質問者（705）です。

>>707,712
Lispじゃないけど関数型のノリで入ると習得はすごく楽だと思いますよ。
使いこなすには経験積んで細かいテクを叩き込まないと難しそうですが。
（自分はまだこの段階）

>>714
可変長引数は内部的にはコレクションにまとめて渡してるだけだし、
>>706のソースはList.apply()の結果をそのままVector.apply()に渡すように
コンパイルされるので、そんなに気にする必要はないと思うが。

>>718
へぇ、そうなんだ。勉強になりました。

構文が複雑すぎて、しばらく使わなかったらすぐに忘れそう

そういう時は、チートシートを見ればいいよ。

なので、誰かいい感じのチートシートを紹介しろ。

チートシートを探しましたが3種類しか見つかりませんでした。
一番上は初代スレ860のリンク先の更新版ですね。

=Scala= CHEAT SHEET v0.1
http://www.geekontheloose.com/wp-content/uploads/2010/02/Scala_Cheatsheet.pdf
http://cheat-sheets.org/saved-copy/Scala_Cheatsheet.pdf
Cheat sheet for scala syntax
http://anyall.org/scalacheat/
Scala to Java Cheat Sheet
http://www.softwaresecretweapons.com/jspwiki/scala-to-java-cheat-sheet

>722
: _* が載ってるのが一つもないじゃん。

>>723
読んだとき分かりにくいというのには同意するし、確かに忘れます。
>>715
で出した代替案とかは公式のAPIを探索すれば原理的には探し出せるので、
そういう意味でいいんじゃないでしょうか？

汎用言語と思って使い始めると意外なモノがなくて苦労するよな。
少し前使ってたときはFTP関係とIME関係で詰まって放棄してしまった。
Javaのプリプロセッサだと割り切ればいい言語なんだが・・・

だれか、
本当に役にたつ チートシートを作ったら、ヒットするんじゃない？

で、言語のお遊びみたいなのを卒業したら、
次は実践的なＴＩＰＳ集だな。

Scala逆引き辞典
みたいなの。

FTP関係とIME関係が言語で用意されてたら逆に汎用言語ではなくて
目的が限定された言語のような期がするが

基本的なものが出揃うまで、まだ時間がかかりそうってこと？

>>725 >>727
それは利用者が少なくてライブラリが少ないという話では

>>728
基本的なものというのが用途によるんでしょ
Javaがサーバーサイドで使われているのなら、その用途に関しては揃っているんじゃないの

IMEは必要に迫られたことはないが文字コード変換用のフィルタはperlかPHP並の
モンが登場して欲しいところだな

Windowsプログラミングがしたいなら、素直にC#使えばいいと思うんだ。

うわー閉鎖的だなー

ファーザー「.Net Frameworkがもてるからもてる」
『.NET Framework 1.0、1.1、2.0、3.0 または 3.5 用の更新プログラムをインストールしてください』
オンナスキー「…これは新手のDLLヘルってやつじゃないのか？」

2.8.1 RC4 age
RC名乗っちゃいけない気がするんだ。
Bata名乗れ。

ばた？

2.8系をこれからさわり始めようと思うんだけど、IDE使わない場合の
ビルドツールのおすすめってなにかな？

sbtは2.8だと使えないみたいな話もあるけど・・・

『sbt？そんなビルドツールで大丈夫か？』

『David Pollakは言っている、Mavenを使えと！』

>>736
普通に使えるから大丈夫

>>737
Mavenはあの長大なpom.xmlを見るだけで敬遠しちゃうんだよなー

>>738
とすると使えない云々は昔の話なのか。

ところで、sbt使って開発したとして、完成したプログラムはどうやって実行するのが普通？
「sbt run」だとごちゃごちゃとメッセージが出力されてうっとうしいんだけど
代替手段がよく分からない。scalaコマンドも引数指定面倒だし。

0 to Int.MaxValue
ってやると空のRangeが返って来るんだけどなんでなん？バグ？

ほんとだ、(0 to Int.MaxValue).lengthで-2147483648が返ってくる
Range.scalaの74行目
＞def length = fullLength.toInt
でオーバーフローしてるっぽい（scala2.8.1RC4）

某所で紹介されてた「type -->[A,B] = PartialFunction[A,B]」で、
「val pf: String --> String = { case "": ... }」って書けるのは何で？

Type[A, B]
は
A Type B
って書けるようになってる。

>>743
なるほど。ほんと何でもアリだな・・・。

>>739
sbtはデフォルトだと2.7.7がインストールされる
Scala2.8使うには、対話モードで 'set build.scala.versions 2.8.0' して
'reload' すると2.8がダウンロードされる。
build.propertiesも更新される。あとは '+compile' すれば完了

コンソール出力ごときでストレス感じるなら
いい感じにIDE対応するまで大人しくしてれば

IDEやだー
ゴスリングに見捨てられても僕らは死ぬまでイッイイイッイーマックス
大丈夫だ、問題ない。

そんなemacsで大丈夫か？

一番いいmacsを頼む！

つYmacs

NetBean6.9.1とプラグインでLiftはじめようとしてるけど
http://sourceforge.net/projects/erlybird/files/nb-scala/

ぜんぜんわからん

プログラムを可能な限りextractorで実装したら、珍妙なコードになって面白い。

IDEAの補完がもたつくの俺だけ？
補完の遅延とか同じ設定でJavaだとさくさく。なんでぞ

というか、Scalaコードをまともに編集できるIDEって存在するの？
IntelliJ IDEAがそうなの？

>>753
現時点でScalaに一番ちゃんと対応してるのがIntelliJ IDEA
Java-Scala言語間横断した名前変更とかもちゃんと機能するのは素直に凄い
ただ、ある程度PCの性能を要求するので低スペックPCには向いて無い。

EclipseとNetBeansだったら、どっちがまとも？
Scala 2.8で比較するとして。

vimかなぁ

Eclipseは普通に編集できるようにするだけで苦労するレベルだった
Emacsかなぁ

Eclipseで普通に編集するだけでも、IDEと格闘するレベルの努力が必要だったのは、
Scala 2.7系時代の話。

2.8系になってからは、……知らん。

Emacsはそれ自体使い始めるまでが苦労するからなぁ
面倒くさくないのならIDEAかなぁ

今まで使い慣れているという理由以外でEmacsを選ぶ理由はあんまりないと思う。

口車に乗せられてIntelliJ IDEA入れてみてみたが、地味すぎて死にたくなる。

地味っつーかなんか使いづらいんだよな

Emacsはヌーの絵が嫌い

あれがアルパカだったら・・・いや、なんでもない

IntelliJだが、補完とかはまあまあ安定している気がするが、
何かの拍子に一度駄目になる（空白の補完ポップアップが出るようになる）と
再起不能っぽい。

あと、上にも同じ事書いてる人が居るが、かなり遅い。

TwitterだかGoogleだかが使ってるとかいうから試したけど
3日頑張ってEclipseに戻した

64bit IDE+JVM だと、ClientVMないから余計厳しいかも

今日の構文
(1 to 10).foldLeft(1) { _ * _ }

この肛門みたいな構文の意味だれか教えろ
foldLeft関数から教えろ

>>768

10!

答えちゃうねん
仕組みやねん

foldというのは折り畳むという意味だな
最初に、引数の要素(単位元になることが多い)と、
レシーバーの一つ目の要素を使って計算して結果を出す
次はその結果とレシーバーの二つ目の要素を使って計算する
これを最後まで繰り返す
foldLeftというのは左から処理していくということだ
foldRightというのもあるが末尾再帰でないから、
できればfoldLeftを使ったほうがいい
関数型言語の基本的な関数の一つだな

>>770

「肛門みたいな」が問題なら、

(1 to 10).foldLeft(1) {(ret, i) => ret * i }

の略記法が、

(1 to 10).foldLeft(1) { _ * _ }

ってわけ。

親切にありがたいけど、　まだわかんない

def fact(n: Int): Int = {
　return (1 to n).foldLeft(1) {_*_}
}

fact(0)としたとき、この式でなんでちゃんと1が返るのか読み取れない
最初にfoldLeft(1)の1とnの0を掛けて0になっちゃわない？

絵で描いてみろ

いや、それは単に空のレシーバーに対しては引数の値がそのまま返るというだけ

関数型言語はライブラリのコードが簡単だから、
ソースコードを直接見て覚えたほうがいいんだけど、
Scalaはその点でコレクションのコードを見てもさっぱりわけわかめだから、
関数型の動作をScalaで覚えるのはあまりおすすめしない

>>773

foldLeftの定義を書き下してみると、こんな感じになる

def foldLeft[A, B](list: List[A], init: B)(f: (B, A) => B): B = list match {
case x::xs => foldLeft(xs, f(init, x))(f)
case Nil => init
}


次のようにListが空の場合、

foldLeft(List[Int](), 1)(_ * _)

定義から明らかにinitをそのまま返すので、結果が1になる。foldLeftは

init (list.size == 0の場合)
f(init, x(0)) (list.size == 1の場合)
f(f(init, x(0)), x(1)) (list.size == 2の場合)
f(f(f(init, x(0)), x(1)), f(2)) (list.size == 3の場合)
...
となる値を返すような関数なので、リストが空の場合initがそのまま返される、という言い方もできる。

>最初にfoldLeft(1)の1とnの0を掛けて0になっちゃわない？
このレス見ると1 to 0がRange(0)みたいなのを返してると勘違いしてるんじゃないか？

>775
ソース見るなら、2.8より前のだな。

2.8のコレクションライブラリは、コードの重複排除と拡張性を手に入れた代わりに
実装がやけに読みづらくなってるからなあ。ユーザ側としては間違いなく使い易くなってると
思うんだけど、いざ実装追いたくなったときにめんどいよね

2.8.1.final

2.8.1
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ !!!!!

akka 1.0もすぐ？

関数型の記述ができるようになるためにはどうやって勉強したらいいかな？
関数型で書かれたアルゴリズム本とか誰か知らない？

関数型のアルゴリズム解説というと、ML扱ってる「関数プログラミングの楽しみ」かな。

ML自体の説明は、
http://min-caml.sourceforge.net/tutorial-ml-1.htm
http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/class/isle4-05w/mltext/
http://ocaml.jp/チュートリアル

>>783
ありがとうございます。
まずHaskellから勉強する必要がありそうですね。

Haskellはちと方向が違う

『関数プログラミングの楽しみ』ってHaskellの本だよね？

やっと hellolift できたお！
最初Mavenでアーキタイプ指定してプロジェクトをダウンロードして、そのあと SBT で
sbt update
sbt jetty-run

ってやったんだけど、これ全部SBTでできないの？
前にSBTだけで構築しようとして試行錯誤したときは
sbt jetty-run で jetty がねーよってエラーでてダメだったんだよね

既存のアルゴリズム本を関数型言語で書き直したみたいな物があれば一番いいんだけど、そんなのないよね？

洋書ならあったような

Javaではメンバー変数はデフォルトprivateで、それが「良い仕様」って事になってたと
思うんだけど、デフォpublicなScalaはなんか思想か解釈が変わったの？
どう気持ちを切り替えたもの？

privateだったっけ？

>>790
Java の場合、フィールドを public にしたら、後で、値の取得・設定時に何らかの処理を挟みたくなっても呼び出し側の
コードを getter/setter 呼び出しに変更してもらう以外に行う術がない。
だから、フィールドに直接アクセスさせずにあらかじめ getter/setter 経由にしておく。
一方、Scala の場合、呼び出し側のコードを変更することなしに、フィールドをプロパティに変更するだけで可能になる。
だから、Scala の場合はデフォルト public で問題ない。
と解釈している。

>>791
Java の場合、デフォルト(公開識別子省略時)はパッケージ private だね。
ただ、>>790 の言う「メンバー変数はデフォルトprivate」の部分は、「フィールドを書くときには private を明示的に付けて
宣言するのが良い仕様のデフォルト(標準)」と言っているんだと思う。

>>790
Scalaで外部に公開される変数(private[this]以外)を宣言すると、
private[this]なフィールドとアクセサメソッドが自動で生成される。

class Hoge {
var piyo: Int = _
}
↓
class Hoge {
private[this] var piyopiyo: Int = _
def piyo: Int = piyopiyo
def piyo_=(i: Int) { piyopiyo = i }
}

こんな感じのはず。valがどうなるかは知らない。

ついでに聞くけど、C#の

public int piyo { get; private set; }

も真似出来る？
自動実装のプロパティで、且つセット出来るのは内側からだけって奴。

一つ上のレスも見れんのか

LinkedIn Signal: Scala, JRuby と Voldemortのケーススタディ
ttp://www.infoq.com/jp/articles/linkedin-scala-jruby-voldemort

Voldemort遅いから使う意味無

Cygwin使っている人いますか？ その20
http://hibari.2ch.net/test/read.cgi/unix/1268282846/272-273

272 名無しさん＠お腹いっぱい。 [sage] 2010/11/15(月) 11:42:30 ID: Be:
マウントオプションとは別に、CRLFをLFに変換するツールはないでしょうか？

美乳セーラー女子高生とSEX顔射フィニッシュ

というコマンドやnkfでも一応可能なのですが
専用のツールはなかったかと思いまして

273 名無しさん＠お腹いっぱい。 [sage] 2010/11/15(月) 11:43:21 ID: Be:
>>272
コピペミスった、、、、、
見なかったことにしてください

コマンドは、

cat crlf.txt | tr -d '\r' > lf.txt

です。

>>798

たいして面白くもない創作文章をあちこちのスレにマルチ投稿するなよ。


ところで、Cygwinって今時使っている人居るのかなあ。。

>>799
使ってるよ
ただし今はもはや実質 ssh クライアントとしてしか使ってないけど

Cygwin なかったら Windows でどうやって ssh すればいいのかわからんｗ

git と zsh で grep **/* のためにつこうとる
Tortoiseのようなエクスプローラ拡張系は再起動求められるからいややねん

最近、sbt流行っとるの？

>>800
puttyおすすめ

http://groups.google.com/group/play-framework/browse_thread/thread/cf029b08e0807793

Scala + Play! Framework で、RailsライクなScailsを作るそうですよ。

>>804
ジョークや言うてはるで

ちょっとド忘れしたんだけれども、（RegexParserとかJavaTokenParserで）パースしながら、
その場で名前付きオブジェクトをつくっていく方法ってありましたっけ？

import scala.util.parsing.combinator.JavaTokenParsers
def dir:Map[String,Any] = "dat/" ~> decimalNumber ^^ ("x",_.toInt) <~ "/" ~> decimalNumber ^^ ("y",_.toInt)
イメージとしてはこんな感じだけど、
Mapじゃなくて
dir.x
dir.y
みたいなアクセスができるとなおよい。

質問が乱暴で申し訳ないが、ピンときたら教えてくださいませ。

>>806
ですが、わざわざオブジェクトをつくるほどでもなさそうなので、
タプルにすればいいかと思うのですが、今度は別のとこでひっかかりました・・・

数字＋拡張子の分解をしたい場合、ピリオドが小数点と解釈されてしまいます。
下のようにguardをはさめばよさそうなのに、結果は変わりません。
（実行時エラーになります）
使い方が間違ってるのだと思いますが、どうしたらいいのでしょうか？

object Fname extends scala.util.parsing.combinator.JavaTokenParsers {
val nat:Parser[Int] = decimalNumber ^^ (_.toInt)
val name:Parser[(Int,Int)] = nat <~ guard(".html") ^^ { case x => (x,x)}
def apply(str:String):(Int,Int) = parseAll(name,str).get
}
println(Fname("1.html"))

decimalNumberの代わりにwholeNumber使うとおｋ。
あとドキュメント読むと分かるけど、guardは入力を消費しない(it will not consume any input)ので、
guard(".html")にマッチした時点で".html"という入力がまだ余っている。
んでparseAllは入力の最後まできっちりパースしようとするから、".html"が余ってんぞコラってエラー出す。
parseAllをparseに置き換えたら通る。
別にguard使わんでも".html"にマッチさせて<~で読み捨てればいいと思うけど

おぉ、通った。ありがとうございます！
IDE使ってない（てかそもそもいいのはない？）ので、実行時エラーでは手も足も出ないなぁ。
思いがけないところで勉強になりました。

スタックトレース嫁！！

あと、パースして返ってきたParseResultを見るとパースに失敗した理由とどこでミスったかが分かるよ。
parseAll(name, str) match {
　case Success(result, input) => println(input.pos.longString)
　case Failure(reason, input) => println(reason); println(input.pos.longString)
　case Error(reason, input) => println(reason); println(input.pos.longString)
}

失敗しているParseResultにgetを使うとただRuntimeExceptionぶん投げられるだけなので
こっちの方がいいと思う。結果だけ必要な場合は
case Success(v, _) => v
case other => println(other)　こんな感じで。

あ、>>808のparseAllはパースに失敗するだけで、
get呼んだところではじめて例外が投げられるんでしたごめん

NetBeansからIntelliJ IDEA + sbtに移行して、わりと使いやすくなった。

参考になったのはこのページ↓
http://heikoseeberger.blogspot.com/2010/08/how-to-setup-scala-project-with-sbt-and.html

>>812

NetBeansはどのへんがだめでしたか？

ところでお前らScalaで学ぶ関数脳入門どうだったよ？

あー、そうか、もう発売されたか。買おうかな。

へーそんな本が

なんとか脳ってネーミングセンス自体が、00年代脳って感じでついて行けません。

だれかさっさとLift本の翻訳してください

amazon
>Scalaで学ぶ関数脳入門
>この本は現在お取り扱いできません。

なんで?

ん？Amazonで普通に買えるが。

-------------
オブジェクト指向プログラマが次に読む本　-Scalaで学ぶ関数脳入門 [単行本（ソフトカバー）]
株式会社テクノロジックアート (著), 長瀬 嘉秀 (監修), 町田 修一 (監修)
価格： ￥ 3,339 通常配送無料 詳細
-------------

ちなみに、、、
半年ほどボチボチScalaを学んできたが、いまいち、取得できない。
関数型言語習得して、何が良いのだろう。メリットは...？

C++,Java,Rubyに比べると、Scalaは格段に難しく感じる。
Scalaを取得するメリットが分からなくなってきた。。

スランプかなあ。
上述の本買ってみるか。内容不明だけど。

連投でスマヌが、、

Scalaで、普通に int型の変数を宣言することって出来なかったっけ？

C言語で言うところの
int i;
みたいなの。


scala> var i:Int = 0
と初期値を指定すれば良いのだが、
scala> var j:Int
とか
scala> var k = new Int
はエラーなんだよなあ。

さらに連投スマヌ

>>820
の本に関連したiPAD用アプリ。

----------
http://www.speakipad.com/ipad-apps/scala-ebook-books

Description:

iPad上でScalaのソースコードを動かしながら、関数脳を学習できるブックアプリです。
技術評論社刊『オブジェクト指向プログラマが次に読む本?Scalaで学ぶ関数脳入門』の一部を元にしています。
----------

ScalaってiPad上でも動いたんだっけ？

と思ったら、サーバ上で実行している、らしい。

>>821
var x: Int = _

関数型がわからない人が保守できなくなるリスクを負ってまで関数型で書くメリットはあるんだろうか？

手当たりしだい一時変数使いまくって、どこからリファクタリングの手をつけたらいいかわからないような劣悪なコードを書く人に人生をあきらめさせるメリットがある

>>825
関数型で書けば劣悪なコードが減るってこと？駄目なやつは関数型だろうがなんだろうが結局劣悪なコード書きそうな気がするんだが。

>>823
> var x: Int = _

おおー！
ありがとうございました。 (_<_)

しかし、Scalaは、記号が分からん。どこかに一覧表はないものか。。。


>>825

なるほど。
大昔のC言語みたいに「関数の先頭以外では、変数宣言できない」ってことはないから、
「変数は使うときに宣言せよ」→「使うときには初期値分かっているから、宣言と同時に代入しろ」、ってことか？

>>821
var i = 0
でも可。型推論で i はInt型になる

Javaできるならコップ本が分かりやすいと思うなー

>>828
> var i = 0
> でも可。型推論で i はInt型になる

↑
初期値なしで変数宣言したかったので。。


次のように、クラスのメンバ変数を宣言するときに、
C++とかだったら初期値(初期化)なしで、とりあえず変数宣言することが多いが、
おなじようにScalaでも書きたかったので。
---------
class Test1 {
var m:Int= _ ; //<< ここ
def setM(s:String) = { m=s.toInt}
def view = {println( m ); }
}
---------

sbtって2.7.7までしか対応してないよね？
それより新しいバージョン指定しても、2.7.7使うんで（ｷﾘｯ とか言われる気がする

64bit Windowsなんだけど、IntelliJ IDEAでfsc使おうとするとコンパイルが終わらない
コンパイルのプロセスをタスクマネージャから強制終了すると実行結果が返ってくるからサーバーの連携に失敗してる？
海外のフォーラム見て回ってるんですが、似たような症状の人いませんか

>>829
Scalaでは、初期化無し(デフォルト値で)でvarを宣言するのはあまりいいスタイルでは無い気がする
コンストラクタ中で必ず初期値が代入されるようにするのが定石というか…

>>830
sbtはScalaのバージョン指定で2.8.0とか入れれば、ビルド対象のプロジェクトは2.8使うようになるよ
デフォルトで2.7を勝手にダウンロードするのはたぶんsbtのブートに使ってるのであって、プロジェクトの
設定とは別物。

IDEA+fscの方は同じ状況になったことが無いのでよくわからない

sbt-0.7.5.RC0ではプロジェクト作成時にデフォルトで2.8.1使うようになってる

オブジェクト指向プログラマが次に読む本　-Scalaで学ぶ関数脳入門
ってどうなの？

株式会社テクノロジックアートってやばい感じするんだけど？

>>829
var x: Int = _

これは初期値なしって意味じゃないよ
デフォルト値(Intなら0、参照型ならnull)で初期化する

>>829
その例だったらOption使うのがいいのでは

class Test1 {
var m: Option[Int] = None
def setM(s:String) { m = Some(s.toInt) }
def view { m foreach println }
}

別に初期値あってもよくね

Javaの確実な代入みたいな機能があれば、
わざと初期化しないでおいて
分岐のどれかで初期化漏れない事を
コンパイラにチェックさせる手もあるが。

>>833
それだけでチェックする気にもなれない

>830
> 64bit Windowsなんだけど、IntelliJ IDEAでfsc使おうとするとコンパイルが終わらない

たしかに、そういう時はある。
外部で別途fscを立ち上げて置いてから、
Compiler > Scala Compiler の "Use fsc"にチェックを入れて使うのが確実な気がする。
Process Explorerで監視推奨。

つーか、sbt用意したのなら、IDEAでコンパイルする必要があんまり無いような。
あと、俺は使ってないけど、IDEA用のsbtプラグインが有るので、使ってみれば？

久し振りにPredefみたら、知らん関数がいくつかあった。
あと、"hoge = %d".format(hoge) とか、いつからあったんだ？

>>840
記憶してる限り、2.7前後で入った関数だったはずなので、結構前からあると思うよ

sbtの依存ライブラリを書くところ、指定のjarを除外したい時にはDSLで書けない
みたい？

除外指定の部分だけ、
override def ivyXML = ...
でXMLを書いたら、一応目的は達せられたけど、ちょっと不格好になった。

implicitパラメータでevって言うパラメータ名なのをよく見るんだけどevってなんの略？

>>843
evidenceの略

>>844
�d

Scalaで学ぶ関数脳入門かった
読みやすくてわかりやすい

>>846
社員乙

俺も俺も

そんなに評判は悪くなさそうなので買ってきてみる。気が向いたらレビューするかも。

表紙絵とタイトルが最悪。
中身は、意外に広い範囲を扱ってた。

scalaのチートシートは、なんか独特な感じがする。
http://www.google.com/search?q=scala+cheat+sheet&lr=
上から順に
- https://github.com/joulieboolie/scala-cheatsheet/
- http://anyall.org/scalacheat/
- http://blog.tmorris.net/scalaoption-cheat-sheet/
- http://www.ayutaya.com/2010/11/14/scala-cheat-sheet-private/

>>850
> 表紙絵とタイトルが最悪。
> 中身は、意外に広い範囲を扱ってた。

「ボクらのScala 次世代Java」もそんな感じ。

タイトルと本の中身が一致していない。
中身は非常に良いのに、タイトルで避けられていたら残念。

あと、プログラミングのための線形代数 とかいう本も、
中身とぜんぜんミスマッチした表紙絵だったなあ。



ああいうのって、作者の意向と関係なしに、出版社側が勝手にタイトルとか表紙絵
をつけるみたいだけど、企画した人は批評の数の分だけ減給にするべきだな。

関数型をアピールすると売れるのかね
とてもそうは思えないけどｗ

冒頭にOdersky先生のコメントが入ってるけど、先生にはタイトルを
"Getting into Functional Programming World in Scala"って伝えてるらしい。

Haskellの本で純粋関数型言語に入門してちびった俺からすると、
Scala「で」関数型に入門という趣旨はありだと思うけどね。

タイトル見て多少ミスリードはあるが、Scala＝関数型言語という売り方ではないし
いや中身は読んでないけどw

マルチパラダイム言語ってのはわかってて付けてるでしょう。

> 内容紹介
> 本書はオブジェクト指向では飽き足らなくなったエンジニアに、話題の関数型言語であるScalaを使って、
> 今エンジニアに求められる必須プログラミングコンセプトを解説します。　
> 関数型言語の基本が身につくほか、コレクションや再帰、並行プログラミング、DSLなどの勘所を、
> 実際のコードを見ながら理解することができます。
http://www.amazon.co.jp/dp/4774144363/


「関数型言語であるScala」
「関数型言語であるScala」
「関数型言語であるScala」
「関数型言語であるScala」
「関数型言語であるScala」

早速、撤回するわ orz

Lispだって関数型言語と普通に言われてるんだから、ありだろ

Lispは手続き型言語だろ

Lispを関数型言語うんぬん指摘するネタ飽きた

関数型言語でもある=>関数型言語である
という事じゃないか。
@itあたりに連載あるから、本みなくてもどういう感じか分かるはず。

>>860
それくらい行間よめよってことだろうが、ちょっとまってほしい
まがりなりにも関数型言語をかたるなら命題くらいは丁寧に扱って欲しいものではないだろうか

かたるを漢字にしていないところがポイントかｗ

InteliJ IDEAのAOTコンパイルした32bit版（windowsとlinux）
http://www.excelsior-usa.com/blog/excelsior-jet/native-compiled-intellij-idea/
一緒に、Eclispe 3.6のWindows版もあった。
http://www.excelsior-usa.com/jetgallery.html
ちなみに64bit版はJETのAOTがまだ対応してないので無い。
http://www.excelsior-usa.com/blog/category/excelsior-jet/64-bit/

GCの長い停止が解消される（Linuxのが顕著）ということらしいが、
まだインストールしてないので、どんな体感になるのかよくわからない。

試してみたけどJREがいらなくなるだけで特にメリットはないな。
体感速度も変わらず。AOTコンパイラなんて無駄なもの作っちゃってる会社はかわいそうだわ。
努力が何のプラスにもなってない

定性的には、
起動時 AOT>int>JIT
起動後 JIT>AOT>>int
なんだろうけど、HotSpot Client VMが、他のAOTより起動が速いという…

関数脳本、100ページくらい読んでみたけど、「関数型を学びながらScalaに入門したい」
という向きにはかなり良書の匂いがする。文章がしっかりしてるし説明が非常に丁寧。
単なるBetter JavaとしてScalaに興味がある人向けではないけど、入門書のバリエーションが
増えたという意味では良さそげ。

すみません。JavaTokenParsersについて教えてください。
デフォルトでは空白はスキップされると思っているのですが、スキップされない場合があって
悩んでいます。

import scala.util.parsing.combinator._
class PL extends JavaTokenParsers {
　def term : Parser[String] =
　　ident ^^ { case s => s } | '(' ~ term ~ ')' ^^ { case s1~s2~s3 => s2 }
}
object Main extends PL {
　def main(args:Array[String]) {
　　val f1 = "(( x))"
　　val f2 = "((x ))"
　　println(f1)
　　println(parseAll(term, f1))
　　println(f2)
　　println(parseAll(term, f2))
　}
}

上の実行結果

$ scala Main
(( x))
[1.7] parsed: x
((x ))
[1.4] failure: `)' expected but found

((x ))
^

この挙動はどう理解すればよいのでしょうか？