プログラミング言語 Scala

プログラミング言語 S ..

415:デフォルトの名無しさん
08/08/21 09:21:03
Renewal ですな
NetBeans 用プラグインも追加されてる > ヘルプも含めて IDE 本体のオール
日本語化は NetBeans の方がダンゼン速いので日本人にとっては良い知ら
せか
ただし 6.5 以上だけど (現在日本語はまだ GUI のみか日本語開発版のみ)

416:デフォルトの名無しさん
08/08/22 02:27:02
Scala本5月には出版っていってたのにまだプレプリントか。

417:デフォルトの名無しさん
08/08/22 14:10:17
Scala本待てない人は、単なる個条的抜き書き程度のしろものですが
それまではこちらをどーぞ
URLﾘﾝｸ(www.h7.dion.ne.jp)

418:デフォルトの名無しさん
08/08/22 15:00:49
うはｗ　こういうのうれしい。
英語のリファレンス読むのメンドくさくて、いまいちちゃんと理解できてなかったんで、
すげーうれしい。

419:デフォルトの名無しさん
08/08/22 21:31:43
>>417
これ、ただの機械翻訳じゃないの？

420:デフォルトの名無しさん
08/08/22 21:51:13
>>416
URLﾘﾝｸ(www.artima.com)
そろそろ出るんじゃないの？

421:デフォルトの名無しさん
08/08/22 21:51:42
機械翻訳はこういう文章を吐かないと思う
なんていうか、プログラマというよりは人文系の方が書いたような文章

422:417
08/08/22 23:32:47
プログラマ向け、でなくJavaとJavaScriptならわかる、という人を想定したら
こんな文章に。
Scalaは、そんな人たちの(関数型言語)入門学習用に向く言語仕様である
ように思われたので。
(つーか私自身にとっても最新の関数型言語の入門学習目的で言語仕様
原文から外せない部分を抜き出す形でまとめました(直訳はおろか意訳で
すらねぃです、でも原文読む参考程度にはなるはず)。ちなみにコンカレント
云々はまだわからない程度のレベルな私)

423:417
08/08/22 23:37:07
あーあといちばん最初に訳した言語仕様要約は直すべき部分が最多ですが
今はいろいろあって直すヒマがないのであしからず(私自身によるコメント部分
に集中してるので、そこの変なのは無視してくだされ。要約でない解説諸ペー
ジの方のが正しいです)。

424:デフォルトの名無しさん
08/08/22 23:42:12
＞If you purchase just the PDF eBook for $27.50, you will be entitled to receive periodic updates as the authors
＞complete the book, as well as the final PDF when the book is finished, for no additional charge. If you purchase PDF
＞+ Paper Book combo for $59.99, you will be entitled to the PDF eBook updates, and we'll ship you the paper book
＞when it is published, on or around August 30, 2008. (Once the book has been printed, you'll be able to purchase just
＞the paper book here for $49.99.)

すいません。これ訳してください。

425:デフォルトの名無しさん
08/08/22 23:55:28
こんな感じか？

$27.50でPDF買ったら、本が完成するまで
追加料金なしでPDFのアップデート受けられるよ。
$59.99でPDFと紙の本買ったら、PDFのアップデートできるし、
10月30日くらいに出版されたら紙の本も送るよ。
出版後は$49.99で紙の本買えるよ。

426:デフォルトの名無しさん
08/08/22 23:57:21
August 30
8月30日、ですね

427:デフォルトの名無しさん
08/08/23 00:05:59
>>425-426
ありがとうございます！
もうすぐ発売日じゃないですか！

428:デフォルトの名無しさん
08/08/23 15:41:22
>>417
ひさびさに電波ぽい文章を見た

429:デフォルトの名無しさん
08/08/23 16:48:38
>>428
だなｗ

頑張ってくれたのに悪いが、行間びっちりな上にろくに段落を区切ってないから、
文章ではなくなんかの模様に見えてしまう。そんなだから最初の一文すら読む気が起きない。

430:デフォルトの名無しさん
08/08/23 17:34:52
>417
むむむ……典型的な『頭の良い人が書いた難しい文章』だな。
・文が長すぎ／意味詰め込みすぎ
・読者に必要な前提知識が多過ぎ
・話が発散しすぎ
ということでおいらもムリ。

自分も素人なんであんまり偉そうなことは言えないけど、
・一文の意味／意図が一つになるように文を解体する。
　- ()の解説は多用しない。注釈で飛ばした方が良い。
　- 直前の文までに出てきた言葉だけで文章を組む。新規の言葉は解説する。
・段落の基本構造（序破急）を意識して文章を構築する
・文章の基本構造（起承転結）を意識して段落や章を構成する
あたりだけでも注意すればずいぶん違うんじゃない？

431:417
08/08/23 20:41:20
いちばん最初のページの水平線から下は「言語哲学的意味論」なのでいわゆる
リファレンスとしては読む必要はまったくないです (つまり、この水平線は、ここから
下は「Scalaという言語に対する(個人的)注解」である、という意味です)
水平線から上の部分にザッと目を通したあとはそのまま「1階受付」へとお進みく
ださい (そこからはいくらかでもマシになってるかと)

432:417
08/08/23 20:47:00
あと行間は、私は逆に空いてると読みづらい方なので、直すかどうかは微妙です
Firefoxなら「スタイルシートを利用しない」すればほんの少しだけ行間が空いて字
ももう少しだけ大きくなるよーですが ...

433:デフォルトの名無しさん
08/08/23 21:11:55
行間以前の問題だろ＞読みづらさ

434:デフォルトの名無しさん
08/08/23 21:27:38
>>417
論文ではなく、仕様書を書くようになればみんなの気持ちが分かるようになるよ。

435:デフォルトの名無しさん
08/08/23 21:47:37
>>430
頭がよいのとおかしいのと狭間くらいだと思う

436:デフォルトの名無しさん
08/08/23 21:59:18
これで難しいって、どれだけ土方なんだよ。

スタイルシートは変更したけど。

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

ぬか喜びさせてしまって申し訳なひ、おのおの方

438:デフォルトの名無しさん
08/08/24 00:56:07
スタイルは俺も無効にしたｗ
これぐらい特殊な文体でもいいんじゃないかな。もちろんわかりやすいほうがいいが、
クセがあって読みにくいぐらいの文章でも、Scalaの雰囲気としてはあってるような気がする。

439:デフォルトの名無しさん
08/08/24 06:34:46
>>430
序破急! うーーーーん。

440:デフォルトの名無しさん
08/08/24 10:14:48
序破急 > 導入・展開・参考
起承転結 > 理由・これまでの過程・話者の新しい意見・新旧の比較

とゆーことではないかな?
ちなみに序破急は能の作劇論、起承転結は漢詩の構成論が由来

441:not 439
08/08/24 10:33:48
技術文書の段落に序破急はおかしいだろw
>>440の頓珍漢さに苦笑

442:430
08/08/24 12:35:13
>441
じゃあ導入->展開->結びで良いや。
さすがに段落ごとに全部この構成にするのはムリがあるけど、意識しないで
破綻するよりはマシですな。

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

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

ちなみに、序破急は能じゃなくて雅楽から来た言葉らしいよ(Wikipedia)

443:デフォルトの名無しさん
08/08/24 13:25:36
>>434
それは論文に対して失礼だw
>>417には悪いが、少なくとも、コンピュータサイエンス系の論文で>>417くらい読みづらい
文章は見た覚えがないよ

444:デフォルトの名無しさん
08/08/24 13:34:09
417のサイトは他のページの方が電波ゆんゆんでいい感じだ

445:デフォルトの名無しさん
08/08/24 15:15:12
Programming in Scalaって本当に8月30日くらいに発売されるの？
アマゾンとかに全然来てないんだけど・・・

446:デフォルトの名無しさん
08/08/24 15:47:49
417は括弧部分をごっそり削ると、ちょっとだけ読みやすくなるぞ。
ちょっとだけ、だけどな。

447:デフォルトの名無しさん
08/08/24 22:04:48
Amazonとかの普通の流通に乗るのかなあって気も。

448:デフォルトの名無しさん
08/08/25 00:06:02
え！？そんな立ち位置なの・・・
Scalaのサイトでしか発売されないのかなあ・・・

449:デフォルトの名無しさん
08/08/25 19:44:46
>>417とか人によませるブログとか一度書いてみた方がいいと思うよ

450:デフォルトの名無しさん
08/08/25 21:29:39
ところでProgramming in Scalaってどんな内容なの？
ＰＤＦ読んだ人いますか？

451:デフォルトの名無しさん
08/08/25 22:45:57
pdf読める携帯買ったんで突っ込んでみたが、読みにくくて読んでないな

452:デフォルトの名無しさん
08/08/26 08:18:39
>>450
> どんな内容なの？

読め

453:デフォルトの名無しさん
08/09/02 12:51:20
Programming in Scalaって結局出版されたんですか？

454:デフォルトの名無しさん
08/09/02 14:36:35
日曜に本屋で見た。

455:デフォルトの名無しさん
08/09/02 21:47:42
マジで？
日本の本屋？

456:
08/09/02 22:14:25
うそだろ。ホームページ見たら
when it is published, on or around September 30, 2008.
ってなってた。また延期です。

457:デフォルトの名無しさん
08/09/07 10:06:41
この言語、groovy, jython, jrubyなどに対する利点は？

458:デフォルトの名無しさん
08/09/07 11:10:24
>>457
一つは速度

459:デフォルトの名無しさん
08/09/07 12:02:40
おお、それは凄い！
残りの二つ目以下２６項目も挙げてくだされ。

460:デフォルトの名無しさん
08/09/07 12:04:16
jython > 本家にかなり遅れている
jruby > 元来 Rails と Java の共用が目的で、それ以外にあえて使う理由がない
groovy > Java 版 Rails のための言語だが失敗。Rails 利用者は Java を要せず、
Java 利用者は Rails を要せず
scala > 関数型パラダイムを Java に持ち込むための言語で、上 3 つとの類似は
あくまでその結果 (Python と Ruby が関数型パラダイムの影響を非常に
強く受けているため)
つーわけで利点云々以前に、もともとの存在理由がまったく異なります

461:デフォルトの名無しさん
08/09/07 12:40:59
え
その逃げはないっしょ

462:デフォルトの名無しさん
08/09/07 12:52:26
都合の悪い展開になったから逃げ呼ばわりするという逃げは
どうかと思います。

463:デフォルトの名無しさん
08/09/07 13:04:26
は？俺に都合のいい展開って何？各言語信者の醜い貶しあい？

464:デフォルトの名無しさん
08/09/07 14:11:14
結局Scalaのアドバンテージは特に無い、という展開。

465:デフォルトの名無しさん
08/09/07 14:45:10
Scalaの利点ねえ。
あえて挙げるならきちんとした型システムがあるとことかかな。

466:デフォルトの名無しさん
08/09/07 15:21:49
>>464
Javaで書くより100倍楽だけど、性能はJavaと同等。
でもEclipseのScalaプラグインはもうちょっとがんばって欲しい。
今だとまだEmacsのscala-modeの方が使い易い。

467:デフォルトの名無しさん
08/09/08 11:36:23
メッセージ駆動並行なコード書くのに
JMSとJMXでMDBと、ScalaのActorどっちが楽？

俺は断然Actor派

468:デフォルトの名無しさん
08/09/08 22:20:42
Erlang派

469:デフォルトの名無しさん
08/09/13 08:13:33
プログラミングしりとり
ｽﾚﾘﾝｸ(575板)l50

470:デフォルトの名無しさん
08/09/13 16:16:58
Computer Language Benchmarks Game
URLﾘﾝｸ(shootout.alioth.debian.org)

Javaは何だかんだで早いよなぁ。
やっぱり俺の本命はErlangじゃなくてScalaだ。
次世代ゲーム機もScalaWithJavaAPIでいいと思う。

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

終了。
　

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

終了。

473:デフォルトの名無しさん
08/09/13 17:26:50
誤爆しかも連投ごめんなさい。

474:デフォルトの名無しさん
08/10/03 21:43:26
C99なんてもう誰も知らんぞ・・・

475:デフォルトの名無しさん
08/10/03 22:22:20
今度こそProgramming in Scalaって出版されましたか？

476:デフォルトの名無しさん
08/10/05 01:00:30
いいえ

477:デフォルトの名無しさん
08/10/05 14:34:55
10月30日以降にまた延期でっす!!

478:デフォルトの名無しさん
08/10/05 19:18:20
またかよ！
完成してから発売日発表しろよ！！

479:デフォルトの名無しさん
08/10/05 19:24:51
>>478
商売の基本は、発売前にマーケティング開始することだからなあ・・・
売れないのがわかったら出ないもんだし

ぁゃしぃebookだってそうだろ？
最初にまず、市場調査→セールス文を書く→マーケティングをしかける→商品作る→売れそうなら発売
が基本ってしってた？

480:デフォルトの名無しさん
08/10/05 19:25:23
> 商売の基本は、発売前にマーケティング開始することだからなあ・・
商売の基本は、商品完成前、発売前にマーケティング開始することだからなあ・・

481:デフォルトの名無しさん
08/10/06 00:30:08
執筆はどの時点で終わってるの？

482:デフォルトの名無しさん
08/10/11 01:14:30
ScalaByExampleのサンプルで動かなかったので質問
9.3章の最後
val intSort = msort((x: Int, y: Int) => x < y)
val reverseSort = msort((x: Int, y: Int) => x > y)
最後に'_'がない

10.3章
for { i <range(1, n)
　　　j <range(1, i)
　　　if isPrime(i+j)
} yield {i, j}
List.range()になってない
最後が(i,j)じゃない
これってサンプルのミスってことでいいの？

483:デフォルトの名無しさん
08/10/11 19:31:52
昔のバージョンではメソッドから関数への変換は _ つけてなかったし、タプルリテラルも中括弧だった（不評のためすぐに小括弧になった）。rangeは覚えてないけどそうだったんだろうね。

484:デフォルトの名無しさん
08/10/11 19:42:07
rangeは単にミスか省略か前提があるのかも。

485:デフォルトの名無しさん
08/10/11 22:59:16
ただのミスでしょう。ScalaLanguageSpecificationやScalaByExampleには新版ではエラーに
なる旧版のままの例のほかにもひと目でわかるタイプミスもときどきあります

486:デフォルトの名無しさん
08/10/12 00:07:59
解答サンクス
仕様変更にリファレンスが追いついてない状態なのね
本の出版が遅れるのも納得だわ

487:デフォルトの名無しさん
08/10/12 12:48:50
見つけたScala Language SpecificationやScala By Exampleのミスは、
MLで報告してあげると良いかも。英語で質問するのは敷居高いと思うかも
しれんが、適当な英語でもそれなりに意味を汲み取ってくれるので、大丈夫

488:デフォルトの名無しさん
08/10/13 22:26:54
2.7.2 RC3でた

489:デフォルトの名無しさん
08/10/18 12:49:41
URLﾘﾝｸ(pragprog.com)

490:デフォルトの名無しさん
08/10/18 13:20:09
>>489
> March 30, 2009.
orz

491:デフォルトの名無しさん
08/10/18 13:53:15
あー489はOdersky本とは別ですよ。タイトル同じだけど。

これも別ね。
URLﾘﾝｸ(blog.aspectprogramming.com)

492:デフォルトの名無しさん
08/10/19 00:22:05
タイトル、微妙に違うくね？

493:デフォルトの名無しさん
08/10/22 07:54:12
Programming in Scala is at the Printer
URLﾘﾝｸ(www.nabble.com)
> most likely we'll be shipping printed copies to all those who bought them the second and third week of November.

まだ先かー。

494:デフォルトの名無しさん
08/10/23 10:03:02
今日は、Scala勉強会@東北の日。東北と言っても、開催するのはネット上。夜の8時から。

495:デフォルトの名無しさん
08/10/24 20:23:54
エロい人ならScalaでグラフ構造ってどうつくるんだろう？
自分でつくると、JAVAで作ったのと変わらない物ができてしまう・・・
caseクラスとか駆使して、もっと、かっちょよく作れないもんかな。

496:デフォルトの名無しさん
08/10/24 22:16:36
そんなメタな構造なら、どんな言語で作っても基本は同じになるんじゃない？
それにメタであるだけに、応用によって実装のしかたは変わるし。
「アルゴリズムがJavaならオブジェクト指向に！」みたいな違和感がある。

497:デフォルトの名無しさん
08/10/25 07:07:55
Scalaって下がJavaだから仕方ないんだろうけど、
他の関数型言語だと構文で解決するようなものを
動的な仕組で無理矢理そう見せてる部分が筋がよくなくてどうにも気持ち悪い。

498:デフォルトの名無しさん
08/10/25 12:34:48
tatoeba?

499:デフォルトの名無しさん
08/10/25 15:26:47
>>497
んなこたあ無いと思うが、具体例は？

500:デフォルトの名無しさん
08/10/25 16:42:48
>>497
え？動的な仕組で無理やり解決？それってむしろ他の関数型言語でしょ。
Scalaは静的な仕組みで無理やり解決だよ。

501:デフォルトの名無しさん
08/10/25 16:49:35
リストの構築子も :: なんてそれっぽいものを用意してはあっても
所詮はメソッドのお化粧なのでパタンに書けないとか。

パタンマッチするのにケースクラスなんてものを導入せざるを得なかったのが
そもそもそうだと思うし。

502:デフォルトの名無しさん
08/10/25 17:29:45
ポイントがよくわからんので具体的なコードで他言語と比較してほしいなあ。

503:デフォルトの名無しさん
08/10/25 18:01:52
>>501
なんとなくわかった。
ちょっと違うが、JavaのGenericsのような無理や不自由さがあるということか。

504:デフォルトの名無しさん
08/10/25 18:04:49
余計わかんねー。Javaのジェネリクスって動的な仕組みなの？

505:デフォルトの名無しさん
08/10/25 18:10:26
>>501
えーと、::はListクラスのメソッドであり、かつcase classだからパタンに書けるんだが…
それはともかく、ケースクラスを導入せざるを得なかったってのは違うと思うな
パターンマッチングという機能をプリミティブで拡張性の無いものでなく、ユーザが
後付けでパタンを定義できて拡張性のあるものにするためにどうすればいいのか
という問題に対する解の一つがケースクラスなりExtractorであるってことだと思う
MLとかのパターンマッチに関する有名な問題の一つとして、抽象データ型に
対してパターンマッチできん、というのがあるけど、Scalaではこの点はそもそも
問題にすらならない

506:デフォルトの名無しさん
08/10/25 22:00:06
>>504
仕組みや目的はまったく違うけど、VMの仕様が言語に影響して無理があって不自由なところが一緒かと

507:デフォルトの名無しさん
08/10/26 11:17:41
JVM 上の Scheme とか普通にあるし、VM の仕様より、既存の Java ライブラリとの親和性を
重視してるかどうか、の違いでわ?

508:デフォルトの名無しさん
08/10/26 19:05:01
なんつーか、JVMの仕様からくる言語使用上の制約は実際あって思いつくけれども、
最初に動的とか非関数型的とかって書いたのはテキトーでしょ？
いずれにせよもうちょっと具体的に語ってくれればその通りだねとかいやそれは違うとかいえるんだけどさ。

509:デフォルトの名無しさん
08/10/26 23:59:56
>> 507
動的な型の言語と比較するのはあまり意味がないと思われる。

510:デフォルトの名無しさん
08/10/27 00:37:34
>>506
Javaからも呼び出せるように class としてバイナリを作成するがために、言語仕様に制約が出ているんじゃないかってことと考えて良い？

511:デフォルトの名無しさん
08/10/27 09:19:20
>>501
そりゃ構文の話で、動的とか静的とか関係ないだろ。

512:デフォルトの名無しさん
08/10/27 09:27:01
>>505
case classを使ったパターンマッチを、
クラス上のデザインパターンにするって主旨の設計だからねえ。
データ構造に依る分岐構造を、
データ構造上のcase classにまとめて整理しようって考え。
Scalaは型大好きだから。

パターンマッチ作法が強制されるけど、
整理の仕方としては面白いわね。

513:デフォルトの名無しさん
08/10/27 11:52:41
オカマっぽい

514:デフォルトの名無しさん
08/10/28 20:20:27
>>513
すまん。女です。

515:デフォルトの名無しさん
08/10/29 10:13:26
ワロタ

516:デフォルトの名無しさん
08/10/30 02:43:53
2.7.2 RC4でた

517:デフォルトの名無しさん
08/11/02 01:52:02
RC5でた

518:デフォルトの名無しさん
08/11/02 10:54:35
RC6でた

519:デフォルトの名無しさん
08/11/02 21:36:53
RC7でた

520:デフォルトの名無しさん
08/11/02 23:10:55
いや、マジで今 RC6

521:デフォルトの名無しさん
08/11/03 00:43:24
RC8来たよ

522:デフォルトの名無しさん
08/11/03 01:14:09
マジかと思って見てみたらRC9が出てるし

523:デフォルトの名無しさん
08/11/03 01:35:29
Programming in ScalaってAmazonとかで買えるようになるんですかね？

524:デフォルトの名無しさん
08/11/03 19:27:53
そうして RC365 まで毎日でるわけですね

525:デフォルトの名無しさん
08/11/03 21:02:39
>>524
そこまでRubyの真似をしなくていいよwww

526:デフォルトの名無しさん
08/11/04 01:01:21
>>525
Vimのまねだったらやだな。

527:デフォルトの名無しさん
08/11/04 10:30:07
D言語みたいに、0.99から0.100になるよりは期待感なくてよいじゃないの

528:デフォルトの名無しさん
08/11/05 11:49:46
scala・・・この言語イマイチだねえ

529:デフォルトの名無しさん
08/11/05 11:50:38
とにかく中途半端な印象しかない

530:デフォルトの名無しさん
08/11/05 16:26:21
とにかくイマイチ絶対に例を挙げない

531:デフォルトの名無しさん
08/11/05 17:36:06
あくまで実用本位で言語オタク受けは眼中にないからな

532:デフォルトの名無しさん
08/11/05 17:46:01
えっ！？

533:デフォルトの名無しさん
08/11/05 19:06:39
rubyの気持ち悪さ異常

534:デフォルトの名無しさん
08/11/05 22:11:20
ruby や groovy は、いいときはミラクルなまでにサクサク進むけど
バグるとプロでもさじを投げるぐらいデバッグが超絶困難なようだね

535:デフォルトの名無しさん
08/11/05 22:42:12
コミュニティの性格に似てるかもな。
好きなスタイルで気分良くモノを進めている時は非常に良い顔を見せるが、
好まないスタイルとの出会いや不機嫌に耐性が無く、そういう時は非常に排他的で非生産的になる。

536:デフォルトの名無しさん
08/11/07 23:54:23
>>534
普段、静的型付け言語とRubyつかっているけど、たまに頭のモード切替が不十分で
静的みたいに書いちゃって、なかなか気づかないバグ残したことがあるよ。

この前ハマったのは、クラスのプロパティをattr_accessorだかで定義して、
自クラス内でプロパティ名そのままでアクセスしようとして、上手くいってなくて、
1日悩んだ挙句、self.プロパティ名、でアクセスしないといけないことに気づいたことかなｗ
アホか俺は、と思ったけどｗ

537:デフォルトの名無しさん
08/11/08 00:07:25
スレ違い

538:デフォルトの名無しさん
08/11/08 10:22:16
Actor の link って何に使うのか良くわからん・・・・

539:デフォルトの名無しさん
08/11/08 12:25:48
別のアクターが終了したのを検知する（あるいは一緒に死ぬ）ため。

540:デフォルトの名無しさん
08/11/08 15:06:14
ありがとうー。
Exit メッセージが来るってことですね。

てっきり、複数のアクタをグループ化して、メッセージのマルチキャストみたいなことができるのかと勘違いした。

541:デフォルトの名無しさん
08/11/08 15:08:13
あぁ、そうか。プロセスと同じように考えればいいのか。
親プロセスが死んだら、子プロセスも死なすって考えればいいのか。

542:デフォルトの名無しさん
08/11/08 15:51:32
メッセージのマルチキャストは、仲介役のアクタを用意して、自前でやるってことか・・・
URLﾘﾝｸ(www.nabble.com)

543:デフォルトの名無しさん
08/11/10 12:20:05
Scala 2.7.2 final キタ！

544:デフォルトの名無しさん
08/11/10 21:13:27
次は final2 がリリースされるんですね、わかります。

545:デフォルトの名無しさん
08/11/15 08:39:33
Programming in Scalaって出版されましたか？

546:デフォルトの名無しさん
08/11/15 21:33:35
11月25日前後を刮目して待て！

547:デフォルトの名無しさん
08/11/15 22:09:54
刮目して待ちます！

548:デフォルトの名無しさん
08/11/19 00:11:34
Programming in Scala 出版age

549:デフォルトの名無しさん
08/11/19 12:03:23
紙の本はまだだな

550:デフォルトの名無しさん
08/11/20 22:06:48
紙のほうは日本で買えるんですか？

551:デフォルトの名無しさん
08/11/21 08:26:36
アマゾンで買えるようになんじゃね

552:デフォルトの名無しさん
08/11/25 11:07:31
下は公式サイト（確か・・）で取ったサンプルコードなんだが、
作成アクター数（nActors)が500くらいからエラー吐きまくり・・

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

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

object Message {
def main(args: Array[String]) {
val n = try {
Integer.parseInt(args(1))
} catch {
case _ =>
println("Usage: examples.actors.Message <n-actors> <n-times>")
Predef.exit }
val nActors = 1000
val finalSum = n * nActors
Scheduler.impl = new SingleThreadedScheduler

553:デフォルトの名無しさん
08/11/25 11:08:50
// 続き１
def beh(next: Actor, sum: Int) {
react {
case value: Int =>
val j = value + 1; val nsum = sum + j
if (next == null && nsum >= finalSum) {
//println(sender)
println(nsum)
System.exit(0)
} else {
if (next != null) next ! j
//println(sender)
beh(next, nsum) }}}

554:デフォルトの名無しさん
08/11/25 11:13:52
// 続き２
def actorChain(i: Int, a: Actor): Actor =
if (i > 0) actorChain(i-1, actor(beh(a, 0))) else a

val firstActor = actorChain(nActors, null)
var i = n
while (i > 0) {
firstActor ! 0
//if (i % 100 == 0) println(i)
i -= 1 }}}

555:デフォルトの名無しさん
08/11/25 11:20:20
nActors >= 473 で
以下を延々吐くみたい

at Message$$anonfun$beh$1$1.apply(message.scala:34)
at Message$$anonfun$beh$1$1.apply(message.scala:25)
at scala.actors.Reaction.run(Reaction.scala:78)
at scala.actors.SingleThreadedScheduler.execute(Scheduler.scala:174)
at scala.actors.Scheduler$.execute(Scheduler.scala:80)
at scala.actors.Actor$class.send(Actor.scala:411)
at scala.actors.Actor$$anon$1.send(Actor.scala:93)
at scala.actors.Actor$class.$bang(Actor.scala:583)
at scala.actors.Actor$$anon$1.$bang(Actor.scala:93)

556:デフォルトの名無しさん
08/11/25 17:50:27
StackOverflow が出てるんだけど、-Xmsをいくら増やしても改善しない。これはバグかもわからんね・・・

557:デフォルトの名無しさん
08/11/25 18:51:51
Programing in Scala v6(PDFと紙で買える奴な)
で、p73に

val greetStrings = new Array[String](3)

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

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

だってさ　＼(^o^)／

2.7.1は全く問題なし　＼(^o^)／

とってもBuggyです本当ny

558:デフォルトの名無しさん
08/11/25 20:01:50
何気にインタプリタでArrayを内容表示する方式が変わったんだな。
昔は [L 方式で、新しいのは中身も表示してあげようとして要素のtoString呼んじゃってるようだ。
ArrayのtoString自体には問題ないようなのでインタプリタ固有の表示ルーチン持ってるんかな。

559:デフォルトの名無しさん
08/11/25 21:14:09
昔は単純にオブジェクトのtoStringを呼んでたんだけど、
新し目の版ではScalaRuntime#stringOfってメソッドを追加してそっちを使っているようだ。
stringOfはval a = null みたいなのについて例外を出さなくしてくれるのだが、
ArrayについてはtoStringじゃなくdeepToStringを呼ぶようにしていて、
このdeepToStringは要素のnullには（たぶん昔から）対応していないんだな。

560:デフォルトの名無しさん
08/11/25 21:33:26
val greetStrings = Array.make[String](3, "")
でとりあえず回避可

561:デフォルトの名無しさん
08/11/25 22:57:29
>>556
-Xss でかくするとか

562:556
08/11/25 23:29:14
>561
スマソ、556は-Xssのtypoでした。
Xmx,Xssとも増やしてもだめだった。＞＜

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

URLﾘﾝｸ(lampsvn.epfl.ch)

ちなみに、上記のソースも
Scheduler.impl = new SingleThreadedScheduler
をしなければ、動くはず。

563:561
08/11/26 12:57:09
java -Xss64M -cp scala-library.jarのパス:. Message 1000 1000
こちらではこれで動きますた

564:561
08/11/26 13:16:35
ちなみに
Scheduler.impl = new SingleThreadedScheduler
をしてる方
あと、デフォらしい -Xss512K では StackOverFlow しましたが
-Xss1024K なら大丈夫でした

565:556
08/11/26 13:43:32
>563
むむっ・・・本当ですね・・・
当方、環境変数JAVA_OPTSで設定していたつもりが、
なにか間違っていて設定が効いてなかったみたいです。orz

結局、単純に2.7.2でスタックの消費量が増えてたってことっすね・・・

566:デフォルトの名無しさん
08/11/27 23:58:25
>>551
本当にアマゾンで買えるのかなあ？
いまだに上がってない・・・
3月発売予定の達人のほうは上がっているのに・・・

567:デフォルトの名無しさん
08/11/28 00:55:36
まだみたいだね
URLﾘﾝｸ(www.amazon.com)

568:デフォルトの名無しさん
08/12/01 10:45:13
買えるようになったな

569:デフォルトの名無しさん
08/12/08 07:09:25
今日、やっと pattern matching の凄さを、下にある OCaml の加減乗除算式を変形する
コード例で理解できました。

　URLﾘﾝｸ(www.ocaml-tutorial.org)

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

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

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

　URLﾘﾝｸ(lampsvn.epfl.ch)

Scala の「pattern-matching is not exhaustive.」警告について教えてくださいませ。

570:デフォルトの名無しさん
08/12/08 09:07:06
>>21を読めばいい

571:デフォルトの名無しさん
08/12/08 13:01:16
>>570 >>21を読めばいい

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

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

Scala に喰らい尽きたくて涎が出ています。ただ、scala に移ってくる programmer の割
合が心配です。Java programmer の殆どは scala には移ってこないだろうと思っていま
す。Python から scala に来る programmer の方が多そうに思えます。

572:デフォルトの名無しさん
08/12/08 22:57:13
>>571
誰がどこから移ってくるとかどうでもいい

573:デフォルトの名無しさん
08/12/09 09:15:41
どうでもいいと思ってるなら書かなきゃいいのに。
いちいち自分の興味ない話題に「どうでもいい」なんてレスしてたらキリないぞ。

574:デフォルトの名無しさん
08/12/09 09:44:20
「どうでもいい」厨にレスしなくていいよ。
どこにでもいるから。
専用ブラウザのあぼーんに設定しておけばそれで済む話

575:デフォルトの名無しさん
08/12/09 17:12:50
自意識が分相応なところに落ち着く前の年齢なんでしょ。

「この俺が、他ならぬこの俺が、どうでもいいと思った！
この話題自体はどうでもいいことだが、この俺がどうでもいいと思ったことは
なんとしても書き込まれねばならない重大ニュースだ！」

576:デフォルトの名無しさん
08/12/09 17:15:20
なんて中身の無いスレだ

577:デフォルトの名無しさん
08/12/09 21:27:15
Scalaでスカラ

578:デフォルトの名無しさん
08/12/10 00:15:14
珍しく書き込みが続いたと思ったらこれかよ

579:デフォルトの名無しさん
08/12/10 01:05:02
3っつもレスがつくなんて>>572も書き込んだかいがあったな

580:デフォルトの名無しさん
08/12/11 08:47:42
>>569 です。scala へ飛び込むための背中押しをお願いします。また Java は殆ど使って
いないので誤解があったら指摘してやってください。

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

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

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

　　return tAt/len(listOfT)

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

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

これが可能ならば scala に飛び込みます。よろしく教えてやってくださいませ。

581:デフォルトの名無しさん
08/12/11 09:49:16
Scalaやらないでいいよ。

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

583:デフォルトの名無しさん
08/12/11 13:33:44
>>569 です。ご意見ありがとうございます。

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

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

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

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

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

584:582
08/12/11 19:16:55
>>583
>>582では、筆が滑って偉そうな書き方になってしまった。申し訳無い。

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

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

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

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

585:582
08/12/11 19:17:48
レスが長くなったので分割しました。

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

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

他にもありますが、とりあえずこの辺で。

586:デフォルトの名無しさん
08/12/11 22:18:27
えー、Javaでも反変あるでしょ？
Scala特有なのはvariance annotationで自動的に共変なり反変なりになるところだと思う。

587:デフォルトの名無しさん
08/12/11 23:17:31
$ scala helloWorld.scala
/work/helloWorld.scala:1 error: not found: value println
println("hello, world!")
^
one error found

588:デフォルトの名無しさん
08/12/11 23:27:20
それからScalaのジェネリクスがC++とJavaのどちらと多くを共有しているかっていったら問答無用でJavaのほうだよ。
それでScalaやらないでC++やるっていうんだったら好きにすればいいと思う。
「C++にできてJavaにできない○○があるが、Scalaではどうか？」って聞いてくれればがんばって答えてみるかも。

589:582
08/12/11 23:38:37
>>586
ワイルドカードの下限境界の事言ってる？あれは「型を使う側」で明示的に指定しない
といけないという点で違うし、制限も強い。ワイルドカードに相当するのは、Scalaだと
Existential Typeだね。

590:デフォルトの名無しさん
08/12/11 23:42:16
いや、だから反変がJavaにはないっていうのは違うでしょ？

591:582
08/12/11 23:54:19
いや、A <: B => T[A] <: T[B]であるような、厳密な意味での反変はやはり無いと
言って良いと思う。Javaの場合、A <: B => T[A] <: T[? extends B]なわけだし。
ただまあ、誤解を招く書き方ではあったかもしれんとは思うけど。

592:582
08/12/11 23:58:46
すまん。共変と反変が逆になっとる。正しくは、以下。

いや、A <: B => T[B] <: T[A]であるような、厳密な意味での反変はやはり無いと
言って良いと思う。Javaの場合、A <: B => T[B] <: T[? super A]なわけだし。
ただまあ、誤解を招く書き方ではあったかもしれんとは思うけど。

593:デフォルトの名無しさん
08/12/12 08:35:32
>>569 です。582 さん、詳細に答えて下さり感謝します。

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

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

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

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

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

もうすこし調べてみます。ありがとうございました。

594:デフォルトの名無しさん
08/12/12 18:54:30
相対論スレかと思った

595:デフォルトの名無しさん
08/12/13 00:12:24
scalaを使うと並列処理がとても上手く書けると聞いた
そのメカニズムを教えてくれないか？

596:デフォルトの名無しさん
08/12/13 00:15:40
関数型だから？？

597:デフォルトの名無しさん
08/12/13 00:19:00
つ URLﾘﾝｸ(www.scala-lang.org)

598:デフォルトの名無しさん
08/12/13 12:45:16
>>587
あえて print1n にしてエラーメッセージ出させるとうちの 2.7.2 final では
(fragment of HelloWorld.scala):1: error: not found: value print1n
print1n("Hello, world!")
^
one error found
!!!
discarding <script preamble>
となる
エラーメッセージ冒頭が違うのは何故？

599:デフォルトの名無しさん
08/12/13 15:09:29
なんか結局Java7にクロージャ入らないらしいので
結構本当にScalaの時代が到来するのではないか。

600:デフォルトの名無しさん
08/12/13 16:38:09
ないないw
エッジな人達はとっくに関数型に行ってるし
そうでない人にScalaは無理
下級兵士はこれからもJavaだよ

601:デフォルトの名無しさん
08/12/13 17:03:06
俺もScalaの時代が来るかについては否定的だけど
Javaな人に関数型の考え方を知ってもらう教材としてScalaは悪く無いと思う
適切なドキュメントさえあればScalaを学ぶのはそう難しいことではない

602:デフォルトの名無しさん
08/12/13 19:49:40
エッヂな人達って関数型に行ってもやっぱり実際に物作るのはC++とかスクリプトとかじゃないの？

603:デフォルトの名無しさん
08/12/13 20:37:13
エッチな人なので関数型言語でWEBクローラつくりました

604:デフォルトの名無しさん
08/12/13 22:32:32
>>599
RubyでいうRuby on Railsのようなキラーライブラリの爆発のようなもの必要だな

Liftはあるが、採用実績はまだこれからだ
Lift Web Framework: Home
URLﾘﾝｸ(demo.liftweb.net)

↓後はLiftのようなものを流行らせるなら、こういう記事がもっと増えて、
InfoQ: David Pollak氏 lift と Scala を語る
URLﾘﾝｸ(www.infoq.com)

さらにこういう本まで出版しないと
Amazon.co.jp： JavaからRubyへ ―マネージャのための実践移行ガイド: Bruce A. Tate, 角谷信太郎: 本
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(images-jp.amazon.com)

おれ自身はRuby好きだけど、静的の魅力も知っているとScalaにすごく期待したくなるわけだよ

605:デフォルトの名無しさん
08/12/13 22:38:38
liftよりWeb Flavorに期待してる。あと、WicketはJavaよりScalaの方が書き易そうな気がするんだ。

606:デフォルトの名無しさん
08/12/13 22:46:11
昔はEJBが駄目すぎたけど今や
生産性なんて言語やフレームワークでそんなに違うかって思う
それより絶対性能の高さや簡単に数十台規模のシステムを開発できる
フレームワークでも作ってくれた方がありがたい

607:デフォルトの名無しさん
08/12/14 00:54:45
>>601
Javaな人に関数型を知ってもらうなら、Groovyでどうよ？

608:デフォルトの名無しさん
08/12/14 01:56:17
>>606
実際は大して違わないんですよ。

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

他に・・・

何がいると思いますか？

609:デフォルトの名無しさん
08/12/14 05:05:36
>>607
Groovyは関数型の要素が少な過ぎると思う。無名関数くらいじゃない？
しかも、そのくらいなら今どきの言語のほとんどが持っている機能だし
それにGroovyは関数型的な(immutableな)データ構造を作成するのを助けてくれないよね
Scalaは関数型的なデータ構造を作りやすい構文になってるので、その点でもScalaの
方が良いと思う

610:デフォルトの名無しさん
08/12/14 09:48:57
「関数型的なデータ構造」なんて曖昧な言葉は使わずに、
「代数的データ構造」と言いましょう。

611:デフォルトの名無しさん
08/12/14 11:17:44
>>610
代数的データ構造と言っちゃうとかなり範囲を限定しちゃうでしょ
immutableなデータ構造全般を指すつもりで関数型的なデータ構造と書いた

612:デフォルトの名無しさん
08/12/14 11:29:23
コンストくらいしかないような

613:デフォルトの名無しさん
08/12/14 23:07:17
>>598
Ubuntuでsynapticから入れたんですけど、
エラーになるんです。

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

こんなになるんです。

614:デフォルトの名無しさん
08/12/15 00:37:57
2.3.0 のようです
URLﾘﾝｸ(ubuntuforums.org)
ちなみに Debian の Etch も 2.3.0

Java 系はプラットフォームを汚すことはめったにないので、
Scala ホームサイトから直落としでも良いかと
Debian の Java は GNU 系に力を入れてるんで、 Sun 系の
方はまだまだです

615:デフォルトの名無しさん
08/12/15 20:28:40
>>614
アドバイスありがとうございます。
tar落としてきてやってみたらうまくいきました。

616:デフォルトの名無しさん
08/12/17 13:37:24
URLﾘﾝｸ(neopythonic.blogspot.com)

617:デフォルトの名無しさん
08/12/17 21:15:12
>>616
最初の学習曲線が厳しいようだ
私は Odersky の文章のまずさ (英語ネイティブでないのでしかたないのだが)
が最初にして最大の壁になるだろうな、と言語仕様を読んでて思ったが

618:デフォルトの名無しさん
08/12/17 23:58:38
>>617
俺は英語能力あまり無いのでOderskyの文章のどの辺がまずいのかあまり
よくわからんかったのだが、たとえば言語仕様のどの辺の文章？

619:デフォルトの名無しさん
08/12/18 20:26:02
どの辺というか、全体的に大ざっぱすぎたり専門的すぎたり、てか
書きぶりなどからして文章書いてる時間的余裕がなさげな感じ
明白なミスはほとんどないんだけど (616 紹介中の文章で can learning と
かあってわらたw)、肝心なところで何十回も読まないと何が言いたい
のか的を得なかったり、もっと簡単に言えるところを妙にまわりくどく
表現したり
まあさすがに数十回も読み直すうちに慣れましたが
(だから、例の本も当人が書くと知ってちょっと不安に思いますた、買う
予定ないけど)

次ページ