- 1 名前：デフォルトの名無しさん mailto:sage [2008/03/10(月) 22:40:17 ]
- The Scala Programming Language
ttp://www.scala-lang.org/
チュートリアル日本語訳
ttp://homepage.mac.com/takashi_miyamoto/scala/ScalaTutorial.pdf
どう書く？org Scala
ttp://ja.doukaku.org/lang/scala/
- 75 名前：デフォルトの名無しさん mailto:sage [2008/03/24(月) 00:03:13 ]
- Scalaのライブラリはどうですか？
- 76 名前：デフォルトの名無しさん mailto:sage [2008/03/24(月) 11:10:28 ]
- >>74
粒度が細かすぎて使いづらいというのはよく言われていることだけど、
それをScalaから使うというのがまたしんどい
結局Java使ってるのと大差ない気がしてくる
- 77 名前：デフォルトの名無しさん mailto:sage [2008/03/24(月) 12:57:22 ]
- >>76
Scalaから使うときは簡単なラッパーをかましてやるのが良い使い方だと思う
本当のところ、早いところScala独自のライブラリが充実して欲しいんだけど
簡単なラッパー作るくらい大した手間じゃないし自作するのが手っ取り早い
たとえば、IOならこんな感じ
// 定義
def withReader[T](File path)(proc :BufferedReader => T) :T = {
val reader = new BufferedReader(new FileReader(path))
try {
proc(reader)
} finally {
reader.close
}
}
// 使用
withReader(new File("hoge.txt")){reader =>
//readerを使ったコード
}
ちなみにscala.io.Sourceは色々と微妙で、使いづらい
- 78 名前：デフォルトの名無しさん mailto:sage [2008/03/24(月) 22:58:01 ]
- それだと使う側のセンスが問われそうだな
俺だと劣化Rubyライブラリになってしまいそうだ
標準ライブラリで言語のポテンシャルを示してほしいところなのだが
つーかこんなラッパーが全世界で何百と作られてんだろうなあ
- 79 名前：デフォルトの名無しさん mailto:sage [2008/03/24(月) 23:01:55 ]
- というかラッパーが物凄く簡単に書けて、
再利用性も高いのが言語の売りの一つなので。
- 80 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 10:15:09 ]
- Lisp方言並に溢れかえるラッパーにｗｋｔｋ
- 81 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 12:08:18 ]
- >>48に誰も反応してくれなくて寂しい俺が来ましたよ
# あれは正確には、「JVM命令セット群のセマンティクス」と書くべきだった
ライブラリの話も出てるし、言語として完成度上げるには、やっぱそろそろJava依存抜けようか。
って無理か。
- 82 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 16:48:04 ]
- どうしても隠せないのは実装に近いところ。
例えばboxing/unboxing関係のAnyVal/AnyRef。
- 83 名前：暗黙のthis mailto:sage [2008/03/25(火) 17:24:39 ]
- ScalaOverview.pdfの
def + (x: Nat): Nat =
if (x.isZero) this else succ + x.pred
って、
def + (x: Nat): Nat =
if (x.isZero) this else this.succ + x.pred
のことなんだな。ちょっと混乱したので書いとく。
- 84 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 17:58:15 ]
- >>81
配列周りはScalaの処理系が凄いがんばって他のgenericなクラスと同じように
見せようとしてるなあと思った。JVMでは配列が特別扱いされてるから、
genericなクラスのように見せかけるのはなかなか大変
>>83
暗黙のthisはJavaでもほぼ同じだから、そんなに混乱しないと思ったけど、どうなんだろう。
Java以外の言語からScala入った人？
- 85 名前：暗黙のthis mailto:sage [2008/03/25(火) 18:04:02 ]
- operation invocationに()がないから混乱した。
Java以外にも関数型言語も分かるので、
curry化されてるのかな？と思ってしまった。
- 86 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 18:04:55 ]
- >>82
> boxing/unboxing関係のAnyVal/AnyRef。
なんとなく想像は付くんだが、具体的にはどんな例がある？
- 87 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 18:06:59 ]
- >>85
ああ、なるほど。invocationの()省略できる辺りは、なんか
構文的にRubyっぽい感じがするね。Scalaは細かいところで、
色々syntax sugarが多いから、慣れない内は混乱の元にも
なるなと思った
- 88 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 18:11:19 ]
- あ、省略できるってのはちょっと不正確だったのでちょっと補足。
Scalaで0引数のメソッドを定義する方法は二つあって、
一つは
class HelloWorld {
def print :Unit = { println("Hello, World!") }
}
という形。この形の場合、
val hello = new Hello
hello.print
という形でのみ呼び出すことができ、hello.print()という呼び出し形式は
コンパイルエラーになる。もう一つは、
class HelloWorld {
def print() :Unit = { println("Hello, World!") }
}
という形。この形の場合、hello.print()と書いてもhello.printと書いても
OK。
- 89 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 18:29:49 ]
- >>86
BoxedArrayはあれば便利だけど、なくても何とかなる。
どうしてもArrayの要素をポインタ共有したい時は、
セルクラスに入れてからArrray[セル]にすればいいから。
けどJavaではBoxedArrayがあるから、作っとかないと困る。
>>84のいうようにうまく処理されているとは思う。
Nothingがあるからprimitive = null;問題も起きないし。
- 90 名前：デフォルトの名無しさん mailto:sage [2008/03/26(水) 02:37:56 ]
- あんま愚痴っててもしょうがないので、
ありがちなところで、Ruby風文字列、正規表現ラッパーを作ってみた
と言っても、まだ半分も実装できてないけど
hexx.sakura.ne.jp/scala/RubyString.scala
使い方は、こんな感じ
import ruby._
import ruby.RubyString._
println("hoge %d %s" % (1, "fuga"))
// → hoge 1 fuga
// Rubyでは
// "hoge %d %s" % [1, "fuga"]
"a\nbbb\nccccc\n".each(l => print(l.length))
// → 246
// Rubyでは
// "a\nbbb\nccccc\n".each {|l| print(l.length)}
println("abcde".sub("(a)b(c)d(e)") { m =>
val lm = RubyRegexp.lastMatch
lm(1).upcase + lm(2).upcase + lm(3).upcase
})
// → ACE
// Rubyでは
// "abcde".sub(/(a)b(c)d(e)/) { $1.upcase + $2.upcase + $3.upcase }
今のところ、Rubyに比べて嬉しいのは、EmacsのFlymakeがよく効くところだな
悪いところは、スクリプトで使うと、やっぱり起動が遅い
- 91 名前：デフォルトの名無しさん mailto:sage [2008/03/26(水) 02:57:01 ]
- >>90
遅いよねぇ。
開発をスクリプトでやってデプロイはコンパイルしてって感じになるのかな。
でもあの起動の遅さはリズムが崩れる。
- 92 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 00:39:06 ]
- NetBeansでScalaが書けるって聞いたんだけど
試してみた人いる？
- 93 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 00:42:07 ]
- >>90じゃあ開発者の楽しさとしてはやっぱりRubyのほうがいいんだね。実行するたびにモタつくなんてなぁ。
- 94 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 01:38:57 ]
- >>93
> 開発者の楽しさ
俺はコンパイラに指摘される型エラーをつぶしていくのが楽しい
だからMLも好き
- 95 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 06:50:40 ]
- 同じJVMをつかっているのに、なぜJRubyよりも性能がいいのですか？
Rubyをなんちゃって言語というほど高尚なのですか？Rubyより悪い点はどこですか？
- 96 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 07:01:52 ]
- >>95
性能がいいのは主に
・静的型付けであり、かつ比較的Javaに型システムが近いこと
(メソッド呼び出し時にinvokevirtualなどVMのメソッド呼び出し命令をそのまま
利用できるし、数値演算もVMの命令を利用できる)
が理由だろうな。他の理由もあるだろうけど、たぶんこれが一番大きい。
- 97 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 09:36:07 ]
- 楽しさって言われてもなあ、スクリプトの起動がそれほど気になるならそうかもしれないけど
対話環境で開発することも多いだろうし、Scalaはスクリプトの方がメインではないだろうし
Rubyとの違いは、やっぱり型が静的か、動的かにつきるんじゃないの？
静的な型でもここまでできると思うか、
やっぱり面倒臭いから静的な型なんていらないと思うか
あとは関数型から引き継いだパターンマッチ、ケースクラスとか
ErlangからパクったActorがどれくらい役に立つか
- 98 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 09:39:38 ]
- JRubyより性能いいの?
JRubyってJavaのバイトコードをターゲットにしたコンパイラなの?
独自バイトコードインタープリタなら遅くて当たり前だけど…
- 99 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 09:42:59 ]
- >>97
あと、mixin-compositionがあるのが重要。
- 100 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 10:03:23 ]
- ああ、そういえばScalaは後からmixinを足せるんだったな
確かに使い方によっては強力な感じはする
- 101 名前：デフォルトの名無しさん [2008/03/28(金) 11:34:23 ]
- ぶっちゃけmixinはあんまり要らんなーと個人的には思う
caseクラスとかマッチングあたりはうれしいけど
Actorはまだ触ってないのでなんとも
- 102 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 13:53:22 ]
- >>92
6.1betaに開発版プラグインの所を参照させて出来たよ。
- 103 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 14:52:00 ]
- actorやmixinはプログラミングモデルだから、
慣れてない人は有り難みは分からない。
使って慣れるのみ。
- 104 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 16:36:28 ]
- >>101
mixinはライブラリ書くとき嬉しいよ
例えば、コレクションぽく見せかけたいものに対して、scala.Iterable[T]をmix-inして、
elements :Iterator[T]だけを実装すれば、Iterable[T]にある便利な高階関数やらを
全部使えるとか。たとえば、Reader系のクラスをサブクラス化してIterable[String]
を実装するなどが考えられる。
- 105 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 16:38:55 ]
- >>98
昔のJRubyは普通のインタプリタだったはず。その頃は凄く遅かった
最近のJRubyは内部でJVMのバイトコードにコンパイルして実行するようになった
ので速くなった。でも、Scalaには性能で遠くおよばない(言語の特性上仕方無い
けど)
- 106 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 22:34:26 ]
- 開発効率ではJRubyに遠く及ばない（言語の仕様上しかたないけど）
- 107 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 22:48:31 ]
- どうせJRubyもScalaも使ったことないくせに
- 108 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 22:58:47 ]
- JRubyは使ってるよ。Scalaはこれから試すよ。
仕様が汚ないけど、型があるからRubyより性能は良いってことだろ。
- 109 名前：デフォルトの名無しさん mailto:sage [2008/03/28(金) 23:13:00 ]
- マジレスだったのかよ！
で、Scalaの仕様のどの辺が気に食わないのよ
開発効率が遠く及ばないというほどの何かがあるの？
- 110 名前：デフォルトの名無しさん mailto:sage [2008/03/29(土) 03:11:22 ]
- rubyの話いらね
- 111 名前：デフォルトの名無しさん mailto:sage [2008/03/29(土) 08:35:05 ]
- >>104
多重継承の代用？
多重継承ではなくmix-inが欲しくなる場面の例はありませんか？
- 112 名前：デフォルトの名無しさん mailto:sage [2008/03/29(土) 09:06:23 ]
- 基本的にmixinは多重継承の代用でしょ
mixinそのものの有用性については
Rubyが先駆者だからRubyの事例を調べた方がいいと思うよ
(またRubyの話になっちゃったけど…)
- 113 名前：デフォルトの名無しさん mailto:sage [2008/03/29(土) 10:23:43 ]
- 機能的にはリッチ版だよ。
name conflictやmutliple pathを解決するための機構をプログラマに対して与える。
どれもがコンクリートクラスになりがちなクラス指向のプログラミングモデルから、
機能mixinを集めてくっつけて実用クラスを構成する〜モデルになる、というかする。
name conflictやmutliple pathはmixする時に解決できるから、
このクラスとあのクラスはうまく多重継承/結合出来ないというケースがぐんと減る。
代用とかじゃなくて、機能が増えたのがmixin。
元祖はLisp Machine LispのFlovors。
基本フレーバーを調合して、香水を作るって考え。
コンポーネント志向が強い。
もちろんmixinなくても同じことはできるよ。
アセンブラあればなんでもできるという意味では。
- 114 名前：デフォルトの名無しさん mailto:sage [2008/03/29(土) 10:39:13 ]
- え、ちょっとよくわからない
どの辺が多重継承よりリッチなの？
- 115 名前：デフォルトの名無しさん mailto:sage [2008/03/29(土) 10:56:30 ]
- つ 版
- 116 名前：デフォルトの名無しさん mailto:sage [2008/03/29(土) 11:03:09 ]
- 版？
- 117 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 00:34:31 ]
- 機能は多いだけじゃだめだとおもう。わかりやすくないと。
Rubyはその辺のバランス感覚に優れているからね。
- 118 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 00:53:52 ]
- Ruby信者もバランス感覚を覚えて欲しい
- 119 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 12:21:15 ]
- だからもっと具体的な話しろよ
Scalaの仕様のどこがいいとか悪いとか、mixinの話も>>111に答えてやれよ
と嗾けるだけでもなんだから
俺がScalaで良いと思ったのはカリー化と無名関数だな
Rubyのブロックはへんてこ構文だったけど、Scalaはすっきりしてると思う
- 120 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 17:56:01 ]
- 部分適用はあるが、カリー化なんてあったっけ?
- 121 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 18:02:14 ]
- カリー化はFunction.curriedでできるが、
ここで俺が言いたいのはカリー化された関数を直接書けるということだな
言葉足らずですまんが
- 122 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 18:12:43 ]
- これか
def add(a: Int)(b: Int)(c: Int) = a + b + c
add(1)(2)(3) // 6
- 123 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 18:18:28 ]
- >>119
それならお前が答えればいいのに
- 124 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 18:26:14 ]
- >>122
うん、それ
Rubyではわざわざブロック構文を導入しているが
Scalaではそれと無名関数を組み合わせて、
同じようなことがすっきりとできるじゃん
というだけの話なんだけど
>>123
いや、俺はmixinは制限付き多重継承だと思ってるから
だから>>113が答えてやれよと
まあ多重継承の定義の問題なんだろうな
- 125 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 20:11:51 ]
- > 俺はmixinは制限付き多重継承だと思ってるから
kwsk
- 126 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 20:25:14 ]
- mixin 多重継承でググれば、mixinは多重継承の一種だという説明が多い
Rubyのまつもとさんによれば、mixinは多重継承のサブセットらしい
俺もそう思っていたというだけの話
Scalaのmixinに何か特別な機能があるかどうかは知らない
- 127 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 22:16:06 ]
- >>126
基本的にそういう認識(mixinは多重継承のサブセット)でいいと思う
Scalaのmixinに何か特別な機能があるかと言えば、たぶん無い
俺がScalaで好きなのは、ExtractorとViews、implicit parameterだな
これらの機能がある言語は、今まで見たことがなかったので新鮮だった
- 128 名前：デフォルトの名無しさん mailto:sage [2008/03/30(日) 22:20:39 ]
- 開発効率の話について言えばScalaがRubyに遠くおよばないなんて
ことは無いと思う。静的言語ゆえの制約(evalできないとか)はもちろんあるけど、
そもそもそういうのを濫用したプログラミングはそうそうする必要は無いし
for-comprehensionやextractorなどRubyに無い便利な機能もあるし
- 129 名前：デフォルトの名無しさん mailto:sage [2008/03/31(月) 06:33:34 ]
- Scalaのmixinは多重継承にならないよう配慮してるね。
別クラスから継承して作ったtraitはmixinできないとか。
- 130 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 20:45:51 ]
- >>128正論だとはおもうが、そゆ発言はRuby厨を刺激するのでは
- 131 名前：デフォルトの名無しさん mailto:sage [2008/04/03(木) 23:51:57 ]
- 簡潔にかける!=わかりやすい、というのを体現した言語だなあ。
確かに個々の機能は優れていると思うが、表現の幅がひろすぎて自分とスタイルの違う書き方がほんと馴染まない。
Rubyのほうがコードの一貫性という意味では良いのかもしれないね。
- 132 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 00:32:15 ]
- 文法的にはRubyにforとパターンマッチが入った程度だろうに
ほんとにScala使ったことあるのかよ
- 133 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 00:45:09 ]
- >>131
Rubyと違って仕様が一貫してそうですが
- 134 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 02:23:30 ]
- >>132
＞文法的にはRubyにforとパターンマッチが入った程度だろうに
あなたもちゃんと使ったことがあるのか疑問があるんだが
どうせ、ちょっとTutorial見ただけで、決め付けただけなんじゃないの？
- 135 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 02:29:46 ]
- 特にScalaの型システム(implicit conversion, higher-kind generics, path-dependent typeなど)
調べてみれば、とてもRubyにforとパターンマッチが入った程度なんて言えない
もちろん、それらがどれくらい使い勝手に影響があるか、という評価は必要だが
- 136 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 02:33:36 ]
- >>134
ちゃんと使ったことあるというのがどのレベルかはわからないがプログラムはある程度書いたよ
他にRubyよりわかりにくくなるほど簡潔にかけるところあるか？
型絡みは簡潔にはなるという方向じゃないでしょ
>>135
だからViewsやジェネリクスでRubyより簡潔にはならないでしょ
>>131は簡潔に書けすぎたり、表現の幅が広すぎてRubyより一貫性がないって言ってんだから
そういうレベルの話だよ
つーか、なんで俺が文句言われるのがわからん
- 137 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 06:45:15 ]
- 相変わらずRuby厨が無駄に湧くスレだなぁ
- 138 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 10:52:07 ]
- 阿呆は放置推奨
- 139 名前：デフォルトの名無しさん [2008/04/04(金) 22:50:01 ]
- 逆にRubyやったことがある人に向いてる言語と思うんだけどなあ。
- 140 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 23:10:57 ]
- Rubyと比較しただけでRuby厨呼ばわりはひどいですね。
Rubyから来た私とJavaからの移行組の同僚のコードがスタイルバラバラになったんで感想を延べただけなんですが。
- 141 名前：デフォルトの名無しさん [2008/04/04(金) 23:27:13 ]
- 同僚って、もう仕事でしかも共同開発って使ってるの？すごい
- 142 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 01:02:21 ]
- Scalaで仕事？
- 143 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 01:30:16 ]
- >>140
コーディングスタイルについては、Rubyだってかなり幅が広くて、
書く人によって全然違うコードになったりすると思うんだが、違う？
というか、○○言語だったらコーディングスタイルを均質化できるというのが
そもそも幻想な気がする
- 144 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 01:31:53 ]
- 馬鹿だから厨と言われてるんであって、Rubyはむしろ被害者。
- 145 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 03:14:08 ]
- >>139
Rubyなんて触ったことすらない
- 146 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 08:32:24 ]
- >>143
そのとおり。というか>>131は、
Rubyでしか一貫性のあるコードが書けない（書く気がない）という気がする
- 147 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 22:34:48 ]
- 確かにrubyに似ているんだけど、{}スタイルのブロックは俺には必要だなと再認識した。
haskellでみた変態的コーディング表記も緩和されてわかりやすいスタイルになっている。
一部なんとなく気にくわない所もあるけど仕様上しかたないことなのかな?(arrow回り)
それと変数名が先にくるのは後で何かよいことあるの?
あとdefineじゃなくてdefならさー、objectじゃなくてobjくらいにしてくれたほうがいいなぁ。
と、c++もjavaもrubyもhaskellもMLもlispも全然できないvb6厨の俺が見た目だけで評価。
- 148 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 23:04:56 ]
- >>147
型宣言が後置で良いことがあるかと言えば、まあ好みの問題なんで
なんとも。ただ、一般論として型宣言が後置の方がパーザ書きやすくなるという
話はある。
- 149 名前：デフォルトの名無しさん mailto:sage [2008/04/05(土) 23:43:18 ]
- なんか、配列やマップ（ハッシュ）の参照も()なのが紛らわしい・・・
なんで同じにしたんだろ。
- 150 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 00:00:27 ]
- リテラルじゃなくてapplyで実装されてるからな
Rubyみたいに大クラス主義ならリテラルと相性が良いと思うが
Scalaの場合、Javaのものと合わせて大量にコレクションクラスがあるから、
リテラルの恩恵があまりないという判断なんだろうな
- 151 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 01:07:40 ]
- ツアーを読み始めてからjavaのよく分からない
機能(アノテーションとかジェネリック?)とかを調べ始めているうちに
まったく放置していたC#って言語が出てきて、これにも結構近いなぁ。
c# extends c++ interface 関数型言語,vm
に対して、
scala extends ruby,java,変態的言語
C++0xもおもしろそうだがまだvb6の総合的な簡潔さにはかなわない気がする。
- 152 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 02:56:08 ]
- >>149
genericsのために、既に[]は使っちゃってるからぶつかる
っていうのが主な理由じゃないかと
- 153 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 02:58:53 ]
- ところで、()使うのがそんなに紛らわしいかな？別に区別が付かない場面なんて
そうそう無いと思うんだが。あと、実用上のご利益として、関数引数を
要求してるとこに、配列やらMapをそのまま突っ込める、というのがある
val f : String => Int = Map("A" -> 1, "B" -> 2, "B" -> 3)
なんてのがＯＫなわけだ
- 154 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 04:06:22 ]
- これって知らなかったが、PartialFunctionを先祖で継承しているからなのか？
関数を継承してるコレクションって珍しいな
- 155 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 04:39:06 ]
- >>154
YES。
確かに、単に関数っぽい、じゃなくて、実際に関数として扱うことができるコレクションという
設計はあまり見かけない気がするね
- 156 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 07:38:00 ]
- >>149
Fortranと一緒だと思えばいい
- 157 名前：デフォルトの名無しさん mailto:sage [2008/04/06(日) 10:56:18 ]
- 〜.run()とか〜.invoke()じゃなくて〜()って出来る
こういうのが浸透してきたから、
コレクションの要素取得にも一般化したんでしょ。
- 158 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 14:41:16 ]
- 他に、関数と配列で同じ表記使う言語あったかなと思ったら、
BASICもそうだったなｗ
- 159 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 17:44:31 ]
- なんか、型推論があれば、
動的型付けなんかいらないみたいな事が書いてあったけど、
本当にそうなの？
- 160 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 18:07:32 ]
- >>159
動的型付けや型推論の定義によるけど
動的型と言っても結局実行時には何の型であるかを決めて変換しないと実行できないので
それをコンパイル時にやってるのが型推論ということだとすれば
実行時まで型がわからない状況以外は全部型推論で片付くことになる
ただ実行時まで型がわからない状況ってevalくらいしか思いつかないのだが・・・
- 161 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 19:50:51 ]
- 動的型付けだと、状況によって型が違う関数とかが発生するでしょ。
例えば Lisp 系なんて、何でも入るリストがデータ構造の基本なんで、多くの関数の型は引数とかに依存する。
型を決めて変換するってよりは、型に応じて分岐処理したりするような世界だから、推論は難しいと思うけど。
- 162 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 20:09:32 ]
- 型に応じて分岐処理ってポリモーフィズム？
- 163 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 20:11:42 ]
- >>161
何でも入るっていっても、本当に実際に何でもつっこむような使い方って
Lisp系でもそんなにしない気がするんだが、どうだろう。Lispのエキスパートじゃないので
自信があるわけじゃないけど。で、もしこれが真ならvariant(VBのじゃなくて、MLとかの
やつね。Scalaで言うとcase class)があれば大体事足りるのではないかと
- 164 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 20:40:31 ]
- >>159
「型推論」じゃなくて「強い型付け」の間違いですか?
- 165 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 20:50:26 ]
- Scala at Waves (SaW):
問題をガリガリ破壊していくフレームワークのような何か。白装束を着ないと自分も破壊される。
- 166 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 20:54:14 ]
- なんでgenericsに<>使わないの? Foo<Bar<Bazz>> ←ここの問題とかだったりしたら orz
{ブレース}使って見た目の「普通感」があるのはJavaneseに取ってもいいことだと思うんだけど、
それをメリットとして軽く触れられた後で<>が[]です、[]が()です、型は後置です、って言われても
やっぱり見慣れない感が。
理論的・技術的に問題ないのと、今までの目の慣れにやさしいかは別問題。
- 167 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:01:41 ]
- C++はC++0xで>>とくっつけて書いていいようになりました。
要するに文脈依存でlexer頑張れと。
- 168 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:07:30 ]
- >>167
lexerに文脈を表す状態を持たせる必要……この道はいつか来た道。 ←ruby/parse.y orz
- 169 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:11:48 ]
- <>でも[]でもどっちでもいいじゃん
- 170 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:24:44 ]
- {}でもdo..endでも でもどっちでもいいじゃん
- 171 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:34:19 ]
- それは{}でお願いします
- 172 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 22:14:10 ]
- >>166
Javaのgenericsにその問題はないから別の理由だろ
- 173 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 22:25:20 ]
- >>166
本当のところ、理由はわからんが、記号がかぶらん方が、パーザにとって
色々都合が良いという話はある。例えば、 A[B] Cという式があったとして、
これがA<B> Cだったら、記号表みないと、A < B > Cという式と区別つかんとか。
- 174 名前：デフォルトの名無しさん mailto:sage [2008/04/07(月) 22:29:23 ]
- >>173の例はミス。A[B] Cだとまずかった。書き直すと、
a.b[C](d)という式があったとして、これがa.b<C>(d)だったら、
記号表みないと、a.b < C > dという式と区別つかんとか。
- 175 名前：デフォルトの名無しさん mailto:sage [2008/04/08(火) 00:34:40 ]
- >>174は処理系実装と言語仕様の思考分離を(ry
|
 |
