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

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

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

前スレ
プログラミング言語 Scala
ttp://pc12.2ch.net/test/read.cgi/tech/1205156417/

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

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

乙。
前スレなんで落ちたの？

>3
少数派のScala民は迫害されているのです。

980超えると24時間ぐらいでdat落ちだったかと

実行可能な機械語の列を書く手法が
だんだんと縮約されてきてるな
いい傾向だ

乙。

>>1乙

乙cala

>>1乙

>>1乙

話題無さ過ぎだな、このスレ。

質問でもニュースでも話題振ってくれさえすれば自分は反応するし、ほかにもそういう
住人は結構居るのではないかと。まあ、言うだけだとアレなので話題振ってみるか

Scala 2.8でコレクションライブラリが全面的に書き直されるけど、どう思う？
http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html
再利用性っていう点ではよく考えられてるなーと感心するんだけど、初学者に対する敷居が高くなりそうな気が
してちょっと心配。たとえば、mapメソッドのシグネチャが
def map [B, That](f : (A) => B)(implicit bf : BuilderFactory[B, That, This]) : That
になってるけど、返り値がThatって何だよとか、ぱっと見で何が返ってくるかよくわからんようになってるのが
どうなんだろうと。

>13
お尻に付いてるimplicit ...は読み飛ばす癖がついてるので……。

せっかくだから、今までの奴との使い方の違いを解説してくれ。

>>14
うい。じゃあ、せっかくなので解説してみる。
2.8のコレクションライブラリの面白い点の一つは、高階関数が引数の関数の型＋レシーバの型によって返り値の静的な型が異なる事を
許容している点。これだけだとさっぱりだと思うので例を挙げて説明してみる。まず、Map[String, String]のインスタンスを作る。
scala> val m = Map("x" -> 10, "y" -> 20)
m: scala.collection.immutable.Map[java.lang.String,Int] = Map(x -> 10, y -> 20)
でもって、mapメソッドを使って、Mapの全valueに10足してみる。
scala> m.map{ case (k, v) => (k, v + 10) }
res0: scala.collection.immutable.Map[java.lang.String,Int] = Map(x -> 20, y -> 30)
mapした結果がMapになっている点に注目。次に、mapの中でkeyを捨ててみる。
scala> m.map { case (k, v) => v }
res1: scala.collection.immutable.Iterable[Int] = List(10, 20)
すると、mapした結果の型がIterableに変わる。

文字列を使った例。まず、filterしてみる。
scala> "Hello, World".filter{c => c != 'l'}
res7: scala.runtime.RichString = Heo, Word
結果がRichStringになっている(2.7.XだとSeq[Char]が返ってきた)。文字列にmapしてみても、
scala> "Hello, World".map{c => (c + 1).toChar}
res8: scala.runtime.RichString = Ifmmp-!Xpsme
無名関数の返り値の型がCharならRichStringが返ってくるが、そうでなければ
scala> "Hello, World".map{c => (c + 1)}
res9: scala.collection.immutable.Vector[Int] = Vector(73, 102, 109, 109, 112, 45
, 33, 88, 112, 115, 109, 101)
Vector(2.8で新規導入された型)が返ってくる。こんな感じで、レシーバと引数に応じて適切な型の返り値を返してくれるように
なってるわけだ。まとめると、2.7.Xだと必要以上に一般的な型(SeqとかIterableとか)が返ってきてたケースの多くで、ちゃんと
要求にあった特殊化された型(MapだとかStringだとかSetだとか)が返ってくるようになってる。長文ですまん。

>15
んー、なんか分かったような気もする。

ソース見ると、
def flatMap[B, That](f: A => Traversable[B])(implicit bf: BuilderFactory[B, That, This]): That = {
val b = bf(thisCollection)
for (x <- this) b ++= f(x)
b.result
}
となってるから、BuilderFactory#applyの返値（最初の例だとMapBuilder）に
+=で要素を足していって最後に変換して返してるんだな。

コンソールで試してみるか、ソースを丁寧に追えば一応分からん事もないけど、
APIドキュメント見た時に、返ってくる型が分かりにくすぎないか？　これ。

>>16
＞APIドキュメント見た時に、返ってくる型が分かりにくすぎないか？　これ。
そうそう。まさにそこが懸念。mapだとAPIドキュメント見ただけだと、ThatというGenericな型が返ってくることしかわからん。
implicit parameterの仕様をちゃんと把握してないと返り値の型もわからないというのはどうなんだろうなあ。

つーかこれ、APIドキュメントのどこをどういう順番で見たら、
「ああ、この場合のThatは、Map[String, Int]のことね」と得心出来るわけ？

Prologの99問から翻訳した問題集が上陸しているようです。
ttp://www.google.co.jp/search?hl=ja&q=S-99%3A+Ninety-Nine+Scala+Problems&ie=UTF-8

>>18
implicit parameterに適合するobjectを見つけるために、implicit parameterに関連付けられた(associated)クラスの
companion objectを探索しに行くというルールがある。関連付けられたクラスというのは、詳細はScala言語仕様の
7.2 implicit parametersを参照して欲しいんだけど、たとえば、

implicit bf :BuilderFactory[(String, Int), That, Map](Thatは不明な型)

の場合(これは、(String, Int)を返す無名関数が渡された場合になる)、BuilderFactory、Tuple2、Map、それらのスーパークラス、が関連付けられた
クラスになる。で、Mapのcompanion objectを見てみると、

implicit def builderFactory[A, B] : BuilderFactory[(A, B), Map[A, B], Map]

となっており、A = String, B = Intとすると、bfに適合する型になるため、これが選択される。その結果、
That = Map[A, B] = Map[String, Int]となり、これが返り値の型になる。一方、

implicit bf :BuilderFactory[Int, That, Map](Thatは不明な型)

の場合(Intを返す無名関数の場合)、Mapのcompanion object内のimplicit defにはマッチせず、そのスーパークラスであるIterableの
companion object内のimplicit def

implicit def builderFactory [A] : BuilderFactory[A, Iterable[A], Iterable]

にマッチして(A = Int)、返り値の型That = Iterable[A] = Iterable[Int]になる。まあ、これでわかると思うけど、なかなかにややこしい。
APIドキュメントにThatがどういう風に選ばれるのかちゃんと書かれてないと、APIドキュメントだけから読み解くのは結構きついもの
があると思う。

Scala Reference Manuals [ ttp://www.scala-lang.org/node/198 ] のページに
新機能の提案書兼概要みたいなのが用意されてたー
・ Scala Improvement Documents [ ttp://www.scala-lang.org/sids ]
2.8以降の追加機能みたい。

1. Named and Default Arguments (draft)
2. Scala Compiler Phase and Plug-In Initialization for Scala 2.8 (active)
3. New Collection Classes (draft)
4. Early Member Definitions (draft)
5. Internals of Scala Annotations (draft)

>>15 の m.map{ case (K, v) => (k, v + 10) } って、なんでcaseがついてるんだっけ？

あと、タプルを返す関数を渡すとMapが返ってるけど、
型パラメータを明示すればタプルのIterableを返すようにもできるのかな

>>22
Scalaでは複数引数の関数とタプルを受け取る関数が区別されてて、タプルを受け取る関数をcase使わないで
書くことももちろんできるんだけど、m.map{t => (t._1, t._2 + 10)}みたいになってキモイので、case使って書いている。

>>22
＞型パラメータを明示すればタプルのIterableを返すようにもできるのかな
これはもちろんYES。

scala> m.map[(String, Int),Iterable[(String, Int)]]{case (k, v) => (k, v + 10)}
res0: Iterable[(String, Int)] = Map(x -> 20, y -> 30)

OCamlからScalaってわかりやすい？

2.8で継続入れるってどこかで読んだんだけど

これだった
A Taste of 2.8: Continuations
http://www.scala-lang.org/node/2096

新しいコレクションライブラリも相変わらず、再帰なんて糞食らえってな感じで
ループ使った実装ばかりだな。

>>20
mapメソッドの問題のひとつは、どのようなBuilderFactoryが用意されているかがわからないこと、という理解でいいのかね？

BとThisの組み合わせでBuilderFactoryが決定されるけど、用意されているものを知ってないとどのようなBuilderFactoryが使用されるかがわからず、よってThatがどの型になるかが予測できない。

これって、インターフェースが実装？（どのようなBuildFactoryがあるか）に依存してしまってると言えない？
最悪、Mapなどに用意されているBuildFactoryの種類に追加があると挙動が変わってしまう場合もある、ということになる。

>>28

Scalaさんて、末尾再起最適しなかったっけ？

>>29
＞BとThisの組み合わせでBuilderFactoryが決定されるけど、用意されているものを知ってないとどのようなBuilderFactoryが使用されるかがわからず、
＞よってThatがどの型になるかが予測できない。

ここはその通りだけど、

＞これって、インターフェースが実装？（どのようなBuildFactoryがあるか）に依存してしまってると言えない？

これはちょっと違う。implicit parameterをうまく使うことによって、型パラメータが適切に推論されるので、型パラメータを書くのを
さぼれますよってだけのことで、型という観点からは、単にBuilderFactoryを余分な引数として取る普通のメソッドに過ぎ無い
わけで、別に実装に依存するとかそういう大げさな話ではない。

Groovyの作者(今は関わってないかも)James Strachanがこんな事書いてるね。
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
注目すべきは、
"I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky,
Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."
2003年にProgramming Scala(たぶん、Programmin in Scalaの間違い)を読んでたら、Groovyなんて
作って無かっただろう、って。

個人的にはGroovyとScalaは適用領域がやや違う気がしてたので、Groovy作者からこういう言葉が
出てくるのは結構意外。

>32
それ使ってGroovyスレを荒らして来いって指令ですか？

>>33
別にそーいうつもりは無かった。ただ単にちょっと面白かったのでネタとして投下してみた。

>>32
総まとめ：Javaの将来的な後継者としての Scala
http://www.infoq.com/jp/news/2009/07/scala-replace-java
>Java の創作者である James Gosling 氏や
>JRuby の主要開発者である Charles Nutter氏に続いて，
>Groovy の創作者である James Strachan氏もScalaへの賛意を表明している。

でも流行るとは思えないなあ

Scala - The Next Five Years
ttp://www.scala-lang.org/node/143#talks

Scala Lift Off ('09/06)で、発表したスライドがあるな。

2.8の説明が中心で8割ぐらいあった。

RemoteActorで、1つのActorに複数のActorが高頻度でメッセージを投げると
たまにメッセージロストするんだけど、仕様ですか？

ScalaはJavaとべったりなのが嫌だなー

Javaとべったりになるための諸々を排除した「きれいなScala」を見てみたかった
という気はするけど、そうだったら今程注目を集めてなかっただろうなあと思う。

pizza, funnelがあってscalaらしいので、(JVMで動くけど)そっちがそういうのかな

ttp://www.artima.com/scalazine/articles/origins_of_scala.html
ttp://pizzacompiler.sourceforge.net/
ttp://lamp.epfl.ch/funnel/

ドキュメントざっと読んでみた
pizzaはシンタックスはかなりJavaに近いけど、Generics,ファーストクラス関数,パターンマッチング等、Scalaの原型っぽい感じ
funnelはシンタックスはよりScalaよりな感じ＆並行処理のためのプリミティブが入ってるのが特徴？
どちらにしても、Scalaの原型という感じで「きれいなScala」とはちょっとイメージが違うかなあ。

おすすめの入門コースを教えてくれ。
母語はJavaで、schemeとHaskellは少々分かる程度。
チュートリアルはぱっと見したが、基本的な文法概念がよくわからん。

Tutorialは和訳されてるけど、そっちの方読んだ？英語苦手なら和訳版読んだ方がいいかも

http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaTutorial-ja_JP.pdf

英語だがProgramming in Scala買うのが一番お勧め。英語としては極めて平易
なんで読みやすいし、かなり丁寧に解説してくれてる。あとは、わからんことあったらこのスレで聞けば
誰かwが答えてくれると思う。このスレ、話題に飢えてるから。

>44
JavaとHaskellが分かれば、あとは何とかなると思うけど。
本は、「Beginning Scala」の方がJavaしか知らん初心者が通読する為の本
って感じで、リファレンス本的な感じが無い。

で、俺はLiftを使ってWebアプリを書いてみるのがいいと思う。
Scalaならではっぽい機能をかなり使ってるから、Scalaの学習に向いてる
気がするので。

やっぱ本読まないとだめかｗ
あのチュートリアルは面白そうというモチベーションは上げてくれるが俺の能力ではあれだけではコードは科研しな。
Liftは興味あるよ。つか、やりたい。
とりあえず金ないけどProgramming in Scalaの方をぽちった。パンの耳でもかじりながら読むよ。（要所を最後まで読了したことないんだけど…

つか、構文糖がいろいろあるっぽくて、釈然としないっつーか
なるほどという実感が持てない。だまされ続けてる感というかなんというか。

うーん。それだけだと何が釈然としないのかよくわからんなー。

「何でこれ、型が違うのにコンパイル通るんだよ！　どこかに俺の知らない
オーバーロードがあるのか？」
↓
「よく見たら、implicitな型変換が定義されてました」

ってのはありがちだが。

クラス定義があると？REPLがちゃんと動かない？
シェルでscalacが通るコードが、C-c C-bだとエラー。
Haskellだと無意識にC-c C-rしまくりなんだけど、みんなコーディングはどんな感じにやってるの？

コンパニオンオブジェクトは、REPLで通らないね。
コンパイル単位が別になってるってことみたい。
この場合は、objectで包む事で一時的に回避してる。

なるほど。ライブラリのソース見たところ、
objectひとつで１ファイルにする物みたいね。

しかし、Scala by example よいね。もしかして、本(Programming in Scala)要らなかった？

JavaとScalaの微妙な違い見つけた。

// Java
class A { public int field = 123; }
class B extends A { private int field = 456; }

// Scala
class A() { val field = 123 }
class B() extends A { private val field = 456 }

Java版はコンパイル通るけどScala版は通らない。
公開フィールドもサブタイピングにおける契約の一部とするとScalaが正しい。

>>54
それはちょっと違う。Javaが上記のコードでOKなのは、
サブクラスのフィールド定義がスーパークラスのフィールド定義を隠蔽(≠オーバーライド)しているから。
フィールドは静的な型だけに基づいて決まり、オーバーライドできない。

いっぽう、Scalaの場合、クラス定義におけるvalは一種のgetterのようなもので、オーバーライド
可能になってるので、public -> privateにするのは不可。

「Scalaのアクターのための性能を犠牲にしないで競合安全性を確保する型システム 」
ttp://www.infoq.com/jp/news/2009/07/scala-actors-race-safe-system

難解すぎて、わけわかめ＞＜

>>55 その仕組みはわかってるつもりなんだけどJava版で使う段になってnew A().fieldがOKでnew B().fieldがNGなのは型的に正しいの？
それともA a = new B(); a.fieldでAのインターフェイスでとにかく使えるんだからいいということかな？　まあそんな気もしてきた。

みんな開発環境にはなにを使ってる？Eclipse プラグインのやつ、どうにも不安定＆イマイチで・・・
NetBeans がいいって聞くけど実際のところはどうなんだろ？

>>58
vim使ってるなあ。Odersky御大によれば、IntelliJ IDEAも良いらしい。

自分もvimですね。単にIDE使うほどにこだわりがないだけですけど。
ところでScala本の翻訳出るんだね。
http://www.amazon.co.jp/gp/product/4844327453

メソッドを関数として扱うにはどうすればいいの？
いちいち{(xs, ys) => xs ::: ys}なんて書かずに、
たとえば(:::)に近いすっきりした書き方がしたい

_を使う。たとえば、
xs.::: _
みたいな感じ。ジェネリックなメソッドを関数として扱う場合、
xs.map[Int] _
みたいに明示的に型パラメータを指定してやらなければならないケースもある。

あ、レシーバも含めて関数にしたいのなら、
_ ::: _
とかかな。型推論が効かないケースだと、(_:List[Int]) ::: (_: List[Int])みたいに型注釈が必要な場合も。

Scala＝Javaな人でOK?

100%がそうじゃないけど、Javaから乗り換えっていうケースが多いだろうね。
Javaの資産がそのまま使えるってのが大きなウリだから。ただ、外国で初期から
Scalaやってる人たちはFPのバックグラウンド持ってる人が多い印象(Scalaの開発者もそうだし)

ライブラリと実行環境の揃ってるHaskellとして。

ScalaやるようになったあとでJavaも勉強しだして結構Javaラーになってしまった。

Scalaから始めてよくJavaの煩雑さに耐えられるなあ。
自分はRubyに慣れてしまってるので、Scalaでもまだまだるっこしく
感じることが多々ある。

初期のJavaからやってたら、Javaも随分楽になったなあと思うけどな

まあ糖衣構文は増量されたと思うけどね
さすがにモダンな言語と比べるとコアの構文が弱すぎる
期待の星だったクロージャも……

俺も正直、Javaを馬鹿にしていたが謝りたい
特にconcurrent関連。いやそれのみに対して。

>70
期待の星だったクロージャも……

Clojureのことだとおもた・・

>>60
池袋ジュンクで先行販売していましたよ。

>>70
モダンな言語って？

HaskellとかRubyとか

Haskellはともかく、Rubyはどうだろ
便利に使わせてもらってるが、モダンとは何か違う気がする
クラシックな言語の良さをそのままに、モダンな機能もちょっと取り入れた的な

Rubyでモダンじゃなかったら、それこそScalaくらいしかモダンじゃなくなる
それにHaskellの方がJavaより古い言語だ

年代的な新旧よりも仕様面ではどうなん？
F#とかw

F#ってOCamlと言語的になにか違うのか？

>>73
なぬ！買わねばっ！

>>60
「JavaからRubyへの移行を考えている人も必読」とか紹介してるけど、
Scalaの後でRuby見たら、なにこの手抜き言語？としか思わんだろう

>>79
OCamlのサブセットです

言語仕様の意味で包含関係って、Ocaml⊃F#でしたっけ？

サブセットじゃないだろ。Active PatternとかF#にあって、OCamlに無い機能も
あるし、オブジェクト指向周りの仕様も別物のはず。

「関数型＝モダンかよ！」by Mercury,Oz,Gödel,...

ゲーデルなんて言語があったのか、知らんかった
なんか随分前に開発止まってるみたいだけど

関数型そのものはモダンではないよね
オブジェクト指向言語に関数型の機能を入れるのが最近の流行なだけで

モダンな関数型とかあるんじゃねーの、と適当に言ってみる

モダンでもレトロでも使われなきゃおじゃんだねw
scalaはその点、出だしからいい位置に居るんじゃないかな

関数型は並行プログラミングが流行なのかね
Erlangとか、このScalaとか
個人的に今のところあまり必要としてないんだけど

マルチコア環境が普通になったからね

UGM系の携帯・WebサイトだとそこそこでもC10Kとかプッシュ型非同期処理とか考えないといけないけど
単価をいかに下げるかの世界だから、サーバの台数を減らしたり、楽に効率あげれそうなものに飛びついて
試してる面もある。Web+DBとかの執筆者の影響で始めてみようという人もいるんじゃないかな？
逆にHPCの世界の人は、大規模な問題を相手にしてるから、ベクトルの代わりにいかにGPU,CELLを並列にチューニングして
使うかの方向が多いよね。

Scalaスケーラブルプログラミング［コンセプト＆コーディング］
ttp://www.impressjapan.jp/books/2745
翻訳本の公式ページにエラッタも出てた。
監修者あとがきは気合いはいってるけど、訳はどうかな。

600ページの本を電車内で読むのはつらい。
日本でもKindle売ってくれたらいいのに。

文法上は並行プログラミングになってるけど、実際に必ず並列動作するコードが吐き出されているのだろうか？

>>92
ページ数の割には薄い。薄い紙を使ってるそーで、裏のページが透けて見えたw

破れそうで怖いな

洋書と殆ど値段変わらないじゃないか…

>93
>文法上は並行プログラミングになってるけど、実際に必ず並列動作するコードが吐き出されているのだろうか？

文法上どこが並行かわからんけど、(どこのこと？)

並列動作は明示的にThreadをコントロールするコード書かないとダメ。

Actor使えば必ず並行かと言われるとそうでもない。Actorを１つしかNewしなければ、逐次動作と変わりない。

MailBox（と呼ばれているキュー）に突っ込まれたデータを、プログラムしたとおり、順々に処理するだけだからね。

>Actor使えば必ず並行かと言われるとそうでもない。Actorを１つしかNewしなければ、逐次動作と変わりない

MainスレッドとActorのWorkerThreadが別々に動くから、並行っちゃ並行だったので訂正。

それだけだとなにが嬉しいのかわからないから、素直にErlang囓る事を勧めるよ。

>>96
良いの？嫌なの？

>>98
もうかじったよw

で、スレッドをコントロールするコードを書くと結局どうなるん？
というかOSの仕組みを借りないと並列実行できないの？

もしかしてかなり基本的な疑問か…orz

そんな質問がでるってことは基礎から足りないね
なんか本とか読んでみたの？

本当にペラペラな紙だな
本自体も厚さの割りにふにゃふにゃだった
内容は知らん

さすが>>102さん、知性あふれる書評ですね！クール！
マジすごいよ君の脳は！

>>102
すごく参考になりました。やはり本は内容より紙質ですよね。

俺も今Amazonから届いたよ
確かに薄いな、ジャンプより薄い
装幀も悪くないし、うん、これは良い本だ

買ってみたくなった

紙質にはこだわったと監修者が言ってたからな

内容よりもまず紙質が評価されているだと……？

内容は既に保障済みだからな
今更語ることといえば、紙質ぐらいしかない

紙質がいまいち

この紙って高いの？安いの？

紙が薄いと、ScanSnapで重送してしまう。

薄くても安心

ページが多い日も安心

モダンな言語って、生まれた時期もあるが、注目されてきた時期も関係するんじゃないの
あと、仕様にミスが少ないとか

紙がペラペラで薄かったりとか

上質な薄い紙にしたので、コストが上がったらしい。出来るだけ薄くしたかったので譲れなかったと。

紙に拘るより、PDFで売ってくれた方が嬉しいけどな。

PDF(笑)

Javaスクール卒業生向けの関数型言語ですね。わかります。

だんこがいが褒めてるのを見て実は駄目な言語じゃないかと思いはじめた

そこはせめて自分の感覚とも相談しろよ・・・・・

Scalaスケーラブルプログラミング
これ詠む価値ないです
原著を読んでください

訳が悪いとか？

紙が撓んで読む気がなくなります。

やはり紙か

今回の翻訳本の語彙は、別の人に少しはチェックしてもらったらしいが、
金取ってるなりに、情報系の対訳集ぐらい出版社なり業界なりでメンテナンスしてほしいな。


あと、clojureの話ってどこでやってるんだ。どうしようもない質問があるんだが・・・

公式のjarだけだと *compile-path* 規定のclassesフォルダ作っても:gen-classのcompileが通らないが、どうすればいいんだ。
ちなみに、「Programming Clojure」で配布しているプログラミング環境のセットだと通る。
ttp://www.pragprog.com/titles/shcloj/source_code

そもそもJVMで動くっていうのがきもい
JVMがないと何にもできない糞言語ってことだろ？

>>128
.NET版なかったっけ

>>128
そんなの言い出したら、処理系がVMで実装されてる言語がほとんど当てはまるがな。
○○はVMがないと何もできない糞言語、ってね。

Javaはいかんだろ

JVMがないと何も出来ない⇒糞言語

て理論がまず分からんわ
なので、今のところ>>128が糞。これなら分かるw

俺もJVMとXMLリテラルは言語の普及には貢献するだろうが、寿命は縮めると思うね

どうせドカタ言語になるだろｗ

>>133
時期が近いGroovyも埋め込みマークアップをサポートしてるのを見ると
流行りなんじゃないのかなあ
個人的には、XMLリテラルは好きでない
言語が依存するほどXMLが絶対的だとは思えないので

JVMはまあ、設計上の選択ということで何も言わないことにする
膨大な資産が投下されてるものを利用したくなるのは分かる

>>128
言語と処理系を切り離して考える程度の知恵もないのか？

for( hoge -> list )
の->はなんなのでしょうか？

>>137
矢印逆じゃね？

∈

矢印逆だった

JVM使うのは基本的に正解だろ。
銀行などシビアなユーザーを含む膨大なユーザベースに叩かれていて、
長年の投資が蓄積されていて、今後も当面投資される見込みの物があるのに、
いまさら車輪の再発明を推すのはアホだろ。選択と集中。
ほかのソフトに依存するのが駄目って奴は、OSのない時代に帰ったら？

誰か答えてあげて
http://pc12.2ch.net/test/read.cgi/tech/1247926906/l50

>>141
途中までまともなこと言ってるんだから、
最後の一行でただの極論馬鹿に落ちぶれなくてもいいのに。

JVM上での言語実装が流行っているのって、
枯らすのに手間暇かかるインターフェース周りの
ライブラリをいちいち作りたくないから。
JVM上に実装するにしろ、.netにするにしろ
そのような面倒などころは先行している実用言語にお任せ。
そうでもしないと、なかなか実用レベルに到達しないだろ。

>>141
デブ元理事？

>>141
うざい

馬鹿丸出しの>>141を論うスレになりました。
Windowsネイティブexeにならない言語なんて意味ねぇんだよ、バーカｗ

ここにもネイティブ厨が

>>141
賛同します。

そんなシビアな環境なのに
今仕事がまったく無いJVMなのでした

チャンチャン

嘘ついてチャンチャンとか締めてもなぁ。

そいやFlightCasterというサービスがClojure使ってるらしいが
LispやSchemeでないのはやっぱJavaの資産の利用が重要だからなのかな。

JVM上の言語はイレージャなどJVMに縛られる部分がどうしてもでてくるからなぁ。

JVM上のlispは、どれぐらいの速度が出るのか調べようとおもったけど、上手くいかなかった。

どのバージョンか見てないけど、ネイティブのsbcl/scalaで、これぐらい
ttp://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=sbcl&lang2=scala&box=1
ttp://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=sbcl&lang2=scala&box=1

ｌisp-2からlisp-1に変換する知識無いので、clojureとkawa(scheme)の計測はできてないし、
そのまま動くはずのabcl(cl)とかもwin環境でいまいち上手く設定できずに出来なかった。orz

全然関係ないけど、on lispとPractical common lispのサンプルをclojure用に一部変換したやつがあった。
ttp://github.com/stuarthalloway/onlisp-clojure/tree/master
ttp://github.com/stuarthalloway/practical-cl-clojure/tree/master

ttp://codemonkeyism.com/clojure-scala-part-2/
Clojure Scalaでググるとこれが一番上にきてた。バランス取りすぎと思える内容だ

スケーラブルプログラミングより
言語仕様詳細に説明してある資料ってどれですか？

公式落ちてる？それともDNS関係？

>>155
Documentation　> Manuals
http://www.scala-lang.org/node/198
# Scala Language Specification
# The SID Library

Language Research
http://www.scala-lang.org/node/143
* Papers

のあたり

関数リテラルがよくわからない
困った

>>158
それは別にScala特有の話じゃないでしょ
Rubyのブロックも同じようなもんだし
無名関数とも呼ばれるから調べるならその辺も

内部状態を保存するから、一時変数を外に持たなくていいとか（レキシカルスコープ?局所変数?）
適用した時点で評価されるとか（遅延束縛）
とかになるとかのところかな？

Y(X(x)) |x=2　= Y * X(x) |x=2とか
実行中に、結果だけじゃなくて、構造を残してるからみたいなことだよね。

参考資料は、
多忙な Java 開発者のための Scala ガイド: オブジェクト指向のための関数型プログラミング
http://www.ibm.com/developerworks/jp/java/library/j-scala01228.html
ほかの言語だとこんな説明があるけどどうだろう。
JavaScriptにおける高階プログラミング
ttp://d.hatena.ne.jp/brazil/20051004/1128435079
on lisp 2. 関数
ttp://www.komaba.utmc.or.jp/~flatline/onlispjhtml/functions.html


・・・実は全然分からんので、とりあえず知ったかしてみた。

Scalaの関数リテラルはscala.FunctionXXを実装している。
関数の呼び出しは、Function#applyの呼び出しに変換される。

finalじゃないローカルスコープ変数を触れることを除けば、
Javaの匿名クラスと変わらないよ。

じゃあhaskellの
無名関数より機能劣るんだな

>>162
何故そうなる。Haskellの無名関数とほぼ同じ程度の機能はあると思うが
具体的に劣ってる部分挙げてみてよ

>>161
＞finalじゃないローカルスコープ変数を触れることを除けば、
＞Javaの匿名クラスと変わらないよ。
これは話が逆で、Javaの匿名クラスは
・記述が冗長である
・外側のスコープのローカル変数についてはfinalなものしか触れない
という点を除けば無名関数と同じようなものだ、という方が適切だと思う。歴史的には
無名関数の方が古い機能だし

Scalaを弄り始めて関数リテラルが良くわからないってことは、
Java経験者である確率が高い。

だから、Javaならこうなるという説明をしたんだよ。

それが余計意味を解らなくするからやめて欲しい
javascriptで比較するのならまだ許されるけど

def w(file File, op: PrintWriter => Unit ) {
val sriter = new PrintWriter(file)
try{
op(writer)
} finally {
writer.close()
}
}

op(writer)を実行するとPrintWriter => Unitはどう利用されるの？

つーか、まず動く例にしろよ
変数の綴りとか間違ってるぞ

import java.io.File
import java.io.PrintWriter

def w(file: File, op: PrintWriter => Unit ) {
val writer = new PrintWriter(file)
try{
op(writer)
} finally {
writer.close()
}
}

w(new File("hello.txt"), _.println("hello"))

こんなんか？
で、質問の意味がわからん
「PrintWriter => Unit」って型だぞ
opという変数に関数オブジェクトが代入されて実行されるだけだ

PrintWriter => Unitってどんな型なのかよくわらかん
引数も取らん関数がなぜUnitを返せるんだ？

>>169
Scalaには引数を取らない関数なんてないぞ
PrintWriter => Unitって言うのは、「PrintWriterオブジェクトを引数にとって、Unitを返す関数」の型だ

>>170
えーとそうすると
op(writer)ってところは何が実行されるの？

>>171
opに代入された関数オブジェクトが、writeを引数にとって関数として実行される
上の例で言えばwの呼び出し引数の「_.println("hello")」という関数リテラルが実行される

>>172
無名関数 != 関数リテラル

なんですよね？この関数リテラルってなんなんですかね？

関数リテラルはカリー化ができない。

無名関数、関数リテラル、匿名関数、みんな同じものだよ
一般的に○○リテラルというのは、オブジェクトを直接生成する表現のこと

例えば、プログラム中の「1」はIntリテラルで、
val a = 1
と書けば、1の値のIntオブジェクトが生成されて変数aに代入される
同じように関数リテラルの場合は、
val f = (a: Int) => println(a)
と書けば、Int型の引数aを取ってプリントする関数が生成されて変数fに代入される
その後でf(1)と関数を呼び出せば、1がプリントされる

つーか、そもそもオブジェクトを生成っておかしくないか。
最初から全部オブジェクトな言語はどうなるんだと。

>>176
最初から全部オブジェクトな言語って具体的に何のことだ？

>>176
横からだが、もう少し詳しく書いてくれんか

まあ、リテラルは定数だから必ずしもオブジェクトを生成するわけではないか

なんつーか、Java関係の業界って難しそうな用語勝手に作ってるけど、
他の用語よりも内容はショボいってこと多くない？

>>179
Scala言語的には一貫して生成と解釈したほうがスムーズでない？
実装上、そうならない可能性もあるにせよ
（そもそも定数畳み込みとかで消えるかも分からん）

>>180
具体的になんのことだ
関数型のリファレンシャル・トランスペアレンシーとか
ポリモーフィック・タイプ・インファレンスの方が難しそうだろ？
このスレでも躓いてるやつは関数型系の用語の方だと思うが

>>179
リテラルが定数って理解も間違ってるでしょ
C/C++のconstで定義した定数はリテラルではない
リテラルは「文字通りの」って意味で字面がそのままオブジェクト／値として解釈される
文字列リテラルとかMapリテラルとか正規表現リテラルとかXMLリテラルとか
解釈された結果のオブジェクト／値が必ずしも定数である必要はない

でも定数じゃないリテラルってあるのか？
昔のCは定数の文字列を書き換えられたと聞いたことはあるけど

>>184
リテラルそのものとそれが解釈された結果の値やオブジェクトを区別してる？

うーむ後もう１つ解らないのですが

def f (x: Int) (y: Int) = x - y

これって引数は2個あるのですか？この意味がよくわかりません

>>185
細かく言えば、リテラルというのはプログラム上の表現であって実態は持たないのだが、
そういう話をしたいのではなくて、生成された（あえてそう言うけど）オブジェクトが
定数じゃないことってあるのか？という意味

>>186
これはカリー化された関数だね
存在意義をこの短いレスで説明するのはちょっと難しい
とりあえず
def f (x: Int) (y: Int) = x - y
は、f(1)(2)みたいに呼び出して、
def f (x: Int, y: Int) = x - y
は、f(1,2)みたいに呼び出すと覚えて、詳しくはいずれ学ぶといいよ
この二つの関数の動作自体は同じ、呼び出し方が違うだけ

>>188
カリー化の書き方なのですか。難しい書き方ですねぇ

カリー化って多変数関数
f(x,y,z)を
(λx.(λy.(λz.M)))
と表現できるってやつであってますか？

あとScalaでは、不動点演算子ってどれなのでしょうか？

>>187
ある。Rubyの文字列リテラルによって生成されたオブジェクトは定数じゃないし、
配列リテラルやMapリテラルによって生成されたオブジェクトが定数の言語って知らないし

うわ、ほんとだ、Rubyで
"abc".sub!("a", "1")
と書いたら動くわ、気持ち悪っ
というわけで、一般的にリテラルが定数というのは訂正させていただきます

>>189
いや、まあ、それであってると言えばあってるけど、
理解するには関数型言語のどれかをちょっと触ってみた方がいいと思う

不動点演算子ってYコンビネータとかのこと？
それってあるものじゃないでしょ
作ろうと思えば作れるけど
どこで調べてきたんだ

>>190
ScalaのMapリテラルはimmutableだよ。何もしなければ。

関数型言語の中でscalaに一番似てそうなのってなにかな
OCaml？
オブジェクト指向と関数指向をどこでどう使えばいいか
参考にできそうかしらん？

HaskellよりはOCamlの方が似てるかな
オブジェクト指向と関数型の融合という点では参考にならんと思うけど

盛り上がってるな。やっぱ本の影響か？

>>194
＞オブジェクト指向と関数指向をどこでどう使えばいいか
これ、参考例がほしいなあ

最近CTMCPを読んでるが、方法論の選択は「問題に合うものを使え」とのこと
例えば、宣言的モデルで解こうとすると、表現力が足りなかったり逆に複雑になるような問題には
明示的な状態操作で対応しろと

理屈は分かる気がするが……どうすりゃいいのよｗ
結局は経験則しかないのかね

Common-LispのletってどうやってScalaで書けばいいのですか？

>>197
設計はオブジェクト指向でやって、あとはなるべく参照透明性があるように書けばいいんじゃないの

>>198
letってローカルスコープ決めるだけじゃないの？
なにがしたいの？

>>199 まあImmutableパターンをつかったJavaみたいな感じだよね。
>>198 >>200 あえてCommon Lispのっていうところをみると動的スコープのletかなあ。だったらDynamicVariableを使うんだけど。

Scalaの入門ドキュメントや本を見るとvalとimmutableﾏﾝｾｰ状態なのに、
クラスライブラリのソース見るとvarとmutableだらけな件は、
どう解釈したらいいの？

速度が問題にならないところだけimmutableにしろと？

基本ライブラリは効率優先に実装せざるをえないからなあ

>>202
コレクションライブラリは一番基盤になる部分で、実行効率最優先だからvar使いまくり
なのは仕方無い。ユーザが自分で作るプログラムの部分でvar使うかどうかは、目的によるけど
普通のアプリケーションならほとんどはimmutableで大丈夫じゃないかなあ。ベンチマーク取ってみれば
わかるけど、immutableしたからといってそれほど劇的に遅くなるわけじゃないし。

あと、内部がvar使いまくりであっても、ユーザからはちゃんとimmutableに見える使い方(scalaListとか)
なら問題が少ないってのもあるな。つまり、副作用がローカルに閉じてれば問題ないってこと。

その辺は、 private[パッケージ名] var のアクセス制限が
うまく作用してる点ではある。

引数に

Int => Int
(Int => Int, Int) => Int

の2つの関数を取りIntを返すって式はどうやって書けばいいの？

def f((Int => Int, (Int => Int, Int) => Int) => Int

じゃないような気がするけど、うーん

>>207
関数を定義するだけなら、例えばこうだけど
def f(f1: Int => Int, f2: (Int => Int, Int) => Int): Int = 1

君は根本的にプログラミングを理解できてないと思うね
まずJavaあたりをしっかり勉強した方がいい

まずJavaあたりをしっかり勉強した方がいい（ｷﾘｯ

>>208
そうなんですかぁ

うっせーぞボケ
リアルでやるぞコラ

例えば、
def f((Int => Int, (Int => Int, Int) => Int) => Int
と書いたときに仮引数の名前がないじゃない
タイプ・シグネチャと混同したのかもしれないと思ったけど、
ScalaもJavaもタイプ・シグネチャは定義できないと

つまり、Javaレベルの知識もないまま、
Scalaを勉強しようとしてるみたいだから、
Javaから勉強しないと意味がないよと

>>210
「君は根本的にプログラミングを理解できてないと思うね
まずJavaあたりをしっかり勉強した方がいい」

この部分は要らないゴミコメントだから気にするなw

最近ずれた質問してる人は全部この人でしょ？
だからそろそろはっきり言ってあげた方がいいと思ったんだよ

プログラミング初心者が学ぶには不適当な言語だよ、Scalaは
とりあえずJavaをちゃんと覚えてからでいいじゃない
どうせライブラリで使わざるをえないんだから

バカでもScalaに触る時代がきたんだなぁ

>>214
Scala本の影響が大きいんだろうね
基本的にはいいことなんだけど

まぁなんでもいいや
解らんことここで聞けるし

>>214
どうして、こういう人を見下す言動が耐えないんだろうね。屑人間が増えたのかね

屋根上屋根ではあるんで、
プログラミング自体はRubyやPythonで、静的型付けはJavaがいいかもな。

計算可能性とラムダ計算とSICP見ながら、こんなの作ったんだけどあってるかな？
もっと正しい方法あったら教えてください

object ＴｅｓｔScala {
def main(args: Array[String]) {
println("TEST1")
println(zero(_ + 1, 0))
println(one(_ + 1, 0))
println(two(_ + 1, 0))
println(three(_ + 1, 0))
println(four(_ + 1, 0))
println(five(_ + 1, 0))
println(plus(two, five, _ + 1, 0))
println(multi(five, five, _ + 1, 0))
}

def zero (op: Int => Int, x: Int) = x
def one (op: Int => Int, x: Int) = op(x)
def two (op: Int => Int, x: Int) = op(op(x))
def three (op: Int => Int, x: Int) = op(op(op(x)))
def four (op: Int => Int, x: Int) = op(op(op(op(x))))
def five (op: Int => Int, x: Int) = op(op(op(op(op(x)))))
def plus (m: (Int => Int, Int) => Int,
n: (Int => Int, Int) => Int,
s: Int => Int,
x: Int) = { m(s, n(s, x))}
def multi (m: (Int => Int, Int) => Int, n: (Int => Int, Int) => Int, s: Int => Int,x: Int) = {
def N1(n0: (Int => Int, Int) => Int, s0: Int => Int) ={ (x: Int) => n(s, x) }
m(N1(n, s), x)
}
}

チャーチ数の実装か、かけ算のところって、

def multi(m: (Int => Int, Int) => Int, n: (Int => Int, Int) => Int, s: Int => Int, x: Int) = m(n(s, _:Int), x)

でいいんじゃないの？つーか、N1って何をやってるんだ？

>>217
一足早く先進的（笑）な言語を触ったことだけが自慢の、
ろくなもん作れてない低脳だから。
最初にScalaを触った年月日の古さを呟くだけで射精できるらしいよ。

バカと言われただけでそんなに煽られてると感じるなら
その先進的（笑）な機能の話をすればいいじゃない
それ以前の話ばっかじゃないか

Scalaの大部分の機能は他の言語の素養があればすぐ使えるようになるよ
それもないのにいきなりScalaを触ろうとして躓くのが問題
もっと解説が多くて基本的な言語はいっぱいある

いいぞいいぞ！
もっと言いあえ！

低能相手に慣れ合いするのが楽しいの
低能に付き合ってあげているやさしい自分が自慢なの

>>220
なるほど、なるほど

m(n(s, _:Int), x)とかけばいいのですか
ところまたまた質問しますが

n(s, _:Int)と記述したときの、_:Intは関数を渡したことなるのですか？

いや、関数の部分適用だよ
Scalaの関数はカリー化されてなくても部分適用ができる
n(s, _:Int) は (x: Int) => n(s, x) と書くのと同じ

>>225
えーとN1は>>226殿によると
部分適用するのと等価な書き方のようです。

>>226
なるほど、書き方が冗長なのが解りました。

>226
そんな書き方有ったのか。
Scalaは部分適用が不得意なイメージが有ったが、そうでもないんだな。

本がでてたのみつけて少しずつ読み始めたけどなんか書き方が気持ち悪く感じる
部分適用とかも val f = sum _ みたいな _ つけるのとか
理由はちゃんと書いてあるけどそれってJavaの仕様から言語仕様を決めてる?
g(args : String*) を Array に適用するにも g(arr: _*) みたいなのとか

カリー化は別にあるけど、そういうことじゃなくて？

過疎が酷いな
消えるの早すぎｗ

まだ9章途中だからやっとカリー化
カリー化可能関数とふつうの関数の書き方が違うのか
でもやっぱり val onePls = curriedSum(1)_ とか最後の _ がかっこわるい
println(hoge) を println { hoge } でもいいとかううーん

>>232
関数オブジェクトを作るために_を付けるという構文は、
Scalaがフィールドとメソッドの名前空間を区別してないからってのもあるだろうな
間違ってメソッドをフィールドみたいに使っちゃって関数渡しになっちゃうのを防ぐみたいな
そういうのはほとんど型チェックで引っ掛かりそうな気もするけど

{}が使えるのはDSLのためでしょ

あと、微妙に「カリー化」という言葉の使い方が間違っているような

ちがってた
f()() とか定義した時点でカリー化関数っていうんだ
もとの関数を引数を別々に固定できるように変換するのをカリー化というと思ったので誤解
() とか {} はオペレータとして定義できればいいのじゃんと思ったけどそうでないよね

>>232
> println(hoge) を println { hoge } でもいい
これって中括弧でもよい、という話だったのか・・・
右側のはてっきり小括弧が省略されているのだと勘違いしてた。
println( {hoge} )

やっぱ本読むかなんかしないと、間違ってる知識がいろいろありそうな

Scalaで括弧が省略できるのはレシーバを書いたときだけだからね
Console println "abc"
みたいに

def f : hoge =

のhogeって引数になるのですかね？

引数？それだと、hogeは戻り値の型だよ。

NetBeansのプラグインを使った環境でプロジェクトに外部のjarを参照させ、
importすると、認識されず型に関する表示が全部errorになってしまうのですが、
なにか使い方が間違ってるんでしょうか？
ｊｄｋのsrc.zipに入っているjarのみ認識しているようですが、
import文を書いた瞬間errorになります。

>239
IntelliJってのを買うといいらしいよ。

ちゃんと動いている人は普通にプロジェクトの設定画面でjarを
指定しているだけなんでしょうか？
だとしたらこちらの環境か設定の問題と切り分けられるんですが・・・。
scalaは外部にあるものを使っていて、SCALA_HOMEとPATHは設定済みです。

>241
夕食に納豆食べれば解決策がひらめくらしいよ。

なんか書けよ

NetBeansのプラグインを使った環境で・・・
ちゃんと動いている人は普通に・・・

うーむ動かすことができるのか・・・。
うらやましい。NetBeansもScalaもクリーンインストールだし、
もはやなんの対策も思いつかない。

プラグインをインストールできないといいたいのか、
自作JARを外部参照するプログラムをコンパイルできないといいたいのか、
よく分からない質問だ

JARを外部参照するプログラムを、
コンパイルはできるけども、なぜか型の情報が出てこない。
全ての型情報が<error>になる。コード補完もめちゃくちゃ。
import文を消すと復元する。
プラグインは入る。jarは外からとってきた奴だけど、
javaプロジェクトでは普通に参照できるし、いろんなファイルで試しても同じ。
そんな感じです。

候補が表示されたりされなかったりするからバグッてると思う

ttp://wiki.netbeans.org/ScalaIssues

Scala 2.7.6 final | The Scala Programming Language
ttp://www.scala-lang.org/node/3250

>>250
つ最終更新日時

つか、NetBeans 6.7.1のを使っているとかいう落ちでは？

>>252
当たりでした。6.7.1に、プラグイン6.7v1を入れ直したら、動きました。
お騒がせしました。

読みが当たったか

エスパーいくない

ひょっとして3項演算子ってない？

いらんと思うけど
val a = if (true) 1 else 2
こんなんでいいんでしょ？

ifが代わりになるから、要らないって言えば要らないけど
ちょっとだけ面倒と思ってしまっただけです
ifは1行でも中括弧付ける癖があるし

パーサーコンビネーター使ってるとき

def xxx:Parser[]って記述と
case classって記述はどうやって

使い分ければいいの？

使い分けはできない

>>260
じゃあ何のために2つ使うの？

>>261
じゃあ何のために使い分けたいの？

ScalaによるWebアプリケーションフレームワーク「Lift」とは
Scala＋Liftによる実践Webアプリケーション開発（1）
http://codezine.jp/article/detail/4310

>>259
基本的には>>260で終了だが、
不毛なやり取りが続いてるみたいだから、一応もうちょい説明すると
def xxx: Parser[T] ...
はParser[T]型を返すメソッドの宣言
case classはパターンマッチに使える新しい型の宣言
そもそも全く意味が違うので、使い分けるとか意味がわからんです。
つか、この二つの区別がつかないってパーザコンビネータ使うとか以前の
レベルで、クラスとかメソッドとは何？ってところから勉強し直した方がいい。

scala本、解説は丁寧でわかりやすいけど、演習問題が少なすぎる希ガス
理解はしても身についてる感が全くない

演習問題なんていちいちやったことないわw

ある程度身についたら、いきなりLiftとか使っちゃっていいんじゃないの

勉強では手を動かさず、いきなり実践訓練か。みんなすげぇなぁ。
俺もトライしてみるか。

使わないコードは極力書きたくないから演習問題なんてしない・・・

もっとパラダイムが面白い言語だったら演習もいいけどね、HaskellとかPrologとか
Scalaは実践向きでしょ

俺はScalaでproject-eulerやってる。
問題の性質上、関数型っぽい書き方になる。
あまり実用的じゃないけどね。

なんか実用的なScalaプログラミング教えてよ

お前ら頭いいしなんでも知ってるだろ？

普通にjavaみたいなコードを書けばいいだけなんじゃ。。

>>270
パラダイムだったらOCamlあたりに引けをとらない面白さだけどな
Haskellより進んだ機能も多いし
確かにPrologのような斬新さはないが

Programming in scalaは
project-eulerで練習するような変態向けじゃなくて一般向け書籍だろ。
なら、特徴的な言語機能毎に練習問題があった方が本の目的には合ってると思うがな。

liftのgetting startedっていまいちだよね

>>274
OOとの融合や暗黙型変換を除いてどのあたり？

XML埋め込めるってのはあるな

JavaScriptのE4Xより先？

少なくともHaskellよりは先

Scalaは実用言語なんだから、オンリーワンな新機能より、
メジャー言語では取り入れられてない程度の物を
うまく使いやすくまとめ上げるところに意味があるんじゃないか

普通に暗黙の型変換とかオンリーワンな新機能じゃね？

暗黙型変換は、うまくまとめ上げるために無理矢理突っ込んだ感があるなぁ。
アドホックでプリプロセッサ的な強引さが、あまり美しいとは思えない。
キャストのオーバーロードは元からあるし、そこまでなら素直だと思うんだけど。

暗黙型変換なんて厨仕様もいいとこだろｗ

暗黙の型変換がどうプリブロセッサ的なのかさっぱりわからん

アドホックじゃないでしょ？Javaでアドホック仕様だった部分を一般化したらついでに強力な何かがついてきただけじゃん？

アドホックじゃないでしょ？Javaでアドホック仕様だった部分を一般化したらついでに強力な何かがついてきただけじゃん？

アドホックじゃないでしょ？Javaでアドホック仕様だった部分を一般化したらついでに強力な何かがついてきただけじゃん？

>>265
そもそも演習問題なんかあった？

0個あったんじゃね？
演習問題の個数は負値をとれないから、
0個を少ないと言わなければ、少ない物はなくなる

いずれ、
「暗黙の型変換もない言語ってダサいよなw」
みたいに言われる日が来るだろうな
Haskellが他の言語に対して
「型推論もない言語ってダサいよなw」
みたいに言ってたように

型変換についてよりリッチな方法は出てくるかもしれないけど、それは
もう少しパワーを落として安全かつ洗練された物になるんじゃ無かろうか。

暗黙の型変換？
ああ、Lispのマクロより非力な劣化版のことね

つか、暗黙の型変換って昔からなかった？

Scalaの場合は自分が作った新しい型へ、既存の型を変換するっていう仕組み
これは今までなかった
Lispのマクロとか、別の機能で同等の機能を実現できるというものを除けばね

Scalaの型推論って、何か弱くね？

Lispよく知らないんだけど、マクロでどうやるの？
関数じゃなくて、値側もしくは関数適用全般を乗っ取る必要があると思うんだが。
マクロにニセ関数的な形をイメージしてるのが間違い？関数適用全般自体を置き換えちゃうの？

あと、新しいのは暗黙ってとこだろ。型変換自体は単なる関数な訳で。
で、自明な場合以外に暗黙にやるのは怖いってのが一般常識だったんではないか？

Lispは関数が値として扱えるので、簡単に乗っ取ることができるよ
値を変えたり、対比したりする感覚で簡単にね
暗黙の型変換のようなことをやるには、引数を判別するだけ

いや、特定の関数にトラップを掛けるのは想像がつくけど、
暗黙型変換自体はすべての関数の適用に有効だろ？
そう言うのをどうするのかなと。

全ての関数適用に有効なわけないだろ
Scalaは変換先の型を引数にとる演算子とか、そこに属するメソッドに
対してのみ変換を行えるわけだから
その分にだけトラップをかければいいことになる

>>299
好きなものを選びな。
・関数定義を乗っ取る。
・構文解析を乗っ取る。
・評価器を乗っ取る。

>>300
＞その分にだけトラップをかければいい
その通りだけど、「その分」ってのは静的に決まらないだろ。

>>301
それもマクロっていうの？

暗黙の型変換ってそれが有効な範囲をスコープで制御出来る所がイイね このアイディアはscalaオリジナル？

>>302
マクロだけどなんで？

>>302
いや、静的に決まるけど？

まあ実例を出したほうが説得力があるだろうね。

>>300 >>301
実例をどうぞ

暗黙の型変換のせいで、クラスのドキュメントが超見づらい。

暗黙の型変換は悪魔だな
なんでこんな仕様入れてるんだろ

開発者はアホだよな

Scalaの標準ライブラリってそんなに暗黙の型変換使ってたっけ？

暗黙の型変換を受け入れるscala信者もアホだよな

プリプロセッサとかLispのマクロとかなんでそういう的外れなたとえが多いのだろうか
新技術を無闇に恐れているというのは伝わってくるが

暗黙の型変換は危険だろ
言語関係の学会でも笑い話にしかならいのに

>>313
学会ってひどい煽りだな
なんでそこまでScalaに粘着してるの？

そもそもこれ実践で使ってる奴いんの？

何をそんなにがんばってるのー。

>>307
すまない、「その分」の実例は用意出来ない

Scalaの作者ってプログラミング言語の研究者だなw

>310
Liftで結構使ってる。

>>315
Liftのソースでimplicitをgrepしたら184個ひっかかった

分母を何にするか決まらないと何の比較にもならんよ。

それはそうと暗黙の型変換をマクロでやるのってイメージわかないので説明してほしいんだけど、
素人考えで思うのはマクロってシンタクスレベルの情報を使ってやるものだから
まだコンパイラが認識するようなレベルでの型の情報は取りだせないよね？
Lispのマクロだと（例えばCamlp4とかとは）その辺違うの？

Lispに静的型なんてあったっけ？

scala最悪だな

暗黙型変換があるから、
a.multiply(b).add(c)とかかかずに、a * b + cとわかりやすくかけるんだろ

>>325
言ってることがよくわかんない

>>326
これがわからなければ暗黙の型変換について何も
わかってないことになる
Scalaの本の最初のほうに書いてあるよ

それって演算子のオーバーロードの話では。。

この例だけ見ればそれと同じ働きをするというだけのこと

>>327
Scala本は手元にあるけど何を言ってるのかわからない
どの辺が暗黙の型変換関係あるわけ？
その式じゃ型が書いてないからわからん

>>328-330
済まない。出直して来る。

27ページと28ページ、それから398ページを呼んでもわからなければ死んでください

>>332
読んでもわかんないんだけど、
multiply と書こうが * と書こうが同じことでしょ？
そこに型変換関係あるの？

┐(´д｀)┌ﾔﾚﾔﾚ

なんか急に頭の悪いレスが増えたな
学会がどうとか死んでくださいとか
大して難解な言語じゃないのに知ったかする奴も多くなったし
まあそれだけメジャーになったということかね

でも、最新（っぽい）技術で俺ＳＵＧＥＥしてる奴は三流だよｗ
C++とかの時代にいっぱいいたｗ　一言で言うと中二病。

>>304
では、Unkoburiburi型から、Int型への暗黙の型変換に相当する事を、
お前の言うlispのマクロで関数側にトラップを掛ける方法で実現したい場合、
トラップを掛ける必要がある関数の範囲は？

引数にIntをとる関数すべてにトラップが必要じゃないの？
そんなの毎秒毎秒新しく生まれてるでしょ？
コンパイル時点でトラップが必要な範囲の関数すべてをカバーするのは原理的に無理。

闇雲にLispスゲーって言っとけばいいってもんじゃないんだよ。

http://blog.objectmentor.com/articles/2009/09/21/programming-scala-is-now-available
これってアリクイ？

>>323
Commonだと宣言型で (declare (fixnum x)) とか効率化やエラーチェックのために宣言する事はできる。
>>322
304じゃないけど、推察のとおりマクロ展開時には型情報とかは利用できないのが普通。
元Lisp使いの俺が想像すると↓みたいになるんじゃないかな。
1.Unkoburiburi型からInt型への変換を定義しておく
=> Unkoburiburi型からintへの変換はunkoburiburi-to-intとか
2.関数と引数の型もマクロ展開時に利用できるように用意しておく
=> (succ ([Int型 引数x]) ... ) とか
3.マクロ展開時に使えるように変数unkoの型を宣言する構文をつくる
=> (define test ([Unkoburiburi型 引数x]) ...) とか
とすることでマクロ展開時に型を照合して変換とかで実現かなぁ。
でも、型推論とか暗黙の変換も自作しなきゃいけないし、個人的にはスルーしていい話だと思うよ。
Camlp4は知らないが、プリプロセッサだとすると1. 2. の情報を展開時に利用するのがだるいかもしれない。

>>338
マレーバクです。

マレーバク
http://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%AC%E3%83%BC%E3%83%90%E3%82%AF

暗黙の型変換がダメっていうのは、AOPがだめっていっていた風潮ににているな。
どこに何がはいってくるのかが分からない・・・っていう。でも、AOPも使いどころさえ間違わなければ、みんなありがたく使ってるでしょ？それと同じじゃない？

>>341
AOPは最適化、マルチスレッド化の邪魔
意味無い

まだ作られて間もない概念だから、みんなどんな時にありがたいのかが
わかってなくて、別の似た古い概念のイメージで
批判してるだけだと思う

このスレに関して言えば、一人の粘着が執拗に叩いてるだけだと思う

そもそも、全員が全員賛成するようなことじゃないだろ。
一般的に言って、メリットデメリットを言うのはいいが、
メリットしか言わないでマンセーしてる奴はカルトだよｗ

今はその以前の段階だろう
なんかわからんうちから先入観で批判してる印象

新しいものは何でも批判して旧弊に固執するような人が居るからこそ、
新しいものを学ぶ人間に儲けの目が出てくる。

頭が悪い人を見て批判するより、そこから儲けを出すほうが賢いと思う。

暗黙の型変換はAOPほど恐れる必要はない
スコープで制限されてるから暴発しづらいし、既存のメソッドの上書きなんかもできない
既存のクラスにメソッドを足すか、明示的に変換しなきゃいけないところを省略できるだけ

ただ、importは慎重にやらないといけなくなる
importすることで暗黙の型変換のメソッドも動くようになるから
importする前にどんなimplicit関数があるかチェックする必要がある

なんでexplicit見たいに暗黙の型を
禁止するキーワード無いの？バカなの？

>>349
そんなものを追加しても誰も使わないのでは？

こうゆう危険な機能があると流行らないね
C++も危険な機能満載だったから流行らなかったし

非明示的な型変換はケースによって必要ではあるし、変換規則を言語仕様に組み込んだ言語もいくつかあるが
プログラマにとって予想外の挙動がトラブルの元凶にもなっていた
そこで変換規則のスコープを制限すれば適度に使いやすくなるだろうと・・・・・？

発想は分かるが、うまくいくかはよく分からん
他言語での実験例はあるんだろうか？

>>352
言語オタの基地外しか思いつかないと思う

>>352
いくつもあるって、たとえばどんな言語？

そもそも暗黙の型変換で実現された機能がScala自身にたくさんあるという事実と、
Liftに大量に存在するという事実から、客観的にもう結論は出てるようなもんだと思う

結論解ってるやつ以外使えない
解りたければソースを読め

>>351
普通にScalaがC++以上に流行ることはないと思うけど？

>>356
解っているやつ以外使えないって当たり前だろ
むしろ解ってないやつは使うなよ

ttp://stackoverflow.com/questions/171489/explicit-type-conversion-in-scala
ケースクラスの場合？

C++が流行らなかったって・・・
さすがにそこまで無知なのはどうかと

>>351
またお前か・・・

>>359
ケースクラスじゃなくてもできると思うけど
Scala本に書いてある範疇
パターンマッチング推奨で、asInstanceOfはわざと長くしてるらしい

まじキチ…ユダヤが人工地震を起こすぞ

【緊急情報カクサンよろしく】

ついに来ました。

大きい動きです。250nT超えてきました。ほぼ間違いありません。もう一度言います。

友人、知人、親類縁者、あらゆるつながりを駆使して巨大地震がくることを教えて下さい。

四川地震より大きいのが来る可能性があります。
http://g★olde★ntam★atama.b★lo★g84.fc2.c★om/

★★★★★危険度ＭＡＸ★★★★★
★★★★★★★★★★★★★★★★

★千葉、静岡、東京、関東で大地震が起きる可能性が非常に高くなっています★★★
★千葉、静岡、東京、関東で大地震が起きる可能性が非常に高くなっています★★★
★千葉、静岡、東京、関東で大地震が起きる可能性が非常に高くなっています★★★
★千葉、静岡、東京、関東で大地震が起きる可能性が非常に高くなっています★★★

★★★★★★★★★★★★★★★★
★★★★★危険度ＭＡＸ★★★★★

警告！連休中の２１、２２、２３日が危ない！かも２
http://live24.2ch.net/test/read.cgi/eq/1★253494015/
【大気イオン】e-PISCO Part11【また延長】
http://live24.2ch.net/test/read.cgi/eq/1★252991726/

本当に地震が来たら、犯人は特権階級全員だということ２

イミュータブルでいつも同じ値を返す無引数メソッドは、valにすべきではない/defとすべき、なの？
Scala本に、
　def tail = new Queue(いつも同じ値,いつも同じ値2)
みたいのが載ってて、Queueはイミュータブルなクラスなんだけど、これは
　val tail = new Queue(いつも同じ値,いつも同じ値2)
の方がいいじゃん、て思ったんだけどなんでdefなの？

>>364
tail変数に別のQueueを代入したかったからじゃない？

>>364
valだとオブジェクト生成時点で評価されちゃう。tail欲しくないのに必ず
new Queue(いつも同じ値, いつも同じ値2)
とされちゃうのは嫌だよね。計算コストが無視できるくらい小さいならそれでも良いかもしれんけど。
lazy valなら最初にアクセスされた１回だけで済むから、lazy valにするなら良いと思うけど。

なるほど、そういうことか、サンキュー

ということは、valよりdefがよいという一般慣習ではないって事ね。
このtailは同一オブジェクトに対してあまり何度も呼ばれなさそうだというだけで、
ほぼ必ず呼ばれてかつ大量な回数呼ばれそうな場合はvalにして問題ないって事ね。

ちなみに、lazy valでないのは、単に本の構成上（このコードはlazyの説明より前に載ってた）の問題と思ってよい？

valをdefでoverrideとか出来るよね、確か。

valかdefかは効率の問題って感じ？

overrideできる時点でvalであってもバイトコード上ではinvokevirtual使っているのかも。
そうなると、評価にかかるオーバーヘッドも差はないのだろうな。
あとは、値の束縛タイミングで使い分ければいい感じかな・・・？

valもdefも同じシンボルテーブルで管理されるらしいから相互にオーバーライド可能。

scalaでは値(シンボルテーブルとしてはフィールド、メソッド、パッケージ、シングルトンオブジェクト)と型(クラス、トレイト)の2種類しかないって本に書いてあったですよ。

val は変数を定義式の値に設定
def は変数を定義式自体に設定
tail の場合、def だと参照するたびにコンストラクタが評価されることになるはず
つまり、初期化引数は同じでも生成されるオブジェクト自体は別物になる

valで定義すると、変数自体が外から見えるように思えるけど、
実際は、変数を返すだけのgettterが自動で生成されてる。
関数呼び出しコストはvalでも掛かる。

>>372
値が同じイミュータブルなオブジェクトを、呼ばれるたびに毎回作る意味は？

>373
valがgettter経由なのは、そのクラス内から参照した時もそうなの？
privateだと違うのかな？

試してみればいいんじゃないの。オーバーライドして違いを観察できるっしょ。

>>373
基本的にはそうだけど、private[this]なvalやvarはgetter/setter生成する必要が無いので、
内部的には直接フィールド参照するコードが生成されてる。

>>373
ミュータブル版の Queue を使うときにもプログラムを書き換えずに済むから？
正確な「意味」は当のプログラム自体を見ないと答えようがないけど (ちなみに私は Scala 本未購入)

>>377
手元のScala本のコード確認してみたけど、関数型言語では一般的な、(immutableな)ListのペアでQueueを表現
するやつだな。日本語版(p.352)から関係のある箇所だけ抜粋するとこんな感じ。tailから呼ばれるmirrorはtrailingの
長さによっては、コストがかかり得るので、valでなくdefにするのは理にかなってる。lazy valだともっと良いけど。

class Queue[T] (
　private val leading: List[T],
　private val trailing: List[T]
) {
　private def mirror =
　　if (leading.isEmpty)
　　　new Queue(trailing.reverse, Nil)
　　else
　　　this
　....
　def tail = {
　　val q = mirror
　　new Queue(q.leading.tail, q.trailing)
　}
　...
}

イミュータブルなデータからの部分範囲の取得は常に新しいオブジェクトとして生成されるべき
だから、この tail は引数なしのメソッドです、フィールドではなくて

>379
何でそうなるべきなのか、理由を書いてくれ。

abstract typeってなんでこんなのあるの？一度上位型扱いされたら使えなくならない？

abstract class 親型 {type Hoge; def fuga(Hoge)}
class 子型 extends 親型 {type Hoge=Foo; def fuga(Hoge){}}
として、
new 子型 fuga new Foo
は動く（コンパイル通る）けど、
val a:親型 = new 子型
a fuga new Foo
は駄目。わざわざ危険なキャストが必要になる。
a fuga (new Foo).asInstanceOf[a.Hoge]

こんなの、ちゃんと安全な型パラメタがあるんだから要らないじゃん？とか思うんだけど。

>>202
亀レスだが、val/immutable、var/mutableの絶対的な量を問題にするよりも、
val/immutableでいいところが、var/mutableになってないかという視点で、
クラスライブラリのソース見るといいと思う。
出来ないものをval/immutableにしようとしても、
それは無理な相談なのだから。

イミュータブルなときにdefとvalのどっちを使うかについては、
Scala本にはフィールドはメソッドに比べて速度が速いけどメモリを食うと書いてあるな
結局getter経由なのにフィールドの方が速いのだろうか

>>379-380
＞イミュータブルなデータからの部分範囲の取得は常に新しいオブジェクトとして生成されるべき

べきっていうかそれしか不可能でしょ。理由はimmutableだから。

>>381
それは使い方間違っとるがな。正しくはこう。

class Foo
abstract class 親型 { type Hoge; def fuga(hoge: Hoge) }
class 子型 extends 親型 { type Hoge = Foo; def fuga(hoge: Hoge){} }
val a: 親型 { type Hoge = Foo } = new 子型 // { type Hoge = Foo }の部分が必要
a fuga new Foo// コンパイル通る

というのはともかく、理論的にはabstract typeはGenericsと機能的には少なくとも同等(のはず)。
ただ、多数の型パラメータ引き連れてる型を継承したいとか、型パラメータを介して複数の型が相互依存関係にある場合とか、
型パラメータの一部だけインスタンス化して他のはabstractなままにしときたいとか、abstract typeの方が便利なことも
ときどきある。たとえば、パーザコンビネータライブラリのParsersでもabstract typeが使われてるね。これは、型パラメータが
あちこちに引き回されることを考慮してのことだと思う。

>>383
valは値を再計算しないけど、defは呼ばれるたびに本体評価するんだから、valの方が通常は
速いのはある意味当たり前かと(呼ばれる場合の話ね。defはメソッドだから実際に呼ばれるまで
評価されないので)。

>>384
キャッシュがあったらミュータブルじゃんて言いたいの？
外部から見えなくても？というか、遅延初期化もミュータブル？
つうか、空間効率無視すれば、初期化を遅延させなくてキャッシュもなしでイミュータブルな部分範囲に固定オブジェクトを返すのは可能でしょ。

補足
＞初期化を遅延させなくてキャッシュもなしでイミュータブルな部分範囲に固定オブジェクトを返すのは可能でしょ。
遅延させずに、初期化時に、必要な部分範囲オブジェクトを全部作っちゃうことを言ってる。

>>385
// { type Hoge = Foo }の部分が必要
おおなるほど。って、これ型パラメタそのまんまやん。
カギ括弧が嫌いな人以外にどううれしいのかよくわからんけど、普通はあんま気にしなくていいのかな。
Parsers使う機会があった時に感じられれば。

scalaのparser combinatorで

長さが1から8のdigitだけをacceptするような
定義を記述する場合

repN(8,digit)って感じで書けばいいのですか？

(x :: y) mkString ""

の””って何しているのでしょうか？

>>391
セパレータを指定してる。mkStringメソッドは、コレクションの各要素について
最初の要素.toString + セパレータ + 次の要素.toString + セパレータ ....
みたいな文字列を返すので、""を指定すると、単にコレクションの全要素をtoStringしたのを
つなぎあわせたのが返ってくる。

わかりました。ありがとうございました。

>>357
C++だと、templete、一引数コンストラクタ、ADLで、
暗黙の型変換が可能。典型的なのが_1 + _2。

scala のコレクション、ミュータブル系の操作が += とかで紛らわしいな。

そう思うなら使わなくていいんだよ

実際万人向けじゃないなと思った
なんかBoostを思い出す

万人向けじゃないってどこを指してるのかわからんけど、
他の言語もScalaみたいになっていくと思うよ

2445.544Dを解析すろとき

=>の続きってどうやってかけばいいのでしょうか
全部繋げたStringにしたいのですが

def test = rep(digit) ~ '.' ~ rep(digit) ~ 'D' ^^ {
case a ~ b ~ c ~ d =>　
}

a::: b :: c ::dじゃエラーになる難しい

List(5,4)とSome(A)を合成して

List(5,4,A)を作るにはどうすればいいのですか？

そのAっていう値の型は何よ。

>>364
携帯から浅はかな考えがらレスするが、
QueueがQueueを返すvalを定義すると場合によっちゃ無限ループじゃね？
最も、既存ライブラリがそんなバカな作りしてるわけないだろうけど
自身が自身の型をvalで定義するのはマズそうってのが俺なりのイディオム

>>399
def test = rep(digit) ~ '.' ~ rep(digit) ~ 'D' ^^ {
　case a ~ b ~ c ~ d => a.mkString　+ b + c.mkString + d
}
とかでどうよ。

>>400
Aが何型かようわからんが、とりあえず
Some(A)
が型Option[A]の変数sに入ってるとして、
scala> List(5, 4) ::: (s match { case Some(a) => List(a) case None => Nil })
res4: List[Any] = List(5, 4, A)

>>402
この場合(っていうか通常)は、無限って事はなくて要素すべての分だけ作られちゃうわな。
でもそのためにlazyってあるんじゃなくて？
lazyってあんま使っちゃいかん物？

>>405
＞lazyってあんま使っちゃいかん物？
んなこたーない。がんがん使っておけ。生成されたコード見てみればわかるけど、オーバーヘッドもさほど
大きくないし。

ちょっとParser Combinatorの書き方が解らないので助けてください。

def test = '\'' ~ rep(digit) | '\'' ^^ { case a ~ b ~ c => a + b.mkString + c}

この結果が > 4のとき成功するという長さを判別するにはどうしたらいいのでしょうか？

'1234'はOKで
'1'はNGにしたいです

レシーバの暗黙型変換っつうか新しいオブジェクトを作る暗黙型変換て、
最内ループで使われてると知らぬ間に無駄に大量のオブジェクト作って遅くなりそう。
new自体はまだよくてもGCコストが上がりそう。

>>407 知らないで適当に言うけど、パーサーひとつのみ引数に撮るrepじゃなくて、
ほかに回数指定できるコンビネーターがあるでしょ、多分。

マニュアル読め。
http://www.scala-lang.org/docu/files/api/scala/util/parsing/combinator/Parsers.html

repN(4,digit) ~ rep(digit) で良いんじゃない？

>>407
repN使うべし。>>409も書いてるけど、ライブラリの使い方でわからんとこあったら、
まずAPIドキュメント読むくせつけた方がいいよ。

うお。>>410とちょうどかぶった。

なんでJavaTokenParsersって

"test" ~ "test2"みたいな記述ができるの？

StdLexicalだとエラーになるのに

ちゃんとAPIドキュメントは調べたん？すでに複数人に指摘されているようだが。
http://www.scala-lang.org/docu/files/api/scala/util/parsing/combinator/RegexParsers.html#literal%28String%29

暗黙の型変換(implicit)を知らんのだったら、ちゃんと調べておかないとこの先もはまりまくりかと。

>>414
ということは、scalaを使う場合全部ソースコード
実装を把握しないと使えないと考えたほうがいいのでしょうか？

なんでAPIドキュメントが実装を把握するうちに入るんだ。

>>415
APIドキュメントは辞書だよ。判らない語彙に出くわしたら調べるのは当たり前。
ただし、Scalaには暗黙の型変換という、ソースに陽に現れない語彙があるので、
暗黙の型変換はちゃんと勉強しておくべき。

暗黙の型変換が罠っぽいという話は、このスレにも何度も出ている。

ドキュメントを読まない奴はプログラミングやめろ

どっちかつーとドキュメント書かない奴にやめてほしい

ドキュメントめんどくせーよ
ソース読む方が早い
だから綺麗に書け

綺麗なソースはドキュメントなくても読めるな
意図が分かる書き方されているのはすごく読み易い

きたなくてドキュメントないのが最悪

Liftって関数は何をしているの？

丸ごとの持ち上げ。

2.7.7 RC1

もう2.7系はバグフィックスだけでしょ？
2.8はいつ出るの？

scalaのWebフレームワーク Liftを使ったサイトはどんなのがありますか？
できればそれが載っている一覧とかが欲しいんですが。。。

ttp://groups.google.com/group/liftweb/browse_thread/thread/9009e6a030a32718

前に探したときも見つからなかったな。
オフィシャルで利用サイトの情報整理してないのかもしれないね。

>>426
>>427
ビジネスSNSのLinkedInはScalaを使っているようだけど、
Liftを使っているのか！？

質問です。

コンパイル時に大きなファイルをコンパイルしようとすると、「Exception in thread "main" java.lang.StackOverflowError」、となってしまうのですが、何かいい手はないですかね？
同様のものを、サイズを小さくするとうまくいくので、ヒープ領域が足りないためと予想されるのですが。
Javaとかだったらコンパイル時に-Xmsとか使えばいいのでしょうけど。

>Javaとかだったら

Javaだぜ！

>>429
環境変数JAVA_OPTSで、JVMに渡すオプション指定できるので
それ使うべし。

>>430
確かにほぼJavaですけどw　使い方がわからないです。
>>431
！　それは初めて知りました。ありがとうございます。

しかし非常に申し訳ないのですが、エラーの原因は何か違うものだったようでした。
本当にすみません。ですが、返信ありがとうございました。

ちなみに自分でつっこみますが、足りない(かと思った)のはヒープ領域でなくてスタック領域です。
なぜ間違えたのか．．．StackOverflowなのに．．．

scala以外にオブジェクト指向＋関数型の言語って他にあるの？
scalaに触発されて、似たような言語を作りたいって人はいるのかもしれないが、
そもそもそんな気持ちも起こらないぐらい、scalaの完成度は高い？

>>433
java -X
(前後省略)
> -Xss<size> set java thread stack size

>>434
OCaml……。

>>434
F#

>>434
Scalaは理論の分かる人の作った言語だから、
分からない人には似たような言語を作るのは無理。
型システムだけ取り出してもも理解できないのではないか。

アクター使うと
ネットワーク間で関数を受け渡せますか？

それアクター関係なくて関数をシリアライズできるかどうかってことでしょ。
一般的にはできないとおもうよ。

>>438
Scalaは難しすぎるから結局一部のお宅をを除いて普及しないでしょう。
Web開発で言えば、中小規模はPHP、大規模はJavaのまま当分行くんじゃないの。
Scalaは今が頂点でしょう。

MicrosoftはScalaに関してどう思ってるんだろう
F#でいいやって考えてるんだろうか

>>442
特に気にも留めてないんじゃない？一応.NETでも動作するとはいえ、ScalaのメインターゲットはJVM上だし。
MSが開発協力してくれたら最新の.NETに対応するのも楽かもなーとは思うけど、MSにとって
そうするメリットも無いし。

>>441
普及に関してはまあ今の時点では何とも言えんが難しすぎるというのは同意しかねるなあ。
Scala触る前は自分はJava使いだったが、結構すんなり理解できたぞ？

昨日からScala本買ってきて読んでるんだけど、List[Any]とタプルを言語的に分ける必要性がよくわからなかったんだけど、どこにあるんだろう？

関数をシリアライズできないって糞言語だろｗ

>>444
それはお前の頭が良すぎるせいだろ馬鹿が

Javaの知識を要求され、しかも関数型に慣れないといけないというのは
初心者にはハードルが高いと思う。
今の盛り上がりはJavaプログラマが流れてるだけで、
それ以外の人に振り向いてもらうのは難しいのでは。
それが逆に、Scalaが、Javaのある程度以上のレベルのプログラマにとっての
楽園になる所以なんだろうけど。

ゴスリングもお気に入りだからな

マーチンファウラーが出てくると
その言語は糞化するからヤバいけどな

>>445
どうしても必要なところ以外にAny使うのは馬鹿。

タプルはちゃんと型チェックできるじゃない
AnyはAnyのチェックしかできない

動的型付け言語で育つと>>445みたいな発想ができるんだな…
List[Any]は任意の型の要素。要素を取り出したときもAnyなんで
使いたい型に変換するときはキャストしなきゃならなくて安全じゃない。
タプルは(String, Int)みたいに自分で好きな型の組み合わせを指定できて
要素を取り出すときはちゃんとその型で取り出されるからキャスト不要で安全

Scalaは八方塞状態になっているJava使いの人達が、新天地を求めて期待しているだけだね。

八方塞状態になっているJava使いの人達が新天地を求めてScalaに期待している、
その通りかもね。

八方塞状態になっているJava使いの人達が新天地を求めてScalaに期待している、
その通りかもね。
その通りだべ

次の案件はJavaの代わりにScalaでよろ、
って上司が言ったら七月六日はサラダ記念日

( ；∀；)ｲｲｼﾞｮｳｼﾀﾞﾅｰ

辞めていいよ

翻訳の本かたよ。
まだ一章の途中だけどｗ読みやすい気がするよ。気がするだけじゃないと良いんだけど。
あと紙質が気に入ったね。
高校の時とか、問題集買う時はまず紙質をチェックしてたのを思い出した。

ゴスリングも
内心Java捨てて
Scalaに移りたいって思っているよ

自身でもないのに何でゴスリングの内心がわかるんだよ

四章の途中くらいまで読んだ。
まだ難しいのは出てきてない。だいたい１日一章として１ヶ月で全部読めるかなｧ？
みんなはどれくらいの期間で読めた？

休みの日二日だから延べ２０数時間くらいだったと思う。

>>463
仕事の合間にコードをほぼ全部写経しながらで
一か月くらいだったかなー。もうちょっとかな。
翻訳読みやすいですね。

関数型言語初心者なので、ループから再帰へ、
varからvalへ置き換えていくのが関数型言語的考え方というのが
とても面白かったです。

関数型言語で仕事やってる人いる？

返信ありがとう。

>>464
はやっ…。
速いと言うより、集中力があるってことっすね。

>>465
それで１ヶ月というのも速いですね。
職場に持ってこうかなぁ…。
自分も関数型言語は大学時代にちょっと触れたぐらいなので読んでて楽しいですよ。

>>467
仕事の合間と書きましたが嘘をつきました。
写経の合間に仕事してました。

フルタイムやってた日もありましたよ。
暇でねぇ・・・もうSIだめだねwww
はあ・・・

>>466
いるよー、ここに。

> 八方塞状態になっているJava使いの人達が新天地を求めてScalaに期待している、
> その通りかもね。
> その通りだべ

Java使いの方への朗報：
RORのようにお手軽にJava Webアプリを作れるフレームワークが公開された。
Play framework
http://www.playframework.org/

JavaでRORできても意味ないじゃんｗ
レン鯖Java対応しているところ高すぎるし

そんなもんに飛び付くやつは最初からJava使わんわな

scalaのlift　バンゼイ（万歳）！！！
しかしだれも使っておらんが....

>>471
専用は高いからVPSかAmazon EC2かGoogle AppEngine for Java当たりなら安い

Scala使うならVPSかAmazonEC2じゃね？
AppEngineはサーブレット中でスレッド使えないらしいからScalaの特徴を生かしきれない気がする。

その通りだっぽ！

applyってどうゆうときに使えばいいの？

これ読め。
http://www.ibm.com/developerworks/jp/java/library/j-scala07298.html

Scalaのリフレクションってどうやんの？
なんかいいライブラリとかある？

Scalaは無理、これ以上広がらない、並列処理の所が魅力的なだけだ。
これに必要性を感じる人はそういない。

結論：Javaでもっと良い物を作れ。
Struts：もう止めてくれ。
Wicket：URLがだめすぎる。
Tapestry：最先端過ぎるのか。
Click：もうちょっと広まっても良さそうだが。
Play：シンプルで良さそうだけどまだわからん。

Javaの愚痴はJavaのスレでやれ

Scalaが一般に受け入られるかどうかはWebフレームワークのLiftにかかっていると思うね。
そろそろStrutsから離れたいと思っている開発者は多いはずだけど、
次が見えて来ない。

そこでLiftだLiftが流行れば一般にもScalaが利用されるだろう。

Liftは難解すぎてRORようになれないね
変態が作ったオナニーフレームワーク過ぎてさｗ

>>483
それは言える、結局シンプルじゃないと普及しないんだよな
ほとんどは万人なんだから

少し前に見つけたけど、Play! frameworkと言うのがリリースされたらしい
Railsを最初見たときと以来の感動を受けたね
Scalaからも超シンプルなフレームワークが出て欲しいね

少し上の話も読めんのか
Javaのことは他所でやれ

Javaに寄生している
寄生虫言語が何いってんだかｗ

他の言語のスレで暴れるのはRuby厨と変わらんな

>>487
まさに別の言語の話を持ち出しているお前自身の自己紹介？
気持ち悪いから他所でやってくれ

>>488
だからRORなりPlayだのの話は他所でやれってだけ
ここはScalaのスレだから
しつこい

待て、君ら2人は同じこと言ってるんではないか？

>>488が言ってんのは、>>487がまたぞろ（Scalaと関係無い）Rubyの話を持ち出したことだろ

>>484
one is manyですか

Ruby厨がROR凄い、○○はRORがないから駄目っていつもの論法で暴れてて
Java厨がそれに無自覚に乗ってるからうざい、他所でやれって話しただけ
自分が使えないから駄目って発想のやつの愚痴は聞きたくない

>>493＝487？
結局Scalaと無関係なRuby厨の話題を持ち込んだってことじゃん
言い訳までしてスゲー格好悪い

>>483がRuby厨で>>484が無自覚に乗ったJava厨と言ってんの
なんでこんなこと解説せにゃならんの
つかなんで俺が絡まれてんの

Javaはともかく、脈絡なくRuby厨を持ち出したからじゃね

LiftはRORみたいになれない、オナニーフレームワークだって
まさにRuby厨の発言だと思うけど、あまりに自明すぎて見えないのかね
まあ問題はそこじゃなくてそれに乗っかるやつの方だけど

横槍だが、俺はそもそも"一般"には受け入れられなくても良いと思ってるんだが…。
一般用の言語じゃないっしょ？（一般の定義がどうとかいうのは荒れそうだからやめてね）
一部のコア開発者とかアーキテクトが使う言語じゃね？
オナニーで良いんだよ、このスレ見てるつはプロのオナニストなんだろ？ｗ

すまん、最後の一行はLiftの話と混ざってたようだ。余計だった。

最終的に仕事で使いたいってやつが多いんじゃないの
Javaの代替えと見ているやつは特に
でも言語なんてそう簡単に普及しないからね

俺はScalaは相当一般的な言語仕様だと思うけど
ちょっと変わってるのは暗黙の型変換くらいじゃないの
他は言語として正当な進化だよ

そういやLiftと言えば、
http://codezine.jp/article/detail/4310
これの続きはどうなった
(1)で終わりじゃないだろうな

<< 代替 >>

× だいがえ
○ だいたい

scalaの致命的な欠点は起動が遅いこと

>>502
そうでもないよ
試してみた？
xargsで呼ばれでもしない限り無問題

スクリプトをscalaコマンドで起動した場合？

移動も遅いし
コンパイルも遅い
話にならん

別に10秒待たされるわけでもあるまいし
ちょっとコードが大きくなればビルドなんてそんなもんでしょ

ちょっとしたスクリプトを気軽に実行、って
感じだともっさりだよね。

あとコンパイルは、気になるほどでかいの
書いた事ないんだけど、fsc使っても遅い？

>>470

そのPlay frameworkで遊んでいたらバージョン１．１で
Scalaをサポートするそうだ。

Lift以外にもScalaでWebが作れるようになるのかな？？

The Play 1.1 release will provide support for the Scala progamming language.
だそうだ。

じゃあ1.1が出たら触ってみるか
Scalaの関数も呼び出せるよレベルじゃないことを祈る

2.7.7 RC2

>>508

Play frameworkでScalaが本当にサポートされるようだぞー
詳しく次のURLを。。。
http://www.playframework.org/documentation/1.1-trunk/scala


次のコマンドでScala Web Appを作成
-------------------------
play new myApp --with scala
-------------------------

コントローラー
-------------------------
package controllers

import play._
import play.mvc._

object Application extends ControllerObject {

def index() {
render()
}

}
-------------------------

一応ちゃんと対応する予定なんだな

ScalaのアクターってIntel Q9550 x1 だと最大どれくらい
生成できるでしょうか？

>>514
それだけじゃなんとも。そもそも、Javaの１スレッドに対してＮ個のアクターが割り当てられる可能性があるので、
基本的にはメモリの許す限りいくらでも生成できるはず。仮に１スレッド１アクターとしても、ＯＳやJVMの実装によって
変わるので、ＣＰＵだけ指定されても何とも言えん。

Scala 2.7.7 final

これがなんで MatchError になるのか教えてください。

scala> Seq("a": Any) match { case Seq(_:Int) => true; case Seq(_*) => false }
scala.MatchError: ArrayBufferRO(a)

>>517 コンパイラのバグだね。 scala> Seq("a": Any) match { case Seq(_*) => false } res1: Boolean = false 以前レポートされた、Extractor使ったコードに関するバグ https://lampsvn.epfl.ch/trac/scala/ticket/1697 と同じ原因な気がする。

>> 518
ありがとうございます。
リンク先に 2.8.0 で修正されていると書いてあったので、
Nightly Build をダウンロードして試してみたら無事動きました。
急ぐわけでもないので、おとなしく 2.8.0 のリリースを待とうと思います。

ここひと月くらいで急激にモナドが認知されだしているような・・・なんかあったんですかね？
scalaだとListやOptionがモナドですね。他には何がありましたっけ？

scalaでモナドって何が嬉しいのか分からん
for内包表記がHaskellでいうdo構文っぽくてListモナドとして使えるのは分かるよ
それは便利だと思う
でもさ、それ以外のモナド（HaskellでいうMaybeとかStateとかReaderとかWriterとか)がscalaで便利かと言われるとどうよ？
もう正直モナドと言いたいだけなんじゃないかと小一時間

MaybeモナドはScalaのOption型だしこれは普通に便利でございますよ。

適切に名前付ければ、すぐに構造が理解できる。
Ideomってそういうもんでしょ。
モナド、いいじゃないですか。

>>522
>普通に便利でございますよ。
本当に？
for内包表記の中にOption型を返す関数を連ねていって最後にyieldした経験ある？
どういう時に使ったか参考までに聞いてみたい

んー、例えば某記事のような例ですけど、

def getId(): Option[Int]
def getNameFromId(id: Int): Option[String]

っていうのがあったとしてgetIdでIDがとれたときだけgetNameFromIdにそのIDを渡して名前を取ってくるみたいな問題があったときに

for (id <- getId(); name <- getNameFromId(id)) yield name

と書けばいいわけ。この式全体としてはOption[String]になる。

ポイントはgetIdで取れなくてもgetNameFromIdで取れなくてもNoneになって各々別々に失敗時のことを書かなくてもいいってことです。

>>525
ありがとう。解説してもらえるのは嬉しいんだけど
Option型の意味くらい分かっているつもりです。

>っていうのがあったとして
ここが曲者。記事にあるような創作例が聞きたいんじゃないのです。
普通に便利なら実際の"scala"プログラミングで応用したことがあるんじゃないかと思って。

しかしなんでscalaの設計者はdo構文ちっくなものを'for'にしたんだろう
名前もbindじゃなくてfilterMapだし
Listモナドにしか使うなと意図ならわかるけど、
scalaユーザーは無理矢理いろんなモナドに当て嵌めようとするのは予想できただろうに

えー、普通によくあるシチュエーションだと思うけど。。そう言われるとなんとも。

×filterMap
○flatMap

>>524は挑発的な釣り発言のようですね。

>524
Liftの作者が、よくScalaの便利な構文の例としてあげてるのは、
ページのパラメータを取得して、それをキーにDBから検索してみたいなやつ。
ま、LiftなんでOption型じゃなくて、それを拡張したBox型だが。

おい、お前ら！！
Scalaで引数の数が23以上の関数って作れるんでしょうか?

>>532
無理。引数の数N個の関数型は、scala.FunctionNにコンパイルされるので、
試しに自前でscala.Function30とかいうtrait作って、30個の引数の関数作ってみたけど、どうも
コンパイラ内部で特別に処理してるらしく、コンパイラが例外吐いて落ちたorz
ただ、無理なのは「関数」であって、メソッドとかはJVMの制限に引っかからない限りいくらでも
引数増やせるはず(うろ覚えだが、確か255個)。

Rubyのevalみたいなこと
もしくはStringで渡した名前のメソッドを実行するような方法ってないですか？

Stringで渡した名前のメソッドを実行するメソッドを作ればいい。
例えば前もってListを使って登録でもしておけば話は早い。

やっぱそういう方法になりますか
ありがとうございます

>>534
evalができるかどうかが動的か静的かの分岐点なので
静的な言語のScalaでevalは無理です

文字列からメソッドを呼び出すだけなら
例えばprintlnでhelloを出力するのは

Javaのリフレクション使えば
Console.getClass.getMethod("println", classOf[java.lang.Object]).invoke(Console, "hello")

2.8のリフレクションを使うなら
import scala.reflect.Invocation._
Console o Symbol("println")("hello")

こんな感じ

>>537
詳しくありがとうございます
2.8で確認できました

varとvalって紛らわしくない？
もうちょっと別になかったのかね。

Play frameworkって、RoRのActiveRecordみたいなのが無いって
どっかの記事で見た気がするけど本当？

fix a
var b
とかかな？

>>540
公式のTutorial見たらJPA使ってたね
Scalaから使うの面倒臭そう

valはともかく、varはわかりやすいと思うんだけど

視認性の問題じゃなかったのか

え、そうだったの？ごめん

ファイルの中のxmlのブレース構文の中に変数名を書いておいて、
プログラムで、同じ変数を定義して、xmlを読み込んだときにscalaの式として
評価できるのかな？
例えばこんな感じ

xmlファイルの中身
---------------------------------------------------
<a>
<b>
<param>{str1 + str2}</param>
</b>
</a>
---------------------------------------------------

コード
---------------------------------------------------
val str1 = "foo"
val str2 = "bar"

xml.XML.loadFileでファイル読み込む
パターンマッチとかでparam要素を取り出す
(変数 \ "param")でscala.xml.NodeSeq型になってる。

(変数 \ "param")は、<param>{str1 + str2}</param>
(変数 \ "param").toStringは、<param>{str1 + str2}</param>
(変数 \ "param").textは、{str1 + str2}
になって、foobarにはならない。

どうすればいいんだろ？

scala.xml.NodeSeqに含まれるブレース文字列を
評価できないものか・・・

ttp://www.scala-lang.org/docu/files/api/index.html
これの日本語版って誰か作ってないの？

>>546
実行時にScalaのコードをコンパイルして実行しないといけないね。
昔ウェブ上で誰かが調べてたの読んだと思うんだけど見つからない。

ただ結構苦労してた記憶があるので中身に書くのは本当にScalaじゃなきゃいけないかってのも考えておくといい。
Java(Scala)に埋め込めるスクリプト言語はいろいろあるよ。

ttp://d.hatena.ne.jp/t2ru/20091107/1257559576
文字列をScalaスクリプトとしてプログラム内でevalする方法

common lispとどう違うのかよくわからん

括弧が違う

>>500
なんか期待できない新連載が始まったなw
http://codezine.jp/article/detail/4475

>>552
その記事の筆者の会社ではScalaを実運用で使ってるみたいだから、実際に使ってみた結果得られた
知見とか書いてくれれば面白い連載になりそうな気がするんだけどな。Scalaの入門は、書籍も出たことだし、Webにも
入門記事はあちこちに転がってるから、よりadvancedな内容を書いて欲しいな。

php5.3よすよす

>>547
必要か？

>>555
必要

大した事書いてないよ

ソース読んだ方が早い

2.8はいつ出ますか？

(´･ω･`) しらんがな

ttp://d.hatena.ne.jp/pcl/20090408/p1
これのPythonより速いScalaバージョンが書けないんですが、
なんとかお願いできませんでしょうか、先輩。

実行時にマシン後にコンパイルしているものに勝つのは難しいかもしれないねえ

psycoを使用してないPythonより30%近く遅いのしか出来なかった

どうにか出来るほどの自由度がこのアルゴリズムにあるの？

いや、ちょっと待てよ
PythonよりJavaの方が速いんだろ？
だったらScalaだって速いんじゃねーか？

たぶんオレの書き方が悪いだけ
Scalaっぽくないし

import java.util.ArrayList;
import scala.collection.jcl.Conversions.convertList
object Primes
{
　　private def isprime( n: int, primes: ArrayList[int] ): boolean = {
　　　　val sqrt = Math.sqrt(n);
　　　　for (i <- primes) {
　　　　　　if (sqrt < i) {
　　　　　　　　return true;
　　　　　　} else if (n % i == 0) {
　　　　　　　　return false;
　　　　　　}
　　　　}
　　　　return true;
　　}
　　def main(args: Array[String]) = {
　　　　var i = 2;
　　　　val lim = args(0).toInt;
　　　　var primes: ArrayList[int] = new ArrayList[int]();
　　　　
　　　　while (i < lim) {
　　　　　　if (isprime(i, primes)) {
　　　　　　　　primes.add(i);
　　　　　　}
　　　　　　i += 1;
　　　　}
　　}
}

>>566
謝罪して帰れよ

Scalaである必要がないな。それならJavaでいいじゃん。

スクリプト＋jitってかなり早いよ
luaとかだとほとんどのアルゴリズムにおいてlispより早かった希ガス
前LLスレに各言語とアルゴリズムごとの速度と記述量のグラフが乗ったサイトが貼ってあって
いろいろ面白かった

俺はArrayListじゃなくて、ListBufferでやってみたけど
pyco 17s
scala 30s
おまけ　action script 40s
みたいな感じだった
秒数は体感で適当

>>563,566
PsycoなしのPythonに負けるなんて、それはなんかおかしいんじゃね？と思って試してみた。
自分の環境(Athlon 64 3000+, Windows XP, Python 3.0.1, Scala 2.7.5 final, JDK 1.6.0_13)だと、
そのコードでも
Python版(Psycoなし)： 3m44.146s
Scala版： 0m34.620s
となって、Scala版の方が圧倒的に速かったぞ？(Python版のコードは元記事のをそのまま使った)

>>571
いや、おまえには聞いてないから

>>569
ttp://shootout.alioth.debian.org/
のデータならあまり厳密じゃないから目安程度に考えるべきかと。
Fortran/C/C++/Common Lisp辺りの商用コンパイラは載っていないし。

Scalaっぽくカッコよく書こうとしたら10倍遅くなったでござるの巻
　　if (primes.take((Math sqrt i).toInt).indexWhere(i % _ == 0) == -1) {
　　　　primes += i
　　}

それはtakeが遅いんじゃないのかねえ

流れに乗って。こう書くと妙に遅いんだよなあ
ListBufferの特性が（というかScalaを）よく分かってないんだと思うが……

import scala.collection.mutable.ListBuffer

def isPrime(n:Int, primes:ListBuffer[Int]):Boolean = {
　　val sqrt = Math.sqrt(n).toInt
　　!primes.filter{ i => i < n }.exists{ i => n % i == 0 }
}

def main(args: Array[String]) {
　　val primes = new ListBuffer[Int]

　　(2 until args(0).toInt).foreach { n =>
　　　　if (isPrime(n, primes)) primes.append(n)
　　}
}

Python 2.6
Pyco使おうがCPython使おうが全く一緒の実行時間だった
なんでだろう
Scalaより早い

かっこよく書こうとしたプログラムが次々と撃沈して、
結局Java風に書いたやつが一番早いっぽいな

俺の環境でやったら>>566でもpsycoありのPythonより辛うじて速かった
そして確かにScalaらしく書こうとするとどんどん遅くなるでござるｗ

Java 6　23s

jcl.Conversionsなんて使わずにベタにwhileで書いたら
psycoありのPythonより倍くらい速いね、当たり前だけど
そしてScalaの意味が全くないけどｗ

5000000回、C++がおかしいな

Python　　　　　　26.4690001011
Python(psyco)　 3.14100003242
Java　　　　　　　 4.84299993515
Scala　　　　　　　8.625
C　　　　　　　　　 1.3599998951
C++　　　　　　　 4.67200016975
C#　　　　　　　　 1.45299983025
Lua　　　　　　　　19.7030000687

>>582
その程度なら誤差と考えていいだろう
どうせコンパイルオプションが悪いとかそんな感じだろ

psycoはやいのね

scalaが糞って証明されたな

そこまで糞か？
遅くてもJavaの1.5倍程度みたいだし
糞というほどでもないような
これで糞とか言い出したらpsycoなしのpythonはやばいぐらい糞になってしまう

cython

C++は糞

何がScala的かを考えないとあまり意味ない比較になるな
Javaっぽく書けばJavaとほとんど速度変わらんはずだし

お題にそって素直に書けばこんな感じかね
でもこれだと遅いんだよなあ…


import scala.collection.mutable.ArrayBuffer

object Primes {
　def isPrime(n: Int, primes: Seq[Int]): Boolean = {
　val sqrt = Math.sqrt(n)
　　for (i <- primes) {
　　　if (sqrt < i) return true
　　　else if (n % i == 0) return false
　　}
　　true
　}

　def main(args: Array[String]) {
　　val primes = new ArrayBuffer[Int]
　　for (i <- 2 to args(0).toInt; if isPrime(i, primes)) primes += i
　}
}

JavaがあればScalaなんて不要ってことだろ

たとえば、>>574はtakeであらたなリストを生成する
>>576はfilterで新たなリストを生成する
これがループの内側にあるので遅くなるのだと思う
Scalaは関数型的に書くと、副作用を起こさないように
新たなリストを生成しようとする
そのために遅くなるのだと思う

>>590
それはボトルネック部分に限った話
それ以外の他の部分では、
遅くなってでも簡潔さを重視したいときの方が多いだろ

>>592
それは業務系しか経験していないバカと学生の
DQN思考だ。

>>593
それは業務系と学生の用途ならScalaの意味はあると認めたことにならないか？

Javaなんて業務系でめちゃくちゃ多用されてるんだから
充分代替としての意義があるだろ

>>593
どこがどのようにDQNか言わないと誰も納得しないよ？

>>593
ボトルネック以外の部分を速くしてどうするの？

でも>>566のソースを見るとたいしてJavaと変わらないじゃん
書き方だけの問題なのかな？
俺にはScalaが、自動型推論によってJavaに比べて圧倒的に
簡潔になるというのは、少々過大評価に思える

566を見て言うか！

>>598
いや、>>566はConversionsで暗黙の型変換したあとにfor(つまりflatMap)してる
これをベタにwhileで書き直せばJavaとあまり変わらん速度になる

今回出たコードの中でJavaより目に見えて簡潔になってるの
は>>574くらいだろうけど、これを見て意味がわかる？
遅いしさ

ぶっちゃけJavaがC系より遅いのは
Integerのautoboxing/autounboxingのオーバーヘッドだろ。
純粋intで書き直せば10000000ループで2.5秒だったよ。

Scalaが遅いのも当然同じ問題だろ。

>>600
速度の問題が解決しても、簡潔さはあまり改善されてないだろ

int配列の長さはどうしたん？

おいおい、流れくらい読めよバカ
・C系じゃなくpythonと比較してる
・JavaよりもScalaの方が重い。設計上の問題

native scala作れば解決するんじゃね
流行るかは知らん

>>603
いや、俺はお題的に関数呼び出しのオーバーヘッドもあるかなと思って
isPrimeを別関数しただけで、簡潔に書こうと思えば、もっと色々書けるよ

美しく書く必要ななんてないんだよ
案件ないんだから、汚く書いて延々と保守できるJavaが
好まれるんだし

保守したいなら美しく書いてあるほうが楽だろ

簡潔な表現って基本的に保守のためだろ

>>574はバグがありました
ちなみに、scala 2.8じゃないと多分動きません

var primes:ListBuffer[Int] = ListBuffer()
for (i <- 2 until limit;
　　 if (primes.indexWhere(x => x < (Math sqrt i).toInt &&
　　　　　　 i % x == 0) == -1))
　　　　primes += i

takeも関数呼び出しもないけど、やっぱり遅いです
なぜだか自分にもわかりません

でもJavaより超簡潔だな

>>611
それだとListを全探索してるから遅い

JavaとScalaを修正したら同じになった

Python(psyco)　　7.26499986649
Cython　　　　　 11.5780000687
Java　　　　　　 3.73500013351
Scala　　　　　　3.85899996758
C　　　　　　　　3.20299983025
C++　　　　　　　3.28100013733
C#　　　　　　　 3.3599998951

美しいというのはfilterだのindexWhereだの変てこな関数満載で
読めないコードのことか？

>>614
ソースきぼんぬ

indexWhereってこれか

def indexWhere (p : (A) => Boolean, from : Int) : Int
Returns index of the first element starting from a start index satisying a predicate, or -1, if none exists.

filter使った方が素直なような

>>614
>>582の人？全体的にほかが遅くなった？
あと、どうやって修正したの？

>>617
時と場合によりけりだろうな
今回はどっちでも

CythonよりPsycoの方が実は速いのか？

>>618
ループ数を2倍

コードは上のほうで誰かが言ってたように

val sqrt: int = Math.sqrt(n);
val l: int = primes.size();
var j: int = 0;
while (j < l)
{
　　var i: int = primes.get(j);
　　if (sqrt < i) {

Javaも同じようにwhileに変更。
あとC++のコンパイルオプションを修正

>>621
なるほどサンクス
forよりwhileのほうが速いのか

全部intかよwwww
Scalaの意味ますますナッシングｗｗｗ

>>623
型指定取っても速度かわらんかった

この場合の推論は全部してくれるな。そして注釈書く場合もintじゃなくてIntだよ。deprecatedって出るでしょ。
ついでにいうとセミコロンも書かなくていいよ。

>>611
そのコードまだおかしいぞ、indexWhereの中は
(x => x < (Math sqrt i).toInt && i % x == 0)
じゃなくて、
(x => x <= (Math sqrt i) && i % x == 0)
じゃないのか？

>>622
forはforeachの呼び出しに展開されるから、関数呼び出しとかautoboxingのオーバーヘッドの分、whileより
遅くなる傾向がある。2.8だと@specializedアノテーションてのが入ってautoboxingのオーバーヘッドは無くなるから
今よりforとwhileの速度差はかなり小さくなるはず。

>>615
filterとかの高階関数使ったコードが変てこで読みにくいってのは単に修行不足
COBOLERが関数使ってないべた書きのコードの方が読みやすいってのと同じ理屈だよ
高階関数使った方が一般に抽象度が高いんだから。

>>626
それはお前がおかしい

PythonとPsyco入れて計測してみたけど、

Python+Psyco: 21秒
Scala (命令型スタイル, ArrayList, while): 11秒

で元のブログの人とおんなじような結果だな。ArrayBuffer[Int]にしたら14秒だったのは見なかったことにしよう。

ArrayListはJavaのライブラリで、ArrayBufferはScalaのライブラリなんだからしょうがない
結局関数の呼び出しの速度ではScalaはJavaと同等で、あとはライブラリの問題ってことだな

>>573のサイトでもScalaはJavaより若干劣る
同等ってことはないかと

Psycoがかなり速いのが驚き
正直数倍ぐらいは差がつくかと思ってた

>>632
それはおそらくプログラムの書き方の問題で、Scalaの関数呼び出しはほぼ直接的にJVMのメソッド呼び出し命令に
マップされるから、原理的に関数呼び出しの速度は(ほぼ)同等になるはず。

簡潔さならpythonの記述力も侮れない
　　for i in range(2, limit):
　　　　if len([x for x in primes[:int(i ** 0.5)] if i % x == 0]) == 0:
　　　　　　primes.append(i)

>>634
引数のアンボクシングとボクシングみたいなのが結構
あるんじゃないの？
よくわからんけど、独自の型多いし

from itertools import ifilter, count
def primes():
  g = count(2)
  while True:
    p = g.next()
    yield p
    g = ifilter(lambda n, p=p: n % p, g)

よくわからんけど遅いに違いないと思うならまずわかろうとするところからだ。

Scalaはリストリテラルがないし、リスト内包表記もないから、
リスト関係の記述の簡潔さを競われると分が悪いんだよね

内包表記はあるんだけど。。

一連の流れを見て思ったのは、C#はえーって事。
C#もautoboxingしてるはずなのに？

>>636
boxing/unboxingに関してはJavaも条件同じだよ(コンテナにIntなどを挿入する場合)。そして、Scalaでも
必要無ければ勝手にboxing/unboxingされたりはしない。つか、よくわからん独自の型って何よ？
AnyVal配下のInt,Long,Float,Double,...は全部バイトコードレベルではJVMのintやlong型にマップされる
から効率は変わらんぞ。それ以外の型はほぼ、単にScalaで実装されたライブラリに過ぎんし。

>>641
C#のGenericsは型情報残ってるから、コンテナにプリミティブ型入れるときのautoboxingは要らんはず
たぶん、その辺が効いてるんじゃないかなあ。

JavaではおとなしくTIntArrayList使えってことだな。

>>629
ちゃんとデバックしてみてよ、動作おかしいから
>>635を書いたのも同じ人だと思うけど、アルゴリズムを勘違いしてるよ
最初のsqrt(i)個の素数じゃなくて、sqrt(i)以下の素数を調べればいいってことだよ
「エラトステネスのふるい」で検索してみてよ
って俺も今調べたところだけどｗ

それで、これって案外、関数型的に書くの難しいね
単純にfilterとかindexWhereを使うのは効率化の意味がない
じゃあどう書けばScala的で「ある程度」効率がいいのかを考えたけど、

import scala.collection.mutable.ListBuffer

object Primes {
　def main(args: Array[String]) {
　　val primes = new ListBuffer[Int]
　　for {
　　　i <- 2 to args(0).toInt
　　　if !primes.take(primes.indexWhere(_ > Math.sqrt(i))).exists(i % _ == 0)
　　} primes += i
　}
}

こんな感じじゃねーかな
これでもめちゃくちゃ遅いけどね
まあ、Scalaは簡潔にも書けるし、いざとなったら
Javaみたいに書いて高速化できるっつーことで

>>645
その人ではないが>>566も>>587も>>589も全部if (sqrt < i) になってるのを見て
変だと思わなかったのか？

untilじゃなくてto使ってるから勘違いしたのか？

if !(primes.takeWhile(_ <= (Math sqrt i)).exists(i % _ == 0))
の方がいいな

このソースコードでpsycoより早くなる人いる？
俺の環境が悪いのか･･･

def main(args : Array[String]) {
　println("start")
　var primes:ArrayBuffer[Int] = new ArrayBuffer[Int]()
　for (i <- 2 until 1000 * 10000){
　　if (isPrime(primes, i))
　　　primes += i
　}
　println("done")
}

def isPrime(x:ArrayBuffer[Int], y:Int) : Boolean = {
　for (i <- x) {
　　if (i > (Math sqrt y))
　　　return true
　　if (y % i == 0)
　　　return false
　}
　return true
}

>>647
ああ、takeWhile失念してたわ
それが答えだね

>>648
俺の環境だとそれとpsycoのやつでほとんど同じくらい

Lift連載第二回

Scala＋LiftフレームワークのView/Template
http://codezine.jp/article/detail/4512

Python(Psyco)早すぎてワロタ
元サイトの時間はCとC++が一緒なのだが、
最初にのみmallocしてるCとC++が一緒って変じゃないか？
コンパイル時に賢くなんかやってくれてるのかな

scalaは速度が必要な場合はJavaに近い速度の書き方ができるわけだが
上の流れを見てるとJavaというかプログラムのことをよくわかってない
人も結構いるから、誰でも同じようにかけるJavaみたいなのも必要だな

>>626 >>645
ご指摘ありがとうございました。

>>645
試しにStreamを使ってみたら、けっこう速くなった(Java風には敵わんが)
if !Stream.fromIterator(primes.elements).takeWhile(_ <= (Math sqrt i)).exists(i % _ == 0)

Streamってのはなんだ？
takeWhileでも新しいListを生成しないやつなんだろうなとは思うが

まず口の利き方を勉強したまえ

Streamはメソッドチェインしても逐次的に処理してくれるのか。

わざわざStreamを使わなくても、Iteratorを使えば同じことが出来た。
if primes.elements.takeWhile(_ <= (Math sqrt i)).forall(i % _ != 0)

なぜexistsをforallに変える必要があるんだ

>>651
いや、俺は逆だと思うよ
元のプログラムがわかりづらいんだよ

今回のアルゴリズムは、ある数nが素数かを調べるには
sqrt(n)以下の素数で割り切れるかを調べればよい、という話だが
>>647はそれをすっきりと表現している
最初からこれを見たら間違うやつは少ないと思う
でも、元のプログラムだと、そういうアルゴリズムだって
なかなかわからないんだよ、注意深く読まないと

最初から低級な書き方で書いていくと
どんどん読むのに労力がいるプログラムになってしまう
だから最初は関数型的に簡潔に書くべきで、
問題が起きてから書き下せばいいってのが、今回の教訓だと思うね

>>657
ライブラリのソース見たけど、IteratorのtakeWhileって何もしてないな
hasNextに判定を差し込むだけだから、確かにこれは速い
ライブラリ実装依存の最適化はあまりよくないと思うけど、しょうがないか
それでもpsycoとか>>648の倍の時間がかかるけど
まあ、一行で書いてそれなら十分か

>>658
'!'の処理が必要なくなる分だけ速くなるかと思って試しに修正して戻し忘れてた。

>>660
takeWhileの実装というよりは、Iterator自体の性質の方が性能に影響していると思う。
Iteratorであれば、必要に応じて要素を計算するので、2や3で割り切れる場合に無駄が少なくて済む。

あと、Iteratorみたいな遅延リストって、関数型言語ならたいてい持っていると思うので、
Scalaのライブラリ依存の高速化テクニックという訳でもないと思う。

>>661
なるほどなるほど
Iteratorのメソッドならチェインしてもたいてい速いと
勉強になった

イテレータが遅いんじゃ話にならんがな

まだ4倍遅いな

標準の Iterator#takeWhile が遅いようだ。
takeWhile を自作すれば速くなるが、やりすぎか?

def myTakeWhile[A](it: Iterator[A], p: A => Boolean) = new Iterator[A] {
　private var cached = false
　private var nextCache: A = _
　private var hasNextCache = false
　def hasNext = {
　　if (!cached) {
　　　cached = true
　　　if (it.hasNext) { nextCache = it.next; hasNextCache = p(nextCache) }
　　　else hasNextCache = false
　　}
　　hasNextCache
　}
　def next =
　　if (hasNext) { cached = false; nextCache }
　　else throw new NoSuchElementException("next on empty iterator")
}
def main(args: Array[String]) {
　val primes = new ArrayBuffer[Int]
　for {
　　i <- 2 until args(0).toInt
　　if !myTakeWhile[Int](primes.elements, (_ <= (Math sqrt i))).exists(i % _ == 0)
　} primes += i
}

いやいや、自作のそういうメソッドを既存のクラスに付加できるのも
Scalaの立派な魅力

あぁそうか、暗黙の型変換を使えば良かったのか

lift ってどうなの？ごちゃごちゃしてる感があるんだけど。

maven必須なのがなんとも

hasNextをchache化するとなんでtakeWhileが速くなるんですか？

引数の型がObjectの関数に数値や文字列などを渡したいんだけどどうしたらいいの？

もしかして、このスレって 2.8.0 が前提なの?
2.8.0 のソースを見ているとしか思えないレスが散見されるんだが(>>660,670)

>>671
文字列はAnyRefのサブタイプなのでそのまま渡せる
Intとかもimplicit conversionが定義されているので、本来ならそのまま渡せる…はずなんだけど
他のimplicit conversionと衝突しているせいで、エラーになる。解決するには
foo(num:java.lang.Integer)
みたいにして、java.langにあるラッパークラスに変換してあげると良い
(fooはAnyRefを引数に取る関数)。

このスレは3.0前提だよな？

>>674
3.0って一体いつになるんだよw

ああ、2.7と2.8じゃ、ソースコードが全然違うね
2.7は同じプログラムでも倍くらい遅いわ
elementsメソッドがobsoleteになってるからまぎらわしかったね
ちゃんとiteratorと書かなきゃ駄目だったね、いまさらだけどｗ

>>665 は、2.7.7 を前提として書きました。
2.8.0 のソースを見る限り、わざわざ takeWhile を自作する必要はないようなので、
2.8.0 の方は >>665 を無視してください。

基本的にはVerとか示すのが一番なんだろうけど
まぁ大体分かるしいいんじゃないの
宿題スレだと必須だけど

NetBeansのscalaプラグインってimportの保管してくれないの？

う〜ん・・遅い・・・う〜ん・・・

なんで関数型言語って並列処理に適してるんだ？いまいち理由がわからん。
あとerlangにしろscalaにしろアクターとかを言語レベルでサポートしてるのはなぜ？別に関数型言語にアクターは必ず必要ってわけではないよね？

アクターやCPSなどの並列モデルに関しては、
スレッドなどと一緒で、有望や成熟した物が、
徐々に主流なものにサポートされていくだけだとおもう。

元々の言語に向き不向きはあるかもしれないが。

関数型言語が並列に向いてると言われてるのは、
参照透明性があれば処理を別々にしやすいからじゃね

いままでの分散処理では、チューニングすれば速度の出るMPIとかは特別な用途向けで、
一般的なプログラム向けとしては、それを仮想的な共有メモリモデルに
当てはめて処理能力を上げるかを研究してきたというのがあった。
↓
それに対して、WebスケールのプログラムやPCでの同時処理数が一般的になるなかで、
共有メモリ上での処理は、CAP定理というので、結局スケールしないことも分かってた。
↓
DBにしろ言語にしろ共有しないで動作する機構を単位とするものが必要になってきて
それには、不変型で処理する関数型とかメッセージパッシングとかが必要だ。
↓
特殊な言語じゃなくて、Cのような主流の書き方が出来る言語で出来るようにしよう。
↓
Scala出来たよ。←今ここ
↓
C/C++とかJava/C#でもサポートされる。

>>681
関数⇒副作用無し(入力が一意なら出力も一意)⇒関数の依存関係だけで並列実行可能性が決まる⇒並行処理でウマー
というのが基本的な考え方。とは言え、実在の処理系でソレが実現できているかは別問題だったり。

あと、ScalaのActorはライブラリでの実装で、言語レベルでは何もしてないぞ。
Erlangの方は、そもそもアクターがないとまともなプログラムが書けない言語仕様。

Scalaは、なぜ関数の副作用の有無を判別出来るようにしなかったんだろう？
var/valみたいに。

実際には副作用があるけど外から見ると無いように見える関数とか作れるからじゃね
というかどっちにしろコンパイラが賢くないと意味なさげ

それを明示できるようになったとしたら、
Cのconst引数と同じで、コールスタックの深いところで副作用のある関数を
使わななきゃいけなくなったときにえらい目に合う気が

>>688みたいなこと、たまにやるわ。
自分の設計が悪いんだろうけどがっくりする。
一方でmutableなのかわかったほうがいいとも思う。
IDEのリファクタリングなどの機能でなんとかならんかね

lift本ってどう？

>690
索引が無いとか、有るはずのappendixが抜けてるとか、てきとーな作り。

でも、一通り読むと役に立つよ。一通り読んでもやっぱりソース読まないと
アプリ作れない気もするけど。

scala結構気に入ったけど
これは流行らないだろうな

Java7にクロージャが入ったし・・・

scala好きになれない…
やりたい事はわかるけど…
あっちこっちの言語の継ぎはぎにしか見えない。
統一感がない。美しくない。

>>693
Java 7に入る予定のクロージャは超劣化版といってもいいもので、
あれが入ったからといってScalaのメリットが無くなるとはいえないなあ。

>>694
あっちこっちの言語の継ぎはぎに見えるのは、君が中途半端に色々な言語
かじっているせい(で、そう思い込んでいる)だと思われ。少なくとも設計理念は
割と明確な言語だと思うよ

ちなみに設計理念てのは、オブジェクト指向プログラミングと関数型プログラミングの統合のことね。
OCamlなんかもオブジェクト指向と関数型のハイブリッドだけど、あっちはMLライクな型システムの上に
オブジェクト指向機能を足していったものなのに対して、ScalaはJavaライクな型システムと言語仕様の
上にどのような機能を載せれば関数型プログラミングが容易にできるかを考え抜いて作られた言語だと思う。
一見色々機能があってごちゃごちゃして見えるけど、ほとんどの機能が関数型プログラミングを容易にする
ためという点で一貫している。

Java見た後だとなんでも良く見える

>>691
感想ありがとうございます。
lift本ってGoogleグループにあるPDFファイルと内容は同じなの？

もう少し低能プログラマにも配慮しないと
普及は難しいだろうな

それってどこのJavaのこと？

その辺はIDE次第かな。

Emacsでも書けるほど簡潔な言語じゃないと駄目というのが俺の持論

>>696
>ごちゃごちゃして見える
言語の継ぎはぎだからでしょ？

>Javaライクな型システムと言語仕様の
>上にどのような機能を載せれば関数型プログラミングが容易にできるか
やりたい事はわかるよ。
美しくないだけ。

>>703
どう継ぎはぎなのか自分の言葉で説明してみたら？

デフォルトがpublicなのがいい

Groovyだと、groovy-all.jarをクラスパスに突っ込んでおけば、普通のJavaと同じように
java -jar hoge.jar
といった感じで実行できるのですが、
ScalaをJavaに混ぜた場合、このような形でプログラムを作るにはどうすれば良いでしょうか？

>>706
Groovyの場合とあんまり変わらん。scala-library.jarをクラスパスに通せばＯＫ

>>696
> オブジェクト指向プログラミングと関数型プログラミングの統合のことね。

統合なんてされてないが?
関数型的なはごく一部だし、
この程度なら今時の言語はほとんど入っているか、入れようとしている。

設計理念ならJoin計算とか型理論とかその辺だろ。

>>708
高階関数、パターンマッチ、代数的データ型、多相型、抽象型、…
現代的な(静的型)関数型言語が持っている機能はほとんど持っているよ。ファンクタでさえオブジェクト＋
抽象型でエミュレートできる。特にML系言語が持っているまともなパターンマッチ持っているのは
少数派だろ。いまどきの言語が取り入れてるのはせいぜい高階関数と多相型までで、パターンマッチ
とか代数的データ型取り入れてるのは少数派だ。あと、Scala自体はJoin計算とはあまり関係ないよ。
型理論はScalaの型システムを設計するに当たって駆使されてるのは間違いないが、それは設計理念
とは別の話だ。

確かにパターンマッチがあるのは地味に嬉しい
クロージャなんかは他の言語でもほとんど付くようになったけど

仮に「オブジェクト指向プログラミングと関数型プログラミングの統合」が設計理念だとしても、
その設計理念が「この言語は継ぎ接ぎですよ」の言い換えに見えるんだけど

それにたとえば、>>709なんていかに多くの機能を継ぎ接ぎして
取り入れているかという説明にしか見えないんだが？

一般的に、継ぎ接ぎという表現は「継ぎ目が見えている」ということに
ウェイトが置かれているものではないかな。
つまり、「統合しきれていない」という「現状・結果」のネガティブ表現であることが多いと思う。

だから「統合という理念」が「継ぎ接ぎの言い換え」であるという解釈は適切ではないように思う。

もっと具体的な話をしろや

>>713
「オブジェクト指向プログラミングと関数型プログラミングの統合」という
言葉か「継ぎ目が見えていない」をイメージする人は少数派で、
単に「同一言語に二つの機能が入っている」ことをイメージする人が多数派であると俺は思うよ。
そして、それは一般的には継ぎ目が見えていることを意味する。

Pythonの作者もScalaの型システムなどについて、コンセプトが
数多く含まれすぎているという趣旨の批判をしているな
これは継ぎ目が見えているという批判に他ならない
http://neopythonic.blogspot.com/2008/11/scala.html

継ぎ接ぎかどうかなんてどうでもいいよ。使い易くて醜くなければ。

動的言語の作者が静的な型の複雑さに文句を言うのはいつものこと

Haskellはなぜか褒めてるけどな

型がないPythonとかガチガチの関数型のHaskellの方が綺麗ってそりゃそうだろって感じだな
色んな機能を持ち合わせた上でどれだけ簡潔に書けるかってことだろ
その点でScalaはよくまとめてると思うよ

それは言い訳じゃないかな

勘違いしてる人が多いけど、Pythonの作者がScala自体を批判したのであって、
Pythonと比べて批判したわけではない

>>722
そりゃポジショントークなのは明らかだろ
まつもとだって他の言語をよく批判するし
とにかく他のやつの言葉をもってくるんじゃなくて
自分で気に食わない点を言えってことだな
抽象的な言葉じゃなくて

>>720
「〜にしては」よくまとめているというが、それは
結局、そういうことを考慮しなければまとまっていないということだろう
動的言語の方がシンプルなのは当たり前というが、
だったら動的言語にすればいいこと
いろんな機能を持ち合わせた代償として複雑な
仕様になったというのなら、そのこと自体が間違っている
ことになる

>>723
で？批判されてることにかわりないわけだが

>>724
シンプルなことが全てじゃないってことだよ
シンプルなのが最強ならSchemeが最高だろうな
静的な型を持ってれば、宣言で汚くなるか、
ミルナーの推論の制約を受けて動的な言語よりやれることは少なくなる
だったら型チェックをやめればいいってのは暴論
あとはトレードオフとバランス感覚の問題

>>725
だったらこっちはScalaを褒めている有名人のリンク集でも作れっていうのか？
馬鹿馬鹿しいことになるだけだろ

>>726
結局、トレードオフやバランスの問題で、ほかよりつぎはぎな言語である
ということだろ

>>727
いや、ぜんぜんばかばかしいことはないよ
継ぎ接ぎではなく、シンプルな言語仕様に統一されている
という趣旨のリンク集が作られればとても参考になるだろう

継ぎ接ぎだらけであるという事実を覆すような
反論は何一つとして出ないな
「多数の機能を取り入れてるにしては」だのと、
条件付きでの反論があるだけで、結局、トレードオフとして
継ぎ接ぎだらけであると認めている意見しか出なかった
継ぎ接ぎだらけであるというのが結論のようだな

>>728>>729
だから「つぎはぎ」って言いたいだけだろ
水掛け論にしかなってない
機能を減らせばシンプルになる、増やせばそれなりに複雑になる
そういうことでしかない
BASICから見れば、Javaだって複雑怪奇な言語にしか見えんだろうさ

やけに伸びてるかと思えば‥‥

機能の多い言語＝継ぎはぎだらけって定義なら、そりゃ言うまでも無く
Scalaは継ぎはぎだらけだろう。だが、そういう事言いたいわけじゃないだろう？
まず、継ぎはぎだらけというのがどういう事なのか、具体例を挙げて批判してくれ。
Guidoの批判は、Scalaをけなしといて一方でHaskellを褒めてるあたり、どう見ても
静的型システムを良く知らずに批判してますって感じで、全然あてにならん。

あ、>>728見ると、シンプルな言語仕様＝継ぎはぎではないって意図なのね。
じゃあ、>>728的にはScalaは継ぎはぎでいいよ、もう。Scalaの言語仕様が
そこそこ複雑なのは事実だから。だが、そんなこと言い出したら、Scheme以外
は皆継ぎはぎだらけみたいなあまり意味の無い結論しか出てこないぞ。

機能の実現ということでいうなら、Schemeはオブジェクト指向の機能も
関数型言語の機能も全て実現できるんだが

>>715
でもうまく行ってたら、たぶん継ぎ接ぎとは言われないんじゃないかな。

うまく行こうが行くまいが、悪くいう奴は出てくるからなぁ

Scala擁護してる人の中にSchemeが好きな人がいるみたいだけど、
Schemeを見ればScalaがいかに継ぎ接ぎだらけかということに気づかない？
マクロさえ使えばScala以上の機能がいくらでも使えるのにシンプルな言語仕様

だったらScheme使って日常のスクリプトとかサーバプログラミングとかやってみればいいさ
どれだけめんどいかわかるから

>>738
つ　普通のやつらの上を行け

>>737
Scheme厨乙。マクロがあれば、「頑張れば」大体なんでもできるのは事実だが、マクロで実現した機能だと
実行性能や分割コンパイルなど、実用的には色々難しい面があるってのを考えといた方がいいぞ。
Common Lispにそれなりに支持者が居る理由を考えてみた方が良い。
あと、ちゃんとした静的型システムは(少なくとも)Schemeのマクロだけで実現するのはまず無理。
型チェックを網羅的にやろうとすると、関数定義や変数定義は全部独自のマクロで定義したものしか
型付けできないみたいなことになって、本末転倒だから。

あとね、マクロって言っても本質的には所詮S式→S式のトランスレータが簡単に書けるというものでしか
無いわけで、マクロがあればどんな言語機能も簡単に実現できるわけじゃねーんだから、あんまりマクロ
を持ち上げ過ぎるのもどうかと思うよ。Scalaだってコンパイラプラグインがあって、言語仕様を好きなように
拡張できるんだから。

>>740
今回の議論に必要であり本質を突いているのは、最初の一行だけで
後はすべて揚げ足取りですね
そして、その本質である最初の一行であっさりとScala以上の方法が
ありうることを認めてしまってるな

>>741
マクロは言語仕様であって、コンパイラプラグインは言語仕様ではない
そして、今は言語仕様の話をしている

そりゃScalaは何でもできる言語じゃないよ
とりあえずevalができないじゃない
でもそういうのはトレードオフだからね
この人はいったい何が不満なんだろ
とりあえずClojureでも使えばいいんじゃないだろうか

別にScala以上の機能を持った言語を探してくる必要もないなあ
高機能だとか低機能だとかってのは継ぎ接ぎだらけであるかどうか
という点とはまた違った観点でしかないのだから

>>742
Scala以上の方法がありうることは最初から否定してないが？
マクロが万能かのような物言いをするから、そうじゃない例を挙げただけだ。

>>743
「今の話の文脈で」、言語仕様かどうかにどんだけ意味があるよ？大体、ScalaはいまんとこEPFLによる
実装しか存在しないんだから、実質、Scalaではコンパイラプラグインが使えると言っても差し支えない。
もちろん、一般論として言語仕様か独自拡張か区別することは重要だけど、少なくとも今の議論では
どうでもいいことだ。「Scalaではコンパイラプラグインさえ使えばどんな機能でも使える上に〜」とか
言ってたら滑稽だろ？Schemeでマクロがうんたら言うのはそれと同レベルだってことだ。

>>746
こちらこそ、マクロが万能であるとは一言も言ってないが？
ただ、Scala以上の機能がいくらでも実現できることは確かだ
だからこそ、比較によって「感覚的に」継ぎはぎだらけだと思えるだろうに
と言いたいんだよ

>>746
今の文脈はどうみても「言語仕様が」継ぎ接ぎだらけだという文脈だろ
意味があるかどうかはまったく別の観点だ
だが、あえて別の観点であることを承知でいえば、言語仕様に
なっているものはコンパイラプラグイン以上に皆が共通で利用するのだから、
言語仕様のみに限って議論することに意味はあるだろう

>>747
Scala以上の機能をマクロ使ってうまく実装できる場合もあるが、そうでない場合もある。
試しに、とりあえずScalaと同じ静的型システムを持った言語をSchemeの「マクロだけで」実装することを
考えてみてくれ。無理でしょ？できても、その部分がScheme部分とは別言語になるだけで、新しい言語の
コンパイラを他の言語で一から書くのとと大して変わらん労力がかかってしまい、マクロである意味は無くなる。

>>749
だから、何でもかんでも全部そうだとは言ってない
君が認めるように「大部分は」うまく実装できる
それだけで事足りる話だ

他の動的な言語にマクロで何でもできると喧嘩ふっかけるならいいが
静的/動的の垣根を越えて比較するのは不毛なのではないか

>>750
いや、Scalaの仕様の複雑さの多くはその強力な静的型システムに起因してるから、そこがうまく
扱えるかどうかは重要。静的型システムがマクロでうまく取り扱えないので、それだけでもマクロで
カバーできない重要な領域があることになる。

また、静的だから違うといってごまかそうとする論理か
静的言語にScheme級のマクロがあったとしてもなんらおかしくはないんだけどな
マクロ以外の別の選択肢もありうるだろう

この板ってID出ないから誰が発言してるんだかわかりにくい。
名前欄に何か入れてよ。

>>752
だから、その強力な静的型システムを実現するために「複雑に」
なっていると認めているじゃん
Schemeはそれを実現していないから複雑でないんだろう
だったら、そこで話は終わりだ
Scalaは継ぎ接ぎだらけであると双方が結論を出した

>>753
いや、だって、発端の>>737が
＞Schemeを見ればScalaがいかに継ぎ接ぎだらけかということに気づかない？
＞マクロさえ使えばScala以上の機能がいくらでも使えるのにシンプルな言語仕様
みたいにSchemeと比較するんだから、しゃあない。マクロ以外の選択肢はそりゃあ
ありえると思うが、例も出さずに可能性だけの話しても意味無い。

静的型つきScheme
http://www.ccs.neu.edu/home/samth/typed-scheme/

>>756
だからといって、揚げ足取りみたいにSchemeより優位な点を挙げて
満足なのか？
元の文はどう見ても全体的な話をしているのに

>>755
複雑＝継ぎはぎだらけって意図ならそうだけど、そう取っていいわけ？
なら、話はそれで終わりだ。

>>759
どうやら結論が出たようだな

まあ、一応付け加えておくと、大体同じような意味ではある
多数の機能を実現するために、継ぎ目の見える複数のコンセプトを導入することを
継ぎ接ぎだらけと言っているから、言語仕様が複雑であるということと
ほとんど大差はない

マクロで彼女ができました

>>753
＞静的言語にScheme級のマクロがあったとしてもなんらおかしくはないんだけどな
おかしくないなら君が作りなさいよ

静的vs動的は古典的なネタだし、ここで繰り返しても意味ないと思うが
君の論法だと全ての静的な言語はマクロがないゆえに複雑な言語ってことになると思うが
Scalaに限定した話にしないと不毛って言ってるわけ

>>758
満足も何も、マクロさえ使えばScala以上の機能がいくらでも使えるっつうから、
そうでない例(静的型システム)出したわけだが？つまり、(Schemeの)マクロで
カバーできない(静的型付けという)重要な機能のためにScalaの言語仕様は
複雑になってるわけで、そこを抜きにしても

>>762
>>757

>>763
そのこと（マクロで実現が難しいことも存在するということ）と、Scala以上の機能がいくらでも使えるということは
なんら矛盾していないんだが？
しかも、その重要な機能のために複雑になっているんだろ？

途中で送信してしまった。
(続き) そこを抜きにして
＞マクロさえ使えばScala以上の機能がいくらでも使えるのに
と言っても、「Scala以上」が実現できてないじゃん、と言えるわけで。

>>764
その型つきSchemeを使って、Scalaと同等の機能を実現できるわけ？

>>766
単に、「Scala以上」の意味を誤解してるだけだな
Scalaのすべてを全部実現することではないからな

>>765
Scalaの静的型システムはScalaの重要な機能のうちの一つであって、しかもSchemeのマクロじゃ
実現が難しい例なわけだが？「Scala以上の機能がいくらでも使える」と聞くと、普通はマクロを使えば
Scalaの機能はすべて実現可能と取るでしょ。

>>767
できるかできないかでいえば、「できる」
困難かどうかでいえば、「困難」
そして、Scalaで実現できないことを実現できる

だから一般論として静的/動的の比較になっちゃ意味ないよ
今までの議論どおり、どっちも得意、不得意があるってことにしかならんのだから
同じ土俵で具体的にScalaの記述はここが冗長であるとか指摘できるならいいけど

>>769
別に取らないだろ
大体は実現できた上で、Scalaに実現できないことをいくらでも付け加えることができるのだし
そもそも、困難であって、できないわけではないだろ

>>771
同じ土俵で語ることが間違ってるな
土俵が間違ってるということも含めて議論しないと

>>773
土俵が間違ってるかどうかって、動的か静的かで結論出せってこと？
それこそ、このスレでやることじゃないよ

>>772
実用を度外視して、できるかどうかで言えばできるけど、それは、単に「SchemeでScalaの型チェッカを書ける」ってのと同レベル
の話であって、マクロを使うことによるメリットはほとんど無いと言っていい。仮にそのマクロを使って実現された埋め込み言語を
SScalaと名づけたとして、SScalaの中に任意のScheme式を埋め込むことはできないだろう(型付けしようが無いから)。
だから、実用的には「できない」と言ってしまっても差し支えない。一般的に言って、Schemeのような呼び出し形式のマクロは
型チェックとか、プログラムのグローバルな最適化とかみたいな横断的関心事扱うには全くもって向いてない。横断的関心事
扱うためのマクロシステムみたいな
のもあるにはあるが、それはSchemeとは別の話になるし。

>>774
結論出せとは言ってないけど、議論の一要素ではあるな
たとえば「動的言語にすれば継ぎ接ぎは少なくできるから
Scalaは継ぎ接ぎだらけで汚いんだ！」という主張はありうる
主張だろう
まあ、静的だとしてももっとほかに解があるという方向性の
主張もあるけどな
実際このスレでもPythonの作者がしているし、
静的Schemeみたいな同じ土俵の言語のURLが張られて
いるようだし

>>775
結局、君が言ってるのは、マクロでは静的型チェックの実現が困難だといってるに過ぎないだろ
静的型チェックを持つ言語がマクロを備えたら何の反論にもならないし、
実際そういう言語はもう存在している

>>733
お前ら、とりあえず落ち着いてこれでも食え

つ【Lua】

>>776
＞たとえば「動的言語にすれば継ぎ接ぎは少なくできるから
＞Scalaは継ぎ接ぎだらけで汚いんだ！」という主張はありうる
＞主張だろう

とりあえず、これのどこが「ありえる主張」なのかさっぱりわからんのだが

静的Schemeは、俺は使ったことない言語だから何も言えんが、
この中で誰か詳しい人いるの？　いないなら脇に置いておくべきだと思うが

>>777
いやだから、Schemeが比較対象になってるからそういう反論しただけであって、別の形の
反論までは否定してないよ。静的型チェックを持つ言語でかつマクロを持っている言語が
いくつかあることも知ってる。ただ、ひとつ言うなら、マクロを足したら言語仕様はその分
複雑になるわけで、君たちが言う「継ぎはぎ」の数はより多くなるんじゃないかな？

静的型を付け加えたSchemeは、言語仕様を議論するだけなら
想像して議論する価値があるだろうし、簡単にみんなが想像できるだろう
このことは、静的であること自体が言語仕様を複雑にしている大きな要因では
ないということも意味しているけど

>>780
その意味では継ぎ目はもちろん多くなるよ
でも、その多くなった継ぎ目で、別の継ぎ目がなくなるのであれば
総合的には継ぎはぎの数は少なくなるだろ

>>781
いや、だから型付きSchemeの仕様を具体的に知ってんのかと
それも知らんのに想像して議論する価値なんてないよｗ

>>783
型付きSchemeが複雑怪奇な仕様だとお前は思うわけ？
どうせ、わからないとか主張するんだろうけど
本音では思わないだろ？ｗ

>>781
静的型システムと言ってもピンキリで強力にしようとすればするほど
仕様が複雑になる(当たり前だけどね)。で、Scalaの型システムはかなり
強力で(高階の型すら扱える)、仕様が複雑になる大きな要因の一つになってる。
ちなみに、Haskellの型システムもかなり強力なので、やっぱりそれほど単純ではない
(Guidoはその辺知っててHaskellを推してるのかどうかは知らんが)。

>>784
いや、知らんよ
誰も知らん言語を想像で語る意味がないってだけ
どうせ頭の中でいいとこどりになるだけだろ

マクロなら何でもできる論もそうだが、可能性だけ想像して
Scalaの方が複雑と断言できる神経が理解できない

>>785
型システムに限らないことをいえば、強力であればあるほど複雑
になるというのは間違いだ
それこそ、Schemeを見ればわかる
そして、次に100歩譲って型システムに限れば、強力であればあるほど複雑になるとしても、
結局、強力であるがために継ぎ接ぎだらけであるという主張の反論にはなっていない
そして、さらに、型システム以外の点でも継ぎ接ぎだらけだ
たとえばGuidoは普通の括弧と中括弧の中でのセミコロンの挙動の違いをあげてるな

>>786
そんなに難しい話でもないだろ
ただ静的型チェックするだけだし

とりあえず、型付きSchemeのドキュメントざっと眺めてみた。レコード型や再帰型、多相型があって
SMLに割と近い感じがする。サブタイピングとか高階の型、型クラスなんかはなさげ。で、これを
土台にどう議論しろと？ScalaよりもHaskellよりも弱い表現力しかなくて、比較対象にできるものでは
無い感じだが。

サブタイピングとか高階の型、型クラスねえ
それこそ「マクロ」で簡単に同等なことを実現できそうだなw

pgr

これ以上、妄想言語と比較論やってもしょうがないわ
具体的にScalaと同等の機能を実現できるマクロを作ってから出直してくれ

>>792
その論理が間違いだといってるのに
じゃあ、Schemeと同等の機能を実現できないのに
Schemeより複雑怪奇なScalaは問題外ですな

>>787
＞型システムに限らないことをいえば、強力であればあるほど複雑
＞になるというのは間違いだ
＞それこそ、Schemeを見ればわかる
型システムの話をしてるんだが。で、型システムは一般に強力にしようとすればするほどどうしても
複雑になる。依存型とかでぐぐってみるとよろし。複雑だから強力とは限らないが、少なくとも強力な
型システムはある程度以上複雑だとは言える。

＞そして、次に100歩譲って型システムに限れば、強力であればあるほど複雑になるとしても、
＞結局、強力であるがために継ぎ接ぎだらけであるという主張の反論にはなっていない
いや、だから複雑＝継ぎはぎという主張なら反論はしないよ。

＞そして、さらに、型システム以外の点でも継ぎ接ぎだらけだ
＞たとえばGuidoは普通の括弧と中括弧の中でのセミコロンの挙動の違いをあげてるな
正直に言うと、シンタックスに限定して言えば、割と継ぎはぎが多いのは認めざるを得ない
(単に複雑という意味でなく、ad hocな挙動がいくつも見られる点で)。ただ、セマンティクスの話は
また別だ。Guidoが挙げてるのは静的型に対する見当違いの批判を除けば、ほぼシンタックス
の話なので、割とどうでもよい。

だからそういうのは静的/動的の一般論でしかないと
そっちがマクロがあればScalaの機能は実現できると主張してるわけだから
具体的にやってもらわんと

>>795
誰もそんなことは主張してないけど？
Scalaにない機能をいくらでも付け加えることができるとは言ってるが

>>790
じゃあ、やってみなされ。実際に型付きSchemeの処理系あるんだから、マクロ使ってそれをちょっと拡張するくらい
簡単なことでしょ？まあ、普通に考えていずれも型システム全体に影響する話だし、Schemeマクロだと無理だが。

>>796
じゃあ、それでいいんじゃない
Scalaでできないこともあるし、Schemeでしかできないこともある
それが一般論だって言ってるわけで
結局何が言いたいのかわからん

>>794
つまり、型システムに限定しても、反論ができない上に、
型システム以外ではフォローのしようすらないってこと？
何の意味があってそれを一生懸命言ってるのかわからないが
まあ、結論が出たならもういいか

>>797
わかった
そういう処理系があるなら、簡単にできそうだ
その点に関してはやってみてから結論を考えるよ

スレが進んでいると思ったら
能無しSchemerが暴れているだけか

>>796
ふーん。じゃあ、
Scheme: マクロでScalaに無い機能をいくらでも付け加えることができるが、静的型システムは実装できない
(型付きSchemeは方言(別言語)だし、マクロ使って書かれたとも書かれて無いから考慮しない)
Scala: マクロは無いが、標準で強力な静的型システムを持ってる
というわけで、単純には比較できないね。

>>798
そして、Schemeの方が言語仕様は小さい
そこから導かれる結論は、Scalaは継ぎ接ぎだらけである
ってことじゃないのか

>>799
継ぎはぎという言葉をちゃんと定義しないでテキトーに使うからでしょ？
複雑＝継ぎはぎなんて定義で話してるとは、思いもよらなかったよ。継ぎはぎというと
後から後からよく考えずに継ぎ足していくイメージがあるもんだからさ。

>>803
>>779もそうだけど、論理的な演繹ができないタイプの人間だね、君は

>>802
ドキュメントまで読んだそうだけど比較対象にしないの？
そのSchemeの言語仕様は複雑だったの？
比較すればいいじゃない

>>804
それほぼ同じだろ
後から後からよく考えずに継ぎ足していくから複雑になるんだし

>>803
わかっててやってるのかしらんが、>>798の
＞Scalaでできないこともあるし、Schemeでしかできないこともある
は
＞Scalaでしかできないこともあるし、Schemeでしかできないこともある
のtypoでしょ。

>>808
まことに申し訳ない
でもScalaでできないことがあるということがScalaの複雑性の証明にはならない
という意味では元の文でもある意味正しい

>>797
>普通に考えていずれも型システム全体に影響する話だし、Schemeマクロだと無理だが。

当然知ってると思うけど、CLOSやSOSを見てもそう思うの？

>>807
後から後からよく考えずに継ぎ足していくならば複雑になるが、
複雑ならば、後から後からよく考えずに継ぎ足していったとは限らない。
論理的に考えて当たり前のことでしょ？よく考えられているけど複雑という
事は往々にしてある。

>>806
型付きSchemeはSchemeとは別の言語だから、比較するなら仕切り直してからだろうと。
あくまで「Schemeっぽい」ってだけだし。

>>810
もちろん知ってるけど、あれらは静的型システムとは言えんでしょ？静的型チェック無いし。同列に扱えるとは
とても思えんが。

今日だけで100レスくらい伸びてるのは何なんだ。3行くらいでまとめてくれ。

>>811
そういう意味で言うなら、よく考えられているけど継ぎはぎだらけということも
往々にしてあるように思うのが普通だと思うんだが

>>812
でもマクロは動的なチェックと同様なお手軽さで静的なチェックができるでしょ？

>>813
Scala
継ぎはぎだらけ
主張

結局彼の言う「継ぎ接ぎ」というのが何なのかがわからんのが問題なんだよ
今の話はなぜか型システムの複雑性になってるし
Scalaという文字列をJavaに置換しても全く同じことが言える話ばっかで
複数のパラダイムを融合したゆえの複雑さの話になってない

>>704
暗黙の型変換をプログラマが勝手に組み込めるというのは継ぎはぎ感がありますね。
そもそも、静的型システムの目的と矛盾してると思います。
注意深く使うというなら動的に変更できる方が統一感があります。

また、参照透明性/副作用の点も
「varとval両方用意したから好きな方を使えるよ」
という安易な発想も継ぎはぎ感がありますね。

参照透明性/副作用の両方の利点を兼ね備えた
新たな仕組みを作るのではなく、「両方使えるよ」
というのは、実用的かもしれないけど美しくない。

全体にScalaの特徴は、いろんな機能を
「ただ、詰め込んだ」としか思えません。
しかも、それらの機能は他の言語で「便利」とわかっている機能。
「なるほど！」と思える興奮がない。

言語としての優劣ではなく、美しくないと思うだけです。

美しい言語使ってればいいんじゃん？

>>818
暗黙の型変換はそんなに継ぎはぎ感があるかねえ
ポリモーフィズムの一つとして、理解できる拡張なんじゃないかな
具体的な使われ方がJavaの型と合わせるためというのが多くてそう見えるかもしれないが

それに静的型システムと矛盾してるというほど強力じゃないよ
実際使えば、制約がきつくて動的言語ほど慎重になる必要なんてないということがわかると思う

val、varはまさにシンタックス上の問題という気がする
varだけなら継ぎはぎじゃなくなるのかとか

他の言語で便利だとわかっている機能を入れただけだというのは同意するが

ああ、すみません。
ここまで話をふっておいてなんですが、
私、Scalaの事、あまり詳しくありませんｗ

何かScala独自の機能があれば教えて下さい。
その機能がすばらしければ、好きになれるかもしれません。

val、varの件はまさしく、Guidoも言ってるHaskellの解決策が
良いっていいたいんだろうね

独自の機能ってのはあんまりないんじゃないの
新しいパラダイムを作る言語でないのは確か

詳しくないものを思い込みで批判するのはネガキャンっていうんじゃないの。

>>819
chinko

>>818
あなたの美意識に興味はないです。
あなたのレスは美しくないのでこれ以上読みたくないです

Scalaはこの数カ月くらいでにわかな人がけちをつける対象としてクローズアップされているかのようだな。

ライブラリ込みならJavaに依存しまくる現状が美しくないというのはその通りだと思うが
今新しい言語を作るとして、Scalaと同等の機能を持ちつつ、
Scalaより美しく作るってのは相当しんどいんじゃないかな
暗黙の型変換とかmutableなところとかを削っていくというならわかるが

っていうか、マクロの本当の意義は、

>>型チェックを網羅的にやろうとすると、関数定義や変数定義は全部独自のマクロで定義したものしか型付けできないみたいなことになって、本末転倒だから。

ここなんだけどな。

コンパイラへ情報を与えることによって、どんな言語にでも化けられるところ。

>>814
そういうことも往々にしてあるかもね。で、複雑⇒継ぎはぎだらけだと言いたいの？

>>815
Schemeマクロみたいな、明示的な呼び出しを必要とするマクロはそれだけでは型チェックみたいに
グローバルに作用するチェックは書けない。(typed (+ 1 1))みたいに明示的にラップ
しなくちゃいけなくて台無し。関数定義にしても、そのための専用マクロを用意しなくちゃ
いけない上に、型付けされた関数に普通のSchemeの値をそのまま渡すことはできない
だろうし…。結局、実用的にはマクロだけで作った静的型システムを使おうと思うと
面倒過ぎるのが容易に想像できる。実用性を考えなくて良いのなら、原理的には
もちろん可能だけどね。

>>818
個々の暗黙の型変換は継ぎはぎであったりなかったりとあるだろうけど、暗黙の型変換のユーザ定義
という機能自体は継ぎはぎ的には見えない。var/val両方用意したのは、まあ日和ってる感じはあるね。
でも、何かくっつけたわけではないし、どの辺が「継ぎはぎ」？(varが継ぎはぎということかな？)「ただ、詰め込んだ」か
どうかは個人的には異論があるが、まあここは個人の印象なので反論しても仕方ないか。

正直そろそろ他所でやってほしい

そうだね、プロテインだね

未踏Lisp作るほどLispは言語として
優秀だろ？なぜScalaなんて使うんだ？

いやそんな釣りはいらないんだけど

>>813
荒らす人
構う人
皆ヒマ人

痴話喧嘩は余所でやれ

いえ、同族嫌悪ですね

前にHaskellとawkで同じような論調なのを見たな。
もしかして改変ネタなのか。

○○は好きになれません。○○は美しくありません。Haskellなら○○です。
ちなみに○○は詳しくありません。だから○○のいいところを教えてください。
やはり美しいとは思えません。Haskellなら（ｒｙ

それはawkで受けて立った人が凄いｗ

「型システムなんてLispのマクロで」「いやマクロではできないでしょ」っていうやり取りもScalaスレで昔にもみたような。同じ人かな？

一人で自作自演してるかと思ったぜ

>>293-339
辺りだな。結局、マクロだと無理か困難ということで決着がついたっぽいけど(一応言っておくけど、
こっちの方の議論は俺は関わってないよ)。

ここでマクロがどうとか言ってるやつは絶対Scheme使ってないんだろうな

Scalaは継ぎはぎということで決着がついたみたいだな

Go＞＞＞＞Scala

>>846
コンパイルスピードの話か

継ぎ接ぎの無さではGoが上だな

まだ言ってるのか
これだけ無知を指摘されて恥ずかしくないのだろうか

>>849
コテンパンに論破されて悔しくないの？

Goは美しい
Scalaは糞だ

休みなのに熱いなぁ、お前等
気に入らなきゃ使わなきゃいいし、改善して欲しければ参加するか、要望出せばいいだけじゃね？

なんか、反論できないかわりにSchemeを攻撃し続けて
見当違いなごまかしをしようとしていた人がいたみたいだな

頭がおかしい奴は独自の語意や新語を何の断りも無しに使う法則が
今回も当たった。

そうだな、人には継ぎ接ぎという言葉の定義の説明を求めるくせに、
自分は最後まで明らかにしなかった人がいたね

>>854
まともな議論になっちゃ困るんだろうな
きっと多少は自覚があるんじゃね

まともな議論では継ぎ接ぎだと決着しちゃったからなあ
なんか独自の新語でごまかすしかないんだろうね

>>857
お前理解できない言葉があったのか
まあ、素直でいいことだ

>>858
本人だけはマトモな言葉だと思ってるから、まぁそういう反応になるよね。

752の言う継ぎはぎの意味は理解できなかったな
独自定義の新語だったからな

>>860
結局「継ぎはぎ」という言葉をあいまいにすることで
詭弁をこねくりまわしてただけだからな
よくこれで半日も粘着しようと思うわ
あまり知識はないけどプログラマっぽいことは言いたいって感じなんだろうな

このスレでNetBeansがいいってレスあったから入れてみたけど、いい所一つもない

継ぎはぎだらけって言うのはね、服のほころびたところなどに
布を当てて繕うことをいうんだよ
つまり、一つの生地で整った服を作っているんじゃなくて、
たくさんの生地・布を使って、足りない部分を補いつつ一つの
服を作り上げてるような様を言うんだよ

オブジェクト指向っぽい機能が足りないからクラスをくっつけよう、
イミュータブルな変数もミュータブルな変数も使いたいから
varとvalをくっつけよう、簡単に書けるようにしたいから〜〜をくっつけよう
型システムが〜〜
こういうのを継ぎ接ぎだらけという

>862
Eclipseだと編集すらままならない状態になる事無い？
一回閉じて開き直せば直るけど。

eclipseだと自動整形機能がない

EclipseもNetBeansも欠点ありそうなのだが、何がScala編集の決定版なのかね

>>863
後段が前段の例になってないと思う。
後段で言ってるのは、現在の素材だけでは成し得ない機能を、別の素材を使うことで
実装することについてでしょ？
それだと、「服の前を留めたいからボタンをくっつけよう」なんてのも継ぎ接ぎの一種になるよ。

もうかまうな。

>>866
scala-mode

>>867
ものの例えに例外があるのは常だけど、
その例でいくと、ボタンがないのに前が開いた服を作ること
自体ちょっと考えづらい

>>867
継ぎ接ぎをするということは、現在の素材でなしえない機能を、別の素材を使うことで
実装することでもあるでしょ

>>869
scala-modeはflymakeがfscでも遅すぎて使えないという問題が

>>870
この場合は、前が開く服を作りたいからボタンを導入しよう、みたいな形になるかと。

>>873
それも継ぎ接ぎの例だろうね
普通は生地に対して使うから、継ぎ接ぎとは言わないだけで
概念としては同じものだろうね

>>866
Intellij

Intellijって最近オープンソース化されたんだっけ
使ってみようかな

EclipseはNetBeansに比べて継ぎはぎだらけ

Eclipse最近ダメダメだな
一時はすごい人気だったのにどうしてこうなった

日本人技術者は、中韓に比べて
技術スキルが継ぎはぎだらけ

今Eclipse衰えてるの？

>>880
Eclipseは開発資金枯渇してきて
コミュニティ崩壊しそう

Eclipseって無いよりマシだけど、ゴジャゴジャしすぎなんだよな。
Visual Studioと比べると洗練されていないというか。
使いなれていないのかも知れんが。。

>>882
有償のVisual Studioと比べたら駄目だろ。あれは別格だよ。

Eclipseの方がVSよりマシだろ

長かった。やっと読み終えたよ。次回からは名前付けるなりしてもらえると追いやすくて助かる。
で、読んでて気になったのが一点。
>>823
>独自の機能ってのはあんまりないんじゃないの
implicit conversionはScala独自で相当すごい機能だと認識してた。
これがあるからScalaはExpression Problemが解決できる訳だし、
実際例えばRichStringとかには知らずのうちに結構お世話になってるはず。
implicit conversionって意外と評価されていないのかしら。

それ関数や演算子の多重定義があればさほどいらなくない？

Javaに依存してなきゃ最初からRichStringなんてものはいらんわけで、
なかなかその辺は褒めづらい

RichStringはimplicit conversionを使ってない訳だが

例を挙げるならBigDecimalとか

そんな馬鹿な、と思って2.8のソース見てみたら、
LowPriorityImplicits.scalaでWrappedStringってのに変換されてた、なにこれ
もう2.8のコードやだ、読みづらすぎだろ

>>886
implicit conversionは、既存のクラスに後からメソッドをくっつける手段(いわゆるオープンクラス)の
一種だから、演算子の多重定義とかとは無関係だよ。

>>887
Javaに依存してなくても、既存の手を入れられないクラスに後からメソッドくっつけたいという
需要は存在するわけで、Javaに依存してるせいとも言い切れない。たとえば、Scalaの標準
ライブラリには自分で手を加えられないので、Scalaのコレクションにimplicit conversionで
メソッド足して使ったりする。

あ、Scalaの標準ライブラリには手を入れられないってのは、Scalaの単なるユーザにとって、という
話ね。Scalaの開発者にとっては手をいれられない存在がJavaのクラスになるだけで問題は
同じってのが言いたかったこと。

implicit conversionで実現した機能って、やっぱboxingみたいに重いんだよね？
それとも、特殊な最適化が掛かってたりする？

Scala遅くて使い物にならない
Javaですら遅いのに

いまどき、Javaより速い言語って限られると思うが

reverse-complement benchmark | Ubuntu :
Intel? Q6600? quad-core Computer Language Benchmarks Game
ttp://shootout.alioth.debian.org/u32q/benchmark.php?test=revcomp&lang=all

ScalaやJavaより早い言語なんていくらでも・・・

>>893
私は「boxingみたい」ってのがよく分かってないんだけど、
implicit conversionは、型の変換が必要なときにその型変換にマッチするimplicit defで
定義された関数を一つ挿入する（コンパイル時に）だけなので、
特別重くなることを心配することはないと思う
そもそも暗黙的じゃきゃ自前で書かなきゃコンパイル通らないだけだし、それを自動でやってくれている

>>896
GCCのC, C++, Ada, Free Pascal, ATSだけじゃん

Javaは実行速度云々以前に起動が遅いからヤダ

>>898
機械語やアセンブリ言語も一応言語じゃね？ｗ

>>900
お前が書いても遅いだけだけどなw

>>897
暗黙の型変換によるメソッド呼び出しのたびに、インスタンス生成するって事について、いっているんだと思う。

scala で DI コンテナの使用例ってないのかな？
Java で DI コンテナ使うのに慣れちゃったから、scala でも使いたいけどいまいちパターンがつかめない。
Java と同じように使うってのも、どうも scala の良さを生かせてない気がしてねぇ・・・

2.8っていつ頃出るのですか？
期限は過ぎているように思うのですが。

>>904
まあ、遅れてるけど、2.8.0 beta RC2という謎のリリース番号のが出てきてる辺り、
betaバージョンが公開されるのはもうそろそろという気がする。正式リリースは…
今の調子だとあと半年くらいしないと出ないんじゃないか？

Intelij IDEAは、コミュニティ版が日本語化されないと手が出しにくいなー
どこかで日本語化パッチとか提供されてたりしない？
ちょっと探しただけじゃ見つかんなかったんだけど。

>>906
そうか？英語でも使っているうちに慣れると思うが・・・

コミュニティ版はRubyとか色々と使えないのか。
Maven使ってLiftプロジェクト作れる？

Scalaをアンストした
世話になったな
さがさないでくれよ

つ 三くだり半

>>908
Liftはためしていないけど、Maven つかった Scala プロジェクトは動いた。
多少設定がいるかもしれんけど、Eclipse で Scala やるよりかは快適。

>>905

ありがとうございます。
当初予定からだいぶ遅れているのですね。
なんか問題有ったんでしょうか？
2.8で結構仕様が変わるという噂を聞いていたので2.8リリースされてから勉強しようと考えていました。
取り敢えずは日本語訳の本が出たので2.7.7で勉強を開始しようと思います。

補完ならIntelliJが一番良さそうだが、まだベータ版なのがちょっとなあ。

>>913
いまのところ、IntelliJ が一番よいのは同意だけど、import 文の自動挿入と整形がいまいちなのが残念。

いつの間にかIntelliJ9の最終リリース版が出てるのか。

simple-build-toolって便利？

maven より手軽らしいよ。

Scalaのビルドツールって何がメジャーなの？
やっぱりmaven？それともIvyに移行したりしてんの？

>>916
Liftもmavenベースからsbtベースに移行しようという意見も出てるらしい
使い勝手という意味では、pure scalaのアプリ作るならmavenより便利だと思う

IntelliJを使ってみたんだがscala.swingパッケージなんかねえ、と言われてしまう。
scala 2.7.7, IntelliJ 9, scala-plugin 0.3.312 でそれぞれ最新のはずなんだが。
ほかに設定があるのかな

>>920
IntelliJは商用版じゃないと動かない
公式が認めてるから諦めろ

>>920
scala.swingはjarファイルが別になってるからたぶんそのせい(IntelliJのデフォルトの
設定では、scala-library.jarしかクラスパス通って無いはず)。scala-swing.jarを
クラスパスに追加すれば動くはず
>>921
何の話かわからんが、オープンソース版でちゃんとscala plugin動くよ。

IntelliJってScala2.7.7使えないの？
直接ライブラリー選択すれば動きそうではあるけど。

>>922
確かにswingのjarにパスが通ってなかっただけみたいでした。
2.7.7のjarを指定しても問題なく動いてます。
ありがとうございます

今日ダウンロードしたんですけど遅いですね・・・
がっかりしました。

遅いって何が？

ダウンロード速度が

すいません
16進数のm56cc82を10進数に直してもらえませんか？

やっとくから、元旦になったらこのスレ見て！

>>929
ありがとうございます。
でも何か悲しいです

mってなんやねん。

minus

Liftの情報少ないな。
基本的に公式のwiki見れば足りるの？

NetBeans6.8がリリースされましたけど、ScalaプラグインはRC1版のものだと
動かないですね...

IDEはどれも今一だな。
もうsbtでいいよ。

>>933
ttp://groups.google.com/group/the-lift-book?pli=1
こんなのもありんす
売ってる本は色々と抜けていて完成度低いらしい、pdfを落としてくると幸せになれるかも

>>936
ありがとう。参考にします。

しかし、売ってる本の完成度が低いってのはどうなんだろうｗ

>>937
文句言いまくれば品質上がるよ？
英語で言えばの話だけど

日本と違って、文句言って素直に聞けない著者は
技術本書く人間として屑というのが常識だから

日本人はやり合って質を高めるというのが苦手だからね。
文句の質も屑。
ノータッチか罵倒かのどっちかになっちゃう。

この掲示板のこと？

Liftアプリは、本読んだ上でMLのログをそれっぽいキーワードで検索すれば
組めると思う。ソースも時々読む必要があるかな？

本体＋サンプルアプリのソースをgrepしても使用例の出てこない関数も
たまにあるね。

ScalaでHaskellのように中置演算子を定義することは可能ですか？
例えば($)のような演算子を作りたいのです。
f $ g $ x

Haskell のようなってのが、関数って意味なら難しい。
中置演算子として使えるメンバメソッドなら、1引数であれば良いだけ。

>>934
そうなのか。暫く6.7使うしかないかな。
IntelliJでもいいけど、CEだと機能的に十分なんだろうか。

>>943 ありがとうございます。つまりHaskellの($)演算子を作るには
class Fun[A,B](f: A=>B) { def $ (x:A) = f x }
のようなクラスを作る必要があるのですね。

>>938
そういう意味じゃないはずだよ・・・
買った人じゃないよな？

同じ本のドラフトが>>936で、
こっちの草稿では、付録や索引がついてたのに
印刷物では、抜けているという・・・・
あとは、プリンターの問題か文字化けしてる記号があったりもする。

この本は、タイトルやページ数が変わってるのに、出版社のページがそのままだったり、
2冊別々に表示されてたり、値段がクロスしてたり、いろいろあったから、
その影響で、出版社の校正素通りか、間引きされて印刷されちゃったのかもしれないね。

Creative Commons Attribution-No Derivative Works 3.0 Unported License
ttp://creativecommons.org/licenses/by-nd/3.0/deed.ja
.草稿じゃなかった。あと、営利配布もOKなのか

Programming Scalaの方は、非営利のみになってるね。
ttp://programming-scala.labs.oreilly.com/
Creative Commons Attribution-Noncommercial
ttp://creativecommons.org/licenses/by-nc/3.0/deed.ja

IntelliJでLiftのプロジェクト作るとboot.scalaで
「Cannot resolve symbol ::」が出る。何で？

最近は Eclipse プラグインって少しはまともになったのかな？

俺も今ちょうどそれを聞きたかった。

ついでにおれも

じゃあ、俺も耳を貸してやるよ

じゃあ俺も俺も・・・って、誰も使ってないのかよっ(w

全然アップデートしてないんじゃないか？
素直にemacs使ってろ

>>949
元がどうだったか知らないけど最近使ってるよ
.scalaファイルを読み込む（エディタに表示する）ときに
謎なエラーダイアログがポップアップしてくる事多数
それ以外は特に困らない
リアルタイムにコンパイルエラーを教えてくれるのは助かるし、
メソッド名の候補が出てくるのも嬉しい
ちなみにVista+eclipse 3.5+plugin最新版

>>948
自己レスだが・・・、Lift 1.1-M8で作ったら
エラーが出なくなったからまあ良しとする。

>>956
と思ったが駄目でした・・・

そんなオチで客が喜ぶとでも思ってるのか！
入場料返せ！

ワロタｗ

おまえら、何でコード書いてるの？
EmacsかVimなの？

とりあえずvim。ビルドはAnt
IntelliJは試してみて、割と使えそうだなと思ってたけどIntelliJの操作に慣れてないので
常用するのはしばらく先になりそう

ためしにIntelliJを使ってみてるが、::がエディタ上でエラー表示になることあるな。
コンパイルは普通に通るので問題ないけど。

ちょっと使った感じだと、NetBeansとくらべてリアルタイムでのエラー表示機能が弱いような

>>961
IntelliJのScalaプラグイン、新しいバージョン出てたから
更新してみたんだけど、その不具合解消されてるっぽい。

Eclipseのプラグインはエラーメッセージ吐きすぎて使えない
NetBeansはあまり補完が働いてくれない気がする
IntelliJはどうなん？

関数型言語を学ぼうと思ってて、haskellとscalaのどちらかじっくりやろうと思ってます。
そこで知りたいんだけど、scalaはどのくらい”関数型言語”よりなんですかね？
scalaをある程度使えるようになったとして、それはすなわち関数型言語を理解出来てること
になるのか、ってところが知りたい。
scalaの方が日本語の情報多そうなんで出来れば使いたいんですけど•••
関数型ってのがあまり分かっていないので変な質問しか出来ないんだけど、
回答してくれるとありがたいです。

>>964
Scalaは関数型でない方法でも書けるから、使えるからと言って関数型を理解したことになるかは微妙
あとHaskellのほうが日本語の情報が多いと思う

関数型言語を学びたいならHaskellの方だろ

>>964
Scalaは関数型言語じゃない。やめとけ。

万能を目指したがどれも半端だった。

Scalaに関数型言語として足りない機能はなによ

>>969
これだから低能は

>>970
プログラム板ってこういうところが嫌だな
まともなプログラミングの話ができない
2chにそういうのを期待しちゃ駄目なのかしら

>>970
これだから博士様は・・

最近のScalaスレだけの傾向じゃないかな。

>>971
うまく共存することを考えなさい

>>967
関数型言語じゃないってのならとりあえずその根拠くらい述べようぜ

>>967
博士様、教えて下さいませ

>>974
そういう小学生みたいな糞レスはいいから、Scalaに関数型言語として足りない機能を書きなよ。

>>965
>>966
haskellのほうがより”関数型言語”であることは知っていましたが、
正直なんか難しそうで(モナドがどうとか)、そういう意味でも
scalaでも関数型言語が学べるのならそっちにしようと思っていたんですが•••
RealWorldHaskellを買うかな•••
学びやすさの点でいったらどちらが上ですか？
ちなみにc言語とobjective-cの経験があります。

264じゃなくて964だった。

>>978
３Ｐの経験は？？

¿¿

>>978
学ぶならそのパラダイムしか使えない言語のほうがいいと思うよ
HakellよりOCaml系のほうが簡単かもしれない
でも日本ではHaskellのほうが人気があって、情報が多いんだよな
やっぱり関数型ならHaskellが一番かと

「関数型言語の勉強」が目的なら、Schemeが一番だと思うが。

関数型言語つってるのにLisp系勧めるのは詐欺だろ

clojureはLispっぽい関数型、
それとも関数型っぽいLispか

Haskellのモナドで四苦八苦するのが、「関数型言語の勉強」として
正しい姿なのかどうかは疑問だが。

ノマドで四苦八苦するか、Thunkで七転八倒するか
人生それぞれ

モナド＊

C#みたいに中途半端においしいとこだけもらうのがベストってことだな

C#はラムダ式を関数型のように使わせない工夫をしてる節がある。
関数型から直接借用したというより、RubyやPythonのような動的言語から借りてきた。

>>982
amazonでRealWorldHaskellを注文したんで、
とりあえずhaskellをやろうと思います。

>>986
調べてみた限り、モナドというのは関数型言語に必要な概念というよりは
”純粋である”ことを実現するために導入した概念みたいですね。
関数型言語を学びたいのであって、その”純粋である”ことにこだわっている
わけではないので、言語としてはOCamlの方がいい気がするんですけどね。
982さんのいうように情報がかなり少ないっぽい•••
モナドで挫折するまでは、haskellでいこうと思う。

Scalaがダメ言語に思えてきた➘➘➘

>>991
> 関数型言語を学びたいのであって、その”純粋である”ことにこだわっている
> わけではないので、

Schemeが目的に合ってるな。Haskell, OCamlでもいいと思うけれども。
たとえそう割りきってもScalaは目的に合ってない。

哲学的な議論はおいといてもScalaはいろいろに書けるから、
関数型的な使い方までたどり着かない。

演習問題じゃなく、すぐに実用アプリを作れないと学習意欲を維持できないって人には、
豊富なJava用ライブラリを呼び出せるScalaが有利かと。

それこそjavaっぽいアプリ作って完結しそう

つーか Scala って Java っぽいアプリをサクサク作ろうって趣旨じゃねーの？

ちょっと次スレ立ててくる

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