1001コメント302KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2009/06/30(火) 00:36:11

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/

0002デフォルトの名無しさん

2009/06/30(火) 01:05:50

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

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

0003デフォルトの名無しさん

2009/06/30(火) 01:24:21

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

0004デフォルトの名無しさん

2009/06/30(火) 01:33:08

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

0005デフォルトの名無しさん

2009/06/30(火) 01:36:11

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

0006デフォルトの名無しさん

2009/06/30(火) 01:46:04

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

0007デフォルトの名無しさん

2009/06/30(火) 02:13:14

乙。

0008デフォルトの名無しさん

2009/06/30(火) 23:17:00

>>1乙

0009デフォルトの名無しさん

2009/07/01(水) 08:31:13

乙cala

0010デフォルトの名無しさん

2009/07/01(水) 20:14:49

>>1乙

0011デフォルトの名無しさん

2009/07/02(木) 22:56:45

>>1乙

0012デフォルトの名無しさん

2009/07/02(木) 23:24:33

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

0013デフォルトの名無しさん

2009/07/02(木) 23:54:43

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

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って何だよとか、ぱっと見で何が返ってくるかよくわからんようになってるのが
どうなんだろうと。

0014デフォルトの名無しさん

2009/07/03(金) 00:01:08

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

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

0015デフォルトの名無しさん

2009/07/03(金) 01:19:43

>>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だとか)が返ってくるようになってる。長文ですまん。

0016デフォルトの名無しさん

2009/07/03(金) 02:10:58

>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ドキュメント見た時に、返ってくる型が分かりにくすぎないか？　これ。

0017デフォルトの名無しさん

2009/07/03(金) 20:18:10

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

0018デフォルトの名無しさん

2009/07/03(金) 22:15:39

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

0019デフォルトの名無しさん

2009/07/03(金) 23:19:17

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

0020デフォルトの名無しさん

2009/07/04(土) 04:14:17

>>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ドキュメントだけから読み解くのは結構きついもの
があると思う。

0021デフォルトの名無しさん

2009/07/04(土) 08:01:31

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)

0022デフォルトの名無しさん

2009/07/04(土) 16:55:37

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

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

0023デフォルトの名無しさん

2009/07/04(土) 17:30:01

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

0024デフォルトの名無しさん

2009/07/04(土) 17:37:49

>>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)

0025デフォルトの名無しさん

2009/07/04(土) 17:42:45

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

0026デフォルトの名無しさん

2009/07/04(土) 17:45:55

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

0027デフォルトの名無しさん

2009/07/04(土) 18:49:02

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

0028デフォルトの名無しさん

2009/07/04(土) 19:25:28

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

0029デフォルトの名無しさん

2009/07/04(土) 21:33:10

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

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

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

0030デフォルトの名無しさん

2009/07/05(日) 02:16:02

>>28

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

0031デフォルトの名無しさん

2009/07/06(月) 04:44:18

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

ここはその通りだけど、

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

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

0032デフォルトの名無しさん

2009/07/08(水) 21:41:04

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作者からこういう言葉が
出てくるのは結構意外。

0033デフォルトの名無しさん

2009/07/08(水) 23:32:13

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

0034デフォルトの名無しさん

2009/07/09(木) 03:08:34

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

0035デフォルトの名無しさん

2009/07/16(木) 01:36:45

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

0036デフォルトの名無しさん

2009/07/16(木) 01:45:28

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

0037デフォルトの名無しさん

2009/07/16(木) 09:48:26

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

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

0038デフォルトの名無しさん

2009/07/16(木) 09:52:00

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

0039デフォルトの名無しさん

2009/07/16(木) 15:51:24

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

0040デフォルトの名無しさん

2009/07/17(金) 00:30:45

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

0041デフォルトの名無しさん

2009/07/17(金) 04:01:48

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

0042デフォルトの名無しさん

2009/07/17(金) 09:47:08

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

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

0043デフォルトの名無しさん

2009/07/17(金) 18:35:49

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

0044デフォルトの名無しさん

2009/07/19(日) 22:20:14

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

0045デフォルトの名無しさん

2009/07/19(日) 22:52:45

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

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

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

0046デフォルトの名無しさん

2009/07/19(日) 23:20:49

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

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

0047デフォルトの名無しさん

2009/07/20(月) 00:56:44

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

0048デフォルトの名無しさん

2009/07/20(月) 01:19:43

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

0049デフォルトの名無しさん

2009/07/20(月) 08:22:12

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

0050デフォルトの名無しさん

2009/07/20(月) 16:59:42

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

ってのはありがちだが。

0051デフォルトの名無しさん

2009/07/20(月) 19:15:59

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

0052デフォルトの名無しさん

2009/07/20(月) 20:58:13

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

0053デフォルトの名無しさん

2009/07/25(土) 04:01:19

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

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

0054デフォルトの名無しさん

2009/07/26(日) 11:24:12

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が正しい。

0055デフォルトの名無しさん

2009/07/27(月) 16:09:50

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

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

0056デフォルトの名無しさん

2009/07/27(月) 20:17:29

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

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

0057デフォルトの名無しさん

2009/07/27(月) 23:20:22

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

0058デフォルトの名無しさん

2009/07/28(火) 21:47:57

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

0059デフォルトの名無しさん

2009/07/29(水) 19:48:58

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

0060デフォルトの名無しさん

2009/07/29(水) 21:53:04

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

0061デフォルトの名無しさん

2009/08/06(木) 00:31:53

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

0062デフォルトの名無しさん

2009/08/06(木) 01:14:07

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

0063デフォルトの名無しさん

2009/08/06(木) 01:16:25

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

0064デフォルトの名無しさん

2009/08/06(木) 01:17:21

Scala＝Javaな人でOK?

0065デフォルトの名無しさん

2009/08/06(木) 01:22:20

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

0066デフォルトの名無しさん

2009/08/06(木) 02:19:17

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

0067デフォルトの名無しさん

2009/08/06(木) 08:05:25

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

0068デフォルトの名無しさん

2009/08/06(木) 08:27:12

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

0069デフォルトの名無しさん

2009/08/06(木) 08:31:21

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

0070デフォルトの名無しさん

2009/08/06(木) 09:25:39

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

0071デフォルトの名無しさん

2009/08/10(月) 18:59:06

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

0072デフォルトの名無しさん

2009/08/15(土) 21:05:10

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

Clojureのことだとおもた・・

0073デフォルトの名無しさん

2009/08/16(日) 18:27:58

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

0074デフォルトの名無しさん

2009/08/16(日) 18:28:49

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

0075デフォルトの名無しさん

2009/08/16(日) 18:31:37

HaskellとかRubyとか

0076デフォルトの名無しさん

2009/08/16(日) 18:33:23

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

0077デフォルトの名無しさん

2009/08/16(日) 18:46:03

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

0078デフォルトの名無しさん

2009/08/16(日) 19:34:17

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

0079デフォルトの名無しさん

2009/08/16(日) 19:50:42

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

0080デフォルトの名無しさん

2009/08/16(日) 20:08:59

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

0081デフォルトの名無しさん

2009/08/16(日) 20:28:01

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

0082デフォルトの名無しさん

2009/08/16(日) 22:20:21

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

0083デフォルトの名無しさん

2009/08/16(日) 22:41:53

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

0084デフォルトの名無しさん

2009/08/17(月) 01:03:00

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

0085デフォルトの名無しさん

2009/08/17(月) 18:50:40

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

0086デフォルトの名無しさん

2009/08/17(月) 19:21:25

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

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

0087デフォルトの名無しさん

2009/08/17(月) 19:44:40

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

0088デフォルトの名無しさん

2009/08/17(月) 19:50:27

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

0089デフォルトの名無しさん

2009/08/17(月) 20:00:50

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

0090デフォルトの名無しさん

2009/08/17(月) 20:04:19

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

0091デフォルトの名無しさん

2009/08/17(月) 22:22:44

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

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

0092デフォルトの名無しさん

2009/08/17(月) 22:29:49

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

0093デフォルトの名無しさん

2009/08/17(月) 22:58:23

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

0094デフォルトの名無しさん

2009/08/17(月) 23:50:19

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

0095デフォルトの名無しさん

2009/08/17(月) 23:58:37

破れそうで怖いな

0096デフォルトの名無しさん

2009/08/18(火) 00:55:11

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

0097デフォルトの名無しさん

2009/08/19(水) 02:05:56

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

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

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

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

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

009897

2009/08/19(水) 02:52:52

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

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

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

0099デフォルトの名無しさん

2009/08/19(水) 16:50:18

>>96
良いの？嫌なの？

010093

2009/08/19(水) 20:00:29

>>98
もうかじったよw

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

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

0101デフォルトの名無しさん

2009/08/19(水) 23:28:03

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

0102デフォルトの名無しさん

2009/08/20(木) 22:38:50

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

0103デフォルトの名無しさん

2009/08/20(木) 23:46:08

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

0104デフォルトの名無しさん

2009/08/21(金) 06:17:12

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

0105デフォルトの名無しさん

2009/08/21(金) 12:01:37

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

0106デフォルトの名無しさん

2009/08/21(金) 12:52:51

買ってみたくなった

0107デフォルトの名無しさん

2009/08/21(金) 19:34:22

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

0108デフォルトの名無しさん

2009/08/21(金) 19:47:45

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

0109デフォルトの名無しさん

2009/08/21(金) 20:15:13

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

0110デフォルトの名無しさん

2009/08/21(金) 21:19:08

紙質がいまいち

0111デフォルトの名無しさん

2009/08/21(金) 21:54:49

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

0112デフォルトの名無しさん

2009/08/21(金) 22:09:56

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

0113デフォルトの名無しさん

2009/08/21(金) 22:18:00

薄くても安心

0114デフォルトの名無しさん

2009/08/21(金) 22:45:28

ページが多い日も安心

0115デフォルトの名無しさん

2009/08/21(金) 22:54:52

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

0116デフォルトの名無しさん

2009/08/21(金) 23:14:24

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

0117107

2009/08/22(土) 10:03:40

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

0118デフォルトの名無しさん

2009/08/22(土) 11:41:55

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

0119デフォルトの名無しさん

2009/08/22(土) 12:12:46

PDF(笑)

0120デフォルトの名無しさん

2009/08/22(土) 12:37:44

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

0121デフォルトの名無しさん

2009/08/22(土) 12:43:24

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

0122デフォルトの名無しさん

2009/08/22(土) 16:57:05

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

0123デフォルトの名無しさん

2009/08/22(土) 19:43:03

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

0124デフォルトの名無しさん

2009/08/22(土) 20:04:52

訳が悪いとか？

0125デフォルトの名無しさん

2009/08/22(土) 20:11:07

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

0126デフォルトの名無しさん

2009/08/22(土) 20:14:31

やはり紙か

0127デフォルトの名無しさん

2009/08/22(土) 21:00:43

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

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

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

0128デフォルトの名無しさん

2009/08/22(土) 21:11:59

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

0129デフォルトの名無しさん

2009/08/22(土) 21:40:38

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

0130デフォルトの名無しさん

2009/08/22(土) 21:53:21

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

0131デフォルトの名無しさん

2009/08/22(土) 22:08:07

Javaはいかんだろ

0132デフォルトの名無しさん

2009/08/22(土) 22:14:53

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

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

0133デフォルトの名無しさん

2009/08/22(土) 22:25:15

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

0134デフォルトの名無しさん

2009/08/22(土) 22:26:52

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

0135デフォルトの名無しさん

2009/08/22(土) 22:46:32

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

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

0136デフォルトの名無しさん

2009/08/22(土) 22:52:42

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

0137デフォルトの名無しさん

2009/08/22(土) 23:59:31

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

0138デフォルトの名無しさん

2009/08/23(日) 00:05:45

>>137
矢印逆じゃね？

0139デフォルトの名無しさん

2009/08/23(日) 16:04:37

∈

0140デフォルトの名無しさん

2009/08/23(日) 19:27:05

矢印逆だった

0141デフォルトの名無しさん

2009/08/25(火) 00:49:33

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

0142デフォルトの名無しさん

2009/08/25(火) 07:27:03

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

0143デフォルトの名無しさん

2009/08/25(火) 07:35:01

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

0144デフォルトの名無しさん

2009/08/25(火) 08:58:08

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

0145デフォルトの名無しさん

2009/08/25(火) 10:45:00

>>141
デブ元理事？

0146デフォルトの名無しさん

2009/08/25(火) 11:50:45

>>141
うざい

0147デフォルトの名無しさん

2009/08/25(火) 12:23:42

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

0148デフォルトの名無しさん

2009/08/25(火) 14:50:06

ここにもネイティブ厨が

0149デフォルトの名無しさん

2009/08/25(火) 23:24:33

>>141
賛同します。

0150デフォルトの名無しさん

2009/08/25(火) 23:36:38

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

チャンチャン

0151デフォルトの名無しさん

2009/08/26(水) 01:47:03

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

0152デフォルトの名無しさん

2009/08/26(水) 04:56:44

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

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

0153デフォルトの名無しさん

2009/08/26(水) 23:52:24

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

0154デフォルトの名無しさん

2009/08/27(木) 00:12:44

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

0155デフォルトの名無しさん

2009/08/27(木) 23:33:52

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

0156デフォルトの名無しさん

2009/08/28(金) 00:01:36

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

0157デフォルトの名無しさん

2009/08/28(金) 00:05:16

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

のあたり

0158デフォルトの名無しさん

2009/08/28(金) 00:26:04

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

0159デフォルトの名無しさん

2009/08/28(金) 01:08:37

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

0160デフォルトの名無しさん

2009/08/28(金) 01:10:29

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

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

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

0161デフォルトの名無しさん

2009/08/28(金) 01:27:29

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

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

0162デフォルトの名無しさん

2009/08/28(金) 07:22:37

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

0163デフォルトの名無しさん

2009/08/28(金) 08:40:58

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

0164デフォルトの名無しさん

2009/08/28(金) 08:43:22

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

0165デフォルトの名無しさん

2009/08/28(金) 12:28:02

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

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

0166デフォルトの名無しさん

2009/08/28(金) 20:21:35

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

0167デフォルトの名無しさん

2009/08/28(金) 20:50:01

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

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

0168デフォルトの名無しさん

2009/08/28(金) 21:17:05

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

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という変数に関数オブジェクトが代入されて実行されるだけだ

0169デフォルトの名無しさん

2009/08/28(金) 21:30:05

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

0170デフォルトの名無しさん

2009/08/28(金) 21:44:12

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

0171デフォルトの名無しさん

2009/08/28(金) 21:53:25

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

0172デフォルトの名無しさん

2009/08/28(金) 22:00:25

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

0173デフォルトの名無しさん

2009/08/28(金) 22:39:51

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

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

0174デフォルトの名無しさん

2009/08/28(金) 22:45:28

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

0175デフォルトの名無しさん

2009/08/28(金) 22:55:17

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

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

0176デフォルトの名無しさん

2009/08/28(金) 22:58:48

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

0177デフォルトの名無しさん

2009/08/28(金) 23:04:29

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

0178デフォルトの名無しさん

2009/08/28(金) 23:11:48

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

0179デフォルトの名無しさん

2009/08/28(金) 23:18:04

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

0180デフォルトの名無しさん

2009/08/28(金) 23:20:48

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

0181デフォルトの名無しさん

2009/08/28(金) 23:30:48

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

0182デフォルトの名無しさん

2009/08/28(金) 23:32:06

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

0183デフォルトの名無しさん

2009/08/28(金) 23:32:53

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

0184デフォルトの名無しさん

2009/08/28(金) 23:36:06

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

0185デフォルトの名無しさん

2009/08/28(金) 23:39:31

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

0186デフォルトの名無しさん

2009/08/28(金) 23:41:28

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

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

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

0187デフォルトの名無しさん

2009/08/28(金) 23:41:45

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

0188デフォルトの名無しさん

2009/08/28(金) 23:53:01

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

0189デフォルトの名無しさん

2009/08/29(土) 00:11:54

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

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

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

0190デフォルトの名無しさん

2009/08/29(土) 00:17:31

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

0191デフォルトの名無しさん

2009/08/29(土) 00:22:56

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

0192デフォルトの名無しさん

2009/08/29(土) 00:32:30

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

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

0193デフォルトの名無しさん

2009/08/29(土) 00:42:17

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

0194デフォルトの名無しさん

2009/08/29(土) 06:44:39

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

0195デフォルトの名無しさん

2009/08/29(土) 10:55:21

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

0196デフォルトの名無しさん

2009/08/29(土) 11:12:23

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

0197デフォルトの名無しさん

2009/08/29(土) 20:06:28

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

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

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

0198デフォルトの名無しさん

2009/08/29(土) 20:55:20

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

0199デフォルトの名無しさん

2009/08/29(土) 21:04:54

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

0200デフォルトの名無しさん

2009/08/29(土) 21:13:20

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

0201デフォルトの名無しさん

2009/08/29(土) 22:48:08

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

0202デフォルトの名無しさん

2009/08/29(土) 23:37:07

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

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

0203デフォルトの名無しさん

2009/08/29(土) 23:57:39

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

0204デフォルトの名無しさん

2009/08/30(日) 00:19:23

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

0205デフォルトの名無しさん

2009/08/30(日) 00:21:33

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

0206デフォルトの名無しさん

2009/08/30(日) 00:43:41

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

0207名無しさん＠そうだ選挙に行こう

2009/08/30(日) 19:23:33

引数に

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

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

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

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

0208デフォルトの名無しさん

2009/08/30(日) 20:18:53

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

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

0209デフォルトの名無しさん

2009/08/30(日) 20:22:24

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

0210デフォルトの名無しさん

2009/08/30(日) 20:41:02

>>208
そうなんですかぁ

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

0211デフォルトの名無しさん

2009/08/30(日) 21:02:53

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

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

0212デフォルトの名無しさん

2009/08/30(日) 21:42:50

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

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

0213デフォルトの名無しさん

2009/08/30(日) 22:04:43

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

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

0214デフォルトの名無しさん

2009/08/30(日) 22:13:52

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

0215デフォルトの名無しさん

2009/08/30(日) 22:17:09

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

0216デフォルトの名無しさん

2009/08/30(日) 22:18:30

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

0217デフォルトの名無しさん

2009/08/30(日) 22:26:48

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

0218デフォルトの名無しさん

2009/08/30(日) 23:20:37

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

0219デフォルトの名無しさん

2009/08/31(月) 00:04:09

計算可能性とラムダ計算と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)
}
}

0220デフォルトの名無しさん

2009/08/31(月) 01:03:43

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

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

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

0221デフォルトの名無しさん

2009/08/31(月) 06:42:01

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

0222デフォルトの名無しさん

2009/08/31(月) 10:46:06

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

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

0223デフォルトの名無しさん

2009/08/31(月) 10:53:45

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

0224デフォルトの名無しさん

2009/08/31(月) 20:02:25

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

0225デフォルトの名無しさん

2009/08/31(月) 23:05:08

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

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

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

0226デフォルトの名無しさん

2009/08/31(月) 23:31:21

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

0227デフォルトの名無しさん

2009/08/31(月) 23:38:29

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

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

0228デフォルトの名無しさん

2009/09/01(火) 00:41:31

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

0229デフォルトの名無しさん

2009/09/06(日) 13:24:57

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

0230デフォルトの名無しさん

2009/09/06(日) 15:26:06

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

0231デフォルトの名無しさん

2009/09/06(日) 22:32:33

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

0232デフォルトの名無しさん

2009/09/06(日) 22:58:23

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

0233デフォルトの名無しさん

2009/09/07(月) 00:02:11

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

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

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

0234デフォルトの名無しさん

2009/09/07(月) 09:35:02

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

0235デフォルトの名無しさん

2009/09/07(月) 19:25:05

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

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

0236デフォルトの名無しさん

2009/09/07(月) 20:45:52

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

0237デフォルトの名無しさん

2009/09/07(月) 23:34:41

def f : hoge =

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

0238デフォルトの名無しさん

2009/09/08(火) 00:49:21

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

0239デフォルトの名無しさん

2009/09/10(木) 02:24:58

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

0240デフォルトの名無しさん

2009/09/10(木) 02:59:52

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

0241デフォルトの名無しさん

2009/09/10(木) 13:32:10

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

0242デフォルトの名無しさん

2009/09/10(木) 13:42:01

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

0243デフォルトの名無しさん

2009/09/10(木) 22:23:18

0244デフォルトの名無しさん

2009/09/10(木) 22:56:52

なんか書けよ

0245デフォルトの名無しさん

2009/09/10(木) 23:42:50

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

0246デフォルトの名無しさん

2009/09/11(金) 00:23:25

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

0247デフォルトの名無しさん

2009/09/11(金) 00:37:51

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

0248デフォルトの名無しさん

2009/09/11(金) 00:51:57

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

0249デフォルトの名無しさん

2009/09/11(金) 05:41:24

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

0250デフォルトの名無しさん

2009/09/11(金) 10:23:33

ttp://wiki.netbeans.org/ScalaIssues

0251デフォルトの名無しさん

2009/09/11(金) 19:19:18

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

0252デフォルトの名無しさん

2009/09/12(土) 23:35:38

>>250
つ最終更新日時

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

0253デフォルトの名無しさん

2009/09/15(火) 18:33:38

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

0254デフォルトの名無しさん

2009/09/15(火) 20:27:44

読みが当たったか

0255デフォルトの名無しさん

2009/09/15(火) 22:14:06

エスパーいくない

0256デフォルトの名無しさん

2009/09/16(水) 23:15:44

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

0257デフォルトの名無しさん

2009/09/16(水) 23:28:42

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

0258デフォルトの名無しさん

2009/09/16(水) 23:37:40

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

0259デフォルトの名無しさん

2009/09/17(木) 00:07:40

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

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

使い分ければいいの？

0260デフォルトの名無しさん

2009/09/17(木) 00:11:04

使い分けはできない

0261デフォルトの名無しさん

2009/09/17(木) 00:11:38

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

0262デフォルトの名無しさん

2009/09/17(木) 01:39:01

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

0263デフォルトの名無しさん

2009/09/17(木) 01:40:47

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

0264デフォルトの名無しさん

2009/09/17(木) 01:47:36

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

0265デフォルトの名無しさん

2009/09/19(土) 14:40:56

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

0266デフォルトの名無しさん

2009/09/19(土) 15:31:41

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

0267デフォルトの名無しさん

2009/09/19(土) 15:44:34

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

0268デフォルトの名無しさん

2009/09/19(土) 17:15:51

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

0269デフォルトの名無しさん

2009/09/19(土) 18:31:05

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

0270デフォルトの名無しさん

2009/09/19(土) 18:33:17

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

0271デフォルトの名無しさん

2009/09/19(土) 21:44:39

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

0272デフォルトの名無しさん

2009/09/19(土) 21:46:27

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

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

0273デフォルトの名無しさん

2009/09/19(土) 22:48:04

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

0274デフォルトの名無しさん

2009/09/20(日) 00:43:03

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

0275デフォルトの名無しさん

2009/09/20(日) 01:22:59

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

0276デフォルトの名無しさん

2009/09/20(日) 01:26:11

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

0277デフォルトの名無しさん

2009/09/20(日) 01:39:39

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

0278デフォルトの名無しさん

2009/09/20(日) 22:09:28

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

0279デフォルトの名無しさん

2009/09/20(日) 23:14:02

JavaScriptのE4Xより先？

0280デフォルトの名無しさん

2009/09/20(日) 23:51:08

少なくともHaskellよりは先

0281デフォルトの名無しさん

2009/09/21(月) 02:58:06

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

0282デフォルトの名無しさん

2009/09/21(月) 03:59:47

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

0283デフォルトの名無しさん

2009/09/21(月) 17:24:50

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

0284デフォルトの名無しさん

2009/09/21(月) 17:29:17

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

0285デフォルトの名無しさん

2009/09/21(月) 18:46:02

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

0286デフォルトの名無しさん

2009/09/21(月) 19:18:15

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

0287デフォルトの名無しさん

2009/09/21(月) 19:26:14

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

0288デフォルトの名無しさん

2009/09/21(月) 19:30:52

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

0289デフォルトの名無しさん

2009/09/21(月) 22:34:18

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

0290デフォルトの名無しさん

2009/09/22(火) 01:22:22

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

0291デフォルトの名無しさん

2009/09/22(火) 01:37:42

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

0292デフォルトの名無しさん

2009/09/22(火) 01:42:19

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

0293デフォルトの名無しさん

2009/09/22(火) 01:44:38

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

0294デフォルトの名無しさん

2009/09/22(火) 02:19:47

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

0295デフォルトの名無しさん

2009/09/22(火) 02:35:14

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

0296デフォルトの名無しさん

2009/09/22(火) 03:24:05

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

0297デフォルトの名無しさん

2009/09/22(火) 03:28:14

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

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

0298デフォルトの名無しさん

2009/09/22(火) 03:39:06

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

0299デフォルトの名無しさん

2009/09/22(火) 03:43:28

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

0300デフォルトの名無しさん

2009/09/22(火) 03:51:07

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

0301デフォルトの名無しさん

2009/09/22(火) 03:52:34

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

0302デフォルトの名無しさん

2009/09/22(火) 04:12:49

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

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

0303デフォルトの名無しさん

2009/09/22(火) 08:20:54

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

0304デフォルトの名無しさん

2009/09/22(火) 08:41:48

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

0305デフォルトの名無しさん

2009/09/22(火) 10:19:24

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

0306デフォルトの名無しさん

2009/09/22(火) 11:35:30

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

0307デフォルトの名無しさん

2009/09/22(火) 11:40:12

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

0308デフォルトの名無しさん

2009/09/22(火) 11:45:59

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

0309デフォルトの名無しさん

2009/09/22(火) 11:51:07

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

開発者はアホだよな

0310デフォルトの名無しさん

2009/09/22(火) 11:52:30

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

0311デフォルトの名無しさん

2009/09/22(火) 11:53:50

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

0312デフォルトの名無しさん

2009/09/22(火) 12:08:48

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

0313デフォルトの名無しさん

2009/09/22(火) 12:17:56

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

0314デフォルトの名無しさん

2009/09/22(火) 12:23:40

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

0315デフォルトの名無しさん

2009/09/22(火) 12:34:22

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

0316デフォルトの名無しさん

2009/09/22(火) 12:42:59

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

0317デフォルトの名無しさん

2009/09/22(火) 12:46:56

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

0318デフォルトの名無しさん

2009/09/22(火) 12:49:44

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

0319デフォルトの名無しさん

2009/09/22(火) 12:51:22

>310
Liftで結構使ってる。

0320デフォルトの名無しさん

2009/09/22(火) 12:52:34

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

0321デフォルトの名無しさん

2009/09/22(火) 12:56:07

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

0322デフォルトの名無しさん

2009/09/22(火) 12:57:22

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

0323デフォルトの名無しさん

2009/09/22(火) 12:59:15

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

0324デフォルトの名無しさん

2009/09/22(火) 12:59:16

scala最悪だな

0325デフォルトの名無しさん

2009/09/22(火) 13:02:09

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

0326デフォルトの名無しさん

2009/09/22(火) 13:03:14

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

0327デフォルトの名無しさん

2009/09/22(火) 13:13:17

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

0328デフォルトの名無しさん

2009/09/22(火) 13:16:11

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

0329デフォルトの名無しさん

2009/09/22(火) 13:25:36

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

0330デフォルトの名無しさん

2009/09/22(火) 13:29:39

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

0331デフォルトの名無しさん

2009/09/22(火) 13:33:07

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

0332デフォルトの名無しさん

2009/09/22(火) 13:35:36

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

0333デフォルトの名無しさん

2009/09/22(火) 13:42:49

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

0334デフォルトの名無しさん

2009/09/22(火) 13:59:37

┐(´д｀)┌ﾔﾚﾔﾚ

0335デフォルトの名無しさん

2009/09/22(火) 14:22:11

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

0336デフォルトの名無しさん

2009/09/22(火) 15:31:09

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

0337デフォルトの名無しさん

2009/09/22(火) 16:18:39

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

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

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

0338デフォルトの名無しさん

2009/09/22(火) 16:29:50

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

0339デフォルトの名無しさん

2009/09/22(火) 16:55:37

>>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. の情報を展開時に利用するのがだるいかもしれない。

0340デフォルトの名無しさん

2009/09/22(火) 22:22:39

>>338
マレーバクです。

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

0341デフォルトの名無しさん

2009/09/22(火) 23:47:19

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

0342デフォルトの名無しさん

2009/09/23(水) 00:04:54

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

0343デフォルトの名無しさん

2009/09/23(水) 00:06:32

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

0344デフォルトの名無しさん

2009/09/23(水) 00:07:45

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

0345デフォルトの名無しさん

2009/09/23(水) 00:13:48

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

0346デフォルトの名無しさん

2009/09/23(水) 00:15:39

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

0347デフォルトの名無しさん

2009/09/23(水) 00:21:28

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

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

0348デフォルトの名無しさん

2009/09/23(水) 00:22:22

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

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

0349デフォルトの名無しさん

2009/09/23(水) 00:25:57

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

0350デフォルトの名無しさん

2009/09/23(水) 00:31:07

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

0351デフォルトの名無しさん

2009/09/23(水) 00:34:34

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

0352デフォルトの名無しさん

2009/09/23(水) 00:35:18

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

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

0353デフォルトの名無しさん

2009/09/23(水) 00:36:35

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

0354デフォルトの名無しさん

2009/09/23(水) 00:37:11

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

0355デフォルトの名無しさん

2009/09/23(水) 00:39:23

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

0356デフォルトの名無しさん

2009/09/23(水) 00:40:26

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

0357デフォルトの名無しさん

2009/09/23(水) 00:40:30

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

0358デフォルトの名無しさん

2009/09/23(水) 00:41:42

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

0359デフォルトの名無しさん

2009/09/23(水) 00:42:21

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

0360デフォルトの名無しさん

2009/09/23(水) 00:43:27

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

0361デフォルトの名無しさん

2009/09/23(水) 00:48:47

>>351
またお前か・・・

0362デフォルトの名無しさん

2009/09/23(水) 00:49:41

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

0363デフォルトの名無しさん

2009/09/23(水) 01:20:13

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

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

ついに来ました。

大きい動きです。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/

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

0364デフォルトの名無しさん

2009/09/23(水) 21:46:53

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

0365デフォルトの名無しさん

2009/09/23(水) 22:10:43

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

0366デフォルトの名無しさん

2009/09/23(水) 22:14:10

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

0367デフォルトの名無しさん

2009/09/23(水) 22:25:46

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

0368デフォルトの名無しさん

2009/09/24(木) 00:01:20

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

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

0369デフォルトの名無しさん

2009/09/24(木) 02:17:04

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

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

0370デフォルトの名無しさん

2009/09/24(木) 07:47:43

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

0371デフォルトの名無しさん

2009/09/24(木) 11:05:53

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

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

0372デフォルトの名無しさん

2009/09/24(木) 11:30:37

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

0373デフォルトの名無しさん

2009/09/24(木) 16:12:36

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

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

0374デフォルトの名無しさん

2009/09/24(木) 19:20:04

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

0375デフォルトの名無しさん

2009/09/24(木) 19:28:43

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

0376デフォルトの名無しさん

2009/09/24(木) 20:58:03

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

0377372

2009/09/24(木) 23:07:45

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

0378デフォルトの名無しさん

2009/09/24(木) 23:41:24

>>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)
　}
　...
}

0379デフォルトの名無しさん

2009/09/25(金) 00:32:43

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

0380デフォルトの名無しさん

2009/09/25(金) 00:42:03

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

0381デフォルトの名無しさん

2009/09/25(金) 04:11:35

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]

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

0382デフォルトの名無しさん

2009/09/25(金) 09:45:57

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

0383デフォルトの名無しさん

2009/09/25(金) 09:46:06

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

0384デフォルトの名無しさん

2009/09/25(金) 10:26:51

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

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

0385デフォルトの名無しさん

2009/09/25(金) 17:25:20

>>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が使われてるね。これは、型パラメータが
あちこちに引き回されることを考慮してのことだと思う。

0386デフォルトの名無しさん

2009/09/25(金) 17:28:28

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

0387デフォルトの名無しさん

2009/09/25(金) 21:05:19

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

0388デフォルトの名無しさん

2009/09/25(金) 21:13:08

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

0389デフォルトの名無しさん

2009/09/25(金) 22:52:52

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

0390デフォルトの名無しさん

2009/09/27(日) 23:47:13

scalaのparser combinatorで

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

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

0391デフォルトの名無しさん

2009/09/29(火) 00:55:22

(x :: y) mkString ""

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

0392デフォルトの名無しさん

2009/09/29(火) 01:09:57

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

0393デフォルトの名無しさん

2009/09/29(火) 01:54:16

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

0394デフォルトの名無しさん

2009/09/29(火) 09:46:29

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

0395デフォルトの名無しさん

2009/09/29(火) 20:21:19

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

0396デフォルトの名無しさん

2009/09/29(火) 20:23:41

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

0397デフォルトの名無しさん

2009/09/29(火) 21:26:54

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

0398デフォルトの名無しさん

2009/09/29(火) 21:52:45

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

0399デフォルトの名無しさん

2009/09/30(水) 01:46:10

2445.544Dを解析すろとき

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

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

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

0400デフォルトの名無しさん

2009/09/30(水) 22:57:03

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

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

0401デフォルトの名無しさん

2009/09/30(水) 23:27:02

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

0402デフォルトの名無しさん

2009/10/01(木) 00:32:40

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

0403デフォルトの名無しさん

2009/10/01(木) 00:45:48

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

0404デフォルトの名無しさん

2009/10/01(木) 00:54:57

>>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)

0405デフォルトの名無しさん

2009/10/01(木) 01:35:29

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

0406デフォルトの名無しさん

2009/10/01(木) 14:52:17

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

0407デフォルトの名無しさん

2009/10/03(土) 19:49:50

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

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

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

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

0408デフォルトの名無しさん

2009/10/04(日) 03:23:33

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

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

0409デフォルトの名無しさん

2009/10/04(日) 03:28:49

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

0410デフォルトの名無しさん

2009/10/04(日) 12:26:59

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

0411デフォルトの名無しさん

2009/10/04(日) 12:28:03

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

0412デフォルトの名無しさん

2009/10/04(日) 12:29:15

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

0413デフォルトの名無しさん

2009/10/04(日) 20:18:00

なんでJavaTokenParsersって

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

StdLexicalだとエラーになるのに

0414デフォルトの名無しさん

2009/10/04(日) 21:26:26

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

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

0415デフォルトの名無しさん

2009/10/04(日) 21:56:17

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

0416デフォルトの名無しさん

2009/10/04(日) 21:58:54

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

0417デフォルトの名無しさん

2009/10/04(日) 22:07:35

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

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

0418デフォルトの名無しさん

2009/10/05(月) 06:06:39

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

0419デフォルトの名無しさん

2009/10/05(月) 22:21:22

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

0420デフォルトの名無しさん

2009/10/05(月) 22:30:30

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

0421デフォルトの名無しさん

2009/10/06(火) 02:41:44

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

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

0422デフォルトの名無しさん

2009/10/06(火) 07:19:19

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

0423デフォルトの名無しさん

2009/10/06(火) 09:22:11

丸ごとの持ち上げ。

0424デフォルトの名無しさん

2009/10/06(火) 22:31:24

2.7.7 RC1

0425デフォルトの名無しさん

2009/10/06(火) 22:47:18

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

0426デフォルトの名無しさん

2009/10/07(水) 09:48:22

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

0427デフォルトの名無しさん

2009/10/07(水) 11:49:15

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

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

0428デフォルトの名無しさん

2009/10/09(金) 10:47:13

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

0429デフォルトの名無しさん

2009/10/14(水) 19:19:41

質問です。

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

0430デフォルトの名無しさん

2009/10/14(水) 20:45:11

>Javaとかだったら

Javaだぜ！

0431デフォルトの名無しさん

2009/10/14(水) 21:58:16

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

0432429

2009/10/14(水) 22:35:39

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

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

0433429

2009/10/14(水) 22:45:09

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

0434デフォルトの名無しさん

2009/10/15(木) 01:15:40

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

0435デフォルトの名無しさん

2009/10/15(木) 01:19:10

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

0436デフォルトの名無しさん

2009/10/15(木) 01:24:18

>>434
OCaml……。

0437デフォルトの名無しさん

2009/10/15(木) 01:58:43

>>434
F#

0438デフォルトの名無しさん

2009/10/15(木) 07:05:38

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

0439デフォルトの名無しさん

2009/10/15(木) 07:32:44

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

0440デフォルトの名無しさん

2009/10/15(木) 07:52:02

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

0441デフォルトの名無しさん

2009/10/15(木) 10:30:38

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

0442デフォルトの名無しさん

2009/10/15(木) 11:54:06

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

0443デフォルトの名無しさん

2009/10/15(木) 12:07:56

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

0444デフォルトの名無しさん

2009/10/15(木) 12:09:07

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

0445デフォルトの名無しさん

2009/10/16(金) 00:00:35

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

0446デフォルトの名無しさん

2009/10/16(金) 00:16:33

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

0447デフォルトの名無しさん

2009/10/16(金) 00:18:55

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

0448デフォルトの名無しさん

2009/10/16(金) 01:21:52

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

0449デフォルトの名無しさん

2009/10/16(金) 01:26:26

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

0450デフォルトの名無しさん

2009/10/16(金) 01:30:44

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

0451デフォルトの名無しさん

2009/10/16(金) 08:08:07

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

0452デフォルトの名無しさん

2009/10/16(金) 08:24:00

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

0453デフォルトの名無しさん

2009/10/16(金) 11:48:00

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

0454デフォルトの名無しさん

2009/10/16(金) 11:53:34

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

0455デフォルトの名無しさん

2009/10/16(金) 16:13:49

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

0456デフォルトの名無しさん

2009/10/16(金) 18:00:22

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

0457デフォルトの名無しさん

2009/10/16(金) 20:13:36

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

0458デフォルトの名無しさん

2009/10/16(金) 20:19:38

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

0459デフォルトの名無しさん

2009/10/16(金) 20:26:34

辞めていいよ

0460デフォルトの名無しさん

2009/10/17(土) 18:29:05

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

0461デフォルトの名無しさん

2009/10/18(日) 15:24:54

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

0462デフォルトの名無しさん

2009/10/18(日) 16:40:13

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

0463460

2009/10/19(月) 04:38:50

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

0464デフォルトの名無しさん

2009/10/19(月) 08:14:08

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

0465デフォルトの名無しさん

2009/10/19(月) 10:10:01

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

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

0466デフォルトの名無しさん

2009/10/20(火) 00:47:19

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

0467460

2009/10/20(火) 09:09:26

返信ありがとう。

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

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

0468465

2009/10/20(火) 11:01:39

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

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

0469デフォルトの名無しさん

2009/10/20(火) 21:30:34

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

0470デフォルトの名無しさん

2009/10/20(火) 22:46:28

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

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

0471デフォルトの名無しさん

2009/10/20(火) 22:52:56

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

0472デフォルトの名無しさん

2009/10/20(火) 22:54:34

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

0473デフォルトの名無しさん

2009/10/20(火) 23:00:53

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

0474デフォルトの名無しさん

2009/10/20(火) 23:04:00

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

0475デフォルトの名無しさん

2009/10/20(火) 23:14:42

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

0476デフォルトの名無しさん

2009/10/20(火) 23:42:57

その通りだっぽ！

0477デフォルトの名無しさん

2009/10/21(水) 00:16:58

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

0478デフォルトの名無しさん

2009/10/21(水) 10:03:31

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

0479デフォルトの名無しさん

2009/10/21(水) 10:23:42

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

0480デフォルトの名無しさん

2009/10/21(水) 12:44:52

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

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

0481デフォルトの名無しさん

2009/10/21(水) 14:04:14

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

0482デフォルトの名無しさん

2009/10/21(水) 16:35:05

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

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

0483デフォルトの名無しさん

2009/10/22(木) 00:07:03

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

0484デフォルトの名無しさん

2009/10/22(木) 00:27:41

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

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

0485デフォルトの名無しさん

2009/10/22(木) 00:53:31

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

0486デフォルトの名無しさん

2009/10/22(木) 00:56:15

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

0487デフォルトの名無しさん

2009/10/22(木) 00:57:59

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

0488デフォルトの名無しさん

2009/10/22(木) 01:02:26

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

0489デフォルトの名無しさん

2009/10/22(木) 01:12:07

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

0490デフォルトの名無しさん

2009/10/22(木) 01:17:39

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

0491デフォルトの名無しさん

2009/10/22(木) 02:13:56

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

0492デフォルトの名無しさん

2009/10/22(木) 02:16:28

>>484
one is manyですか

0493デフォルトの名無しさん

2009/10/22(木) 02:22:23

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

0494デフォルトの名無しさん

2009/10/22(木) 02:31:25

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

0495デフォルトの名無しさん

2009/10/22(木) 02:35:39

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

0496デフォルトの名無しさん

2009/10/22(木) 02:37:55

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

0497デフォルトの名無しさん

2009/10/22(木) 02:44:29

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

0498デフォルトの名無しさん

2009/10/22(木) 03:22:09

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

0499498

2009/10/22(木) 03:24:45

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

0500デフォルトの名無しさん

2009/10/22(木) 03:36:47

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

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

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

0501デフォルトの名無しさん

2009/10/22(木) 06:17:11

<< 代替 >>

× だいがえ
○ だいたい

0502デフォルトの名無しさん

2009/10/22(木) 06:21:18

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

0503デフォルトの名無しさん

2009/10/22(木) 07:41:45

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

0504465

2009/10/22(木) 10:09:18

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

0505デフォルトの名無しさん

2009/10/22(木) 10:19:26

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

0506デフォルトの名無しさん

2009/10/22(木) 10:43:52

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

0507465

2009/10/22(木) 10:59:20

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

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

0508デフォルトの名無しさん

2009/10/23(金) 00:33:06

>>470

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

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

0509デフォルトの名無しさん

2009/10/23(金) 00:35:11

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

0510デフォルトの名無しさん

2009/10/23(金) 00:53:11

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

0511デフォルトの名無しさん

2009/10/23(金) 16:00:18

2.7.7 RC2

0512デフォルトの名無しさん

2009/10/25(日) 08:24:54

>>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()
}

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

0513デフォルトの名無しさん

2009/10/26(月) 21:12:55

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

0514デフォルトの名無しさん

2009/10/26(月) 23:44:50

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

0515デフォルトの名無しさん

2009/10/27(火) 20:34:00

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

0516デフォルトの名無しさん

2009/10/29(木) 15:03:16

Scala 2.7.7 final

0517デフォルトの名無しさん

2009/10/31(土) 14:09:09

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

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

0518デフォルトの名無しさん

2009/10/31(土) 16:25:06

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

0519デフォルトの名無しさん

2009/10/31(土) 17:40:01

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

0520デフォルトの名無しさん

2009/11/02(月) 22:36:13

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

0521デフォルトの名無しさん

2009/11/03(火) 11:49:19

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

0522デフォルトの名無しさん

2009/11/03(火) 12:06:16

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

0523デフォルトの名無しさん

2009/11/03(火) 12:16:08

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

0524デフォルトの名無しさん

2009/11/03(火) 12:19:45

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

0525デフォルトの名無しさん

2009/11/03(火) 12:34:44

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

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

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

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

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

0526デフォルトの名無しさん

2009/11/03(火) 12:38:09

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

0527デフォルトの名無しさん

2009/11/03(火) 13:02:23

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

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

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

0528デフォルトの名無しさん

2009/11/03(火) 13:06:26

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

0529デフォルトの名無しさん

2009/11/03(火) 13:07:12

×filterMap
○flatMap

0530デフォルトの名無しさん

2009/11/03(火) 13:13:31

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

0531デフォルトの名無しさん

2009/11/03(火) 17:02:18

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

0532デフォルトの名無しさん

2009/11/03(火) 22:54:08

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

0533デフォルトの名無しさん

2009/11/05(木) 12:12:15

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

0534デフォルトの名無しさん

2009/11/05(木) 23:09:07

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

0535デフォルトの名無しさん

2009/11/05(木) 23:56:08

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

0536デフォルトの名無しさん

2009/11/06(金) 00:53:22

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

0537デフォルトの名無しさん

2009/11/06(金) 01:47:03

>>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")

こんな感じ

0538デフォルトの名無しさん

2009/11/06(金) 21:59:58

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

0539デフォルトの名無しさん

2009/11/07(土) 01:05:54

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

0540デフォルトの名無しさん

2009/11/07(土) 01:18:37

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

0541デフォルトの名無しさん

2009/11/07(土) 02:24:25

fix a
var b
とかかな？

0542デフォルトの名無しさん

2009/11/07(土) 13:28:04

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

0543デフォルトの名無しさん

2009/11/07(土) 14:32:08

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

0544デフォルトの名無しさん

2009/11/07(土) 14:37:42

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

0545デフォルトの名無しさん

2009/11/07(土) 14:45:19

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

0546デフォルトの名無しさん

2009/11/08(日) 01:10:35

ファイルの中の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に含まれるブレース文字列を
評価できないものか・・・

0547デフォルトの名無しさん

2009/11/08(日) 01:12:28

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

0548デフォルトの名無しさん

2009/11/08(日) 10:07:16

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

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

0549デフォルトの名無しさん

2009/11/08(日) 10:12:05

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

0550デフォルトの名無しさん

2009/11/08(日) 11:24:53

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

0551デフォルトの名無しさん

2009/11/08(日) 11:32:36

括弧が違う

0552デフォルトの名無しさん

2009/11/09(月) 20:32:41

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

0553デフォルトの名無しさん

2009/11/09(月) 22:23:24

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

0554デフォルトの名無しさん

2009/11/13(金) 17:54:25

php5.3よすよす

0555デフォルトの名無しさん

2009/11/14(土) 01:24:10

>>547
必要か？

0556デフォルトの名無しさん

2009/11/14(土) 02:11:06

>>555
必要

0557デフォルトの名無しさん

2009/11/14(土) 07:27:29

大した事書いてないよ

0558デフォルトの名無しさん

2009/11/14(土) 10:49:13

ソース読んだ方が早い

0559デフォルトの名無しさん

2009/11/14(土) 22:29:15

2.8はいつ出ますか？

0560デフォルトの名無しさん

2009/11/14(土) 23:12:40

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

0561デフォルトの名無しさん

2009/11/15(日) 17:30:21

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

0562デフォルトの名無しさん

2009/11/15(日) 18:05:24

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

0563デフォルトの名無しさん

2009/11/15(日) 18:15:25

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

0564デフォルトの名無しさん

2009/11/15(日) 18:32:01

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

0565デフォルトの名無しさん

2009/11/15(日) 18:46:01

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

0566デフォルトの名無しさん

2009/11/15(日) 19:07:44

たぶんオレの書き方が悪いだけ
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;
　　　　}
　　}
}

0567デフォルトの名無しさん

2009/11/15(日) 19:16:36

>>566
謝罪して帰れよ

0568デフォルトの名無しさん

2009/11/15(日) 19:19:24

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

0569デフォルトの名無しさん

2009/11/15(日) 19:22:28

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

0570デフォルトの名無しさん

2009/11/15(日) 19:54:05

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

0571デフォルトの名無しさん

2009/11/15(日) 19:57:55

>>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版のコードは元記事のをそのまま使った)

0572デフォルトの名無しさん

2009/11/15(日) 20:11:20

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

0573デフォルトの名無しさん

2009/11/15(日) 20:11:44

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

0574デフォルトの名無しさん

2009/11/15(日) 20:17:08

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

0575デフォルトの名無しさん

2009/11/15(日) 20:19:00

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

0576デフォルトの名無しさん

2009/11/15(日) 20:21:39

流れに乗って。こう書くと妙に遅いんだよなあ
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)
　　}
}

0577デフォルトの名無しさん

2009/11/15(日) 20:24:56

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

0578デフォルトの名無しさん

2009/11/15(日) 20:26:06

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

0579デフォルトの名無しさん

2009/11/15(日) 20:27:43

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

0580570

2009/11/15(日) 20:32:48

Java 6　23s

0581デフォルトの名無しさん

2009/11/15(日) 20:40:15

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

0582デフォルトの名無しさん

2009/11/15(日) 20:41:04

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

0583デフォルトの名無しさん

2009/11/15(日) 20:44:55

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

0584デフォルトの名無しさん

2009/11/15(日) 20:46:19

psycoはやいのね

0585デフォルトの名無しさん

2009/11/15(日) 20:47:05

scalaが糞って証明されたな

0586デフォルトの名無しさん

2009/11/15(日) 20:48:51

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

0587デフォルトの名無しさん

2009/11/15(日) 20:54:31

cython

0588デフォルトの名無しさん

2009/11/15(日) 20:55:18

C++は糞

0589デフォルトの名無しさん

2009/11/15(日) 20:58:06

何が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
　}
}

0590デフォルトの名無しさん

2009/11/15(日) 21:00:55

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

0591デフォルトの名無しさん

2009/11/15(日) 21:02:04

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

0592デフォルトの名無しさん

2009/11/15(日) 21:02:53

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

0593デフォルトの名無しさん

2009/11/15(日) 21:09:02

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

0594デフォルトの名無しさん

2009/11/15(日) 21:10:31

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

0595デフォルトの名無しさん

2009/11/15(日) 21:11:06

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

0596デフォルトの名無しさん

2009/11/15(日) 21:11:21

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

0597デフォルトの名無しさん

2009/11/15(日) 21:12:26

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

0598デフォルトの名無しさん

2009/11/15(日) 21:15:38

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

0599デフォルトの名無しさん

2009/11/15(日) 21:18:31

566を見て言うか！

0600デフォルトの名無しさん

2009/11/15(日) 21:18:32

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

0601デフォルトの名無しさん

2009/11/15(日) 21:19:44

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

0602デフォルトの名無しさん

2009/11/15(日) 21:20:33

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

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

0603デフォルトの名無しさん

2009/11/15(日) 21:23:16

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

0604デフォルトの名無しさん

2009/11/15(日) 21:24:38

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

0605デフォルトの名無しさん

2009/11/15(日) 21:25:24

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

0606デフォルトの名無しさん

2009/11/15(日) 21:26:21

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

0607デフォルトの名無しさん

2009/11/15(日) 21:27:36

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

0608デフォルトの名無しさん

2009/11/15(日) 21:36:40

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

0609デフォルトの名無しさん

2009/11/15(日) 21:38:13

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

0610デフォルトの名無しさん

2009/11/15(日) 21:39:53

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

0611デフォルトの名無しさん

2009/11/15(日) 21:40:18

>>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も関数呼び出しもないけど、やっぱり遅いです
なぜだか自分にもわかりません

0612デフォルトの名無しさん

2009/11/15(日) 21:41:29

でもJavaより超簡潔だな

0613デフォルトの名無しさん

2009/11/15(日) 21:43:10

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

0614デフォルトの名無しさん

2009/11/15(日) 21:47:15

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

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

0615デフォルトの名無しさん

2009/11/15(日) 21:47:17

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

0616デフォルトの名無しさん

2009/11/15(日) 22:02:28

>>614
ソースきぼんぬ

0617デフォルトの名無しさん

2009/11/15(日) 22:04:28

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使った方が素直なような

0618デフォルトの名無しさん

2009/11/15(日) 22:04:35

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

0619デフォルトの名無しさん

2009/11/15(日) 22:06:15

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

0620デフォルトの名無しさん

2009/11/15(日) 22:07:29

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

0621614

2009/11/15(日) 22:13:29

>>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++のコンパイルオプションを修正

0622デフォルトの名無しさん

2009/11/15(日) 22:16:16

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

0623デフォルトの名無しさん

2009/11/15(日) 22:17:41

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

0624デフォルトの名無しさん

2009/11/15(日) 22:22:15

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

0625デフォルトの名無しさん

2009/11/15(日) 22:25:38

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

0626デフォルトの名無しさん

2009/11/15(日) 22:37:18

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

0627デフォルトの名無しさん

2009/11/15(日) 22:43:22

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

0628デフォルトの名無しさん

2009/11/15(日) 22:46:08

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

0629デフォルトの名無しさん

2009/11/15(日) 22:49:26

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

0630デフォルトの名無しさん

2009/11/15(日) 23:01:15

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

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

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

0631デフォルトの名無しさん

2009/11/15(日) 23:04:04

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

0632デフォルトの名無しさん

2009/11/15(日) 23:12:44

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

0633デフォルトの名無しさん

2009/11/15(日) 23:14:12

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

0634デフォルトの名無しさん

2009/11/15(日) 23:19:31

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

0635デフォルトの名無しさん

2009/11/15(日) 23:37:15

簡潔さなら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)

0636デフォルトの名無しさん

2009/11/15(日) 23:45:54

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

0637デフォルトの名無しさん

2009/11/15(日) 23:48:38

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)

0638デフォルトの名無しさん

2009/11/15(日) 23:49:01

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

0639デフォルトの名無しさん

2009/11/15(日) 23:50:43

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

0640デフォルトの名無しさん

2009/11/15(日) 23:53:48

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

0641デフォルトの名無しさん

2009/11/16(月) 00:40:13

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

0642デフォルトの名無しさん

2009/11/16(月) 00:51:08

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

0643デフォルトの名無しさん

2009/11/16(月) 00:52:08

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

0644デフォルトの名無しさん

2009/11/16(月) 00:56:25

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

0645デフォルトの名無しさん

2009/11/16(月) 01:50:25

>>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みたいに書いて高速化できるっつーことで

0646デフォルトの名無しさん

2009/11/16(月) 04:33:43

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

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

0647デフォルトの名無しさん

2009/11/16(月) 04:44:42

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

0648デフォルトの名無しさん

2009/11/16(月) 07:13:17

このソースコードで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
}

0649デフォルトの名無しさん

2009/11/16(月) 09:03:34

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

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

0650デフォルトの名無しさん

2009/11/16(月) 16:34:40

Lift連載第二回

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

0651デフォルトの名無しさん

2009/11/16(月) 21:07:19

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

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

0652574 611

2009/11/16(月) 22:11:24

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

0653デフォルトの名無しさん

2009/11/16(月) 23:22:38

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

0654デフォルトの名無しさん

2009/11/16(月) 23:37:49

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

0655デフォルトの名無しさん

2009/11/16(月) 23:47:31

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

0656デフォルトの名無しさん

2009/11/17(火) 05:21:54

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

0657653

2009/11/17(火) 07:19:13

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

0658デフォルトの名無しさん

2009/11/17(火) 08:44:45

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

0659デフォルトの名無しさん

2009/11/17(火) 20:41:10

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

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

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

0660デフォルトの名無しさん

2009/11/17(火) 21:23:03

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

0661653

2009/11/17(火) 22:52:49

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

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

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

0662デフォルトの名無しさん

2009/11/17(火) 22:56:31

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

0663デフォルトの名無しさん

2009/11/18(水) 13:56:17

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

0664デフォルトの名無しさん

2009/11/19(木) 22:02:45

まだ4倍遅いな

0665デフォルトの名無しさん

2009/11/21(土) 07:09:09

標準の 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
}

0666デフォルトの名無しさん

2009/11/21(土) 08:56:40

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

0667デフォルトの名無しさん

2009/11/21(土) 09:47:26

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

0668デフォルトの名無しさん

2009/11/21(土) 09:59:17

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

0669デフォルトの名無しさん

2009/11/21(土) 12:13:37

maven必須なのがなんとも

0670デフォルトの名無しさん

2009/11/21(土) 16:42:53

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

0671デフォルトの名無しさん

2009/11/21(土) 18:19:22

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

0672デフォルトの名無しさん

2009/11/21(土) 18:39:07

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

0673デフォルトの名無しさん

2009/11/21(土) 18:49:31

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

0674デフォルトの名無しさん

2009/11/21(土) 18:56:57

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

0675デフォルトの名無しさん

2009/11/21(土) 18:58:56

>>674
3.0って一体いつになるんだよw

0676デフォルトの名無しさん

2009/11/21(土) 19:23:31

ああ、2.7と2.8じゃ、ソースコードが全然違うね
2.7は同じプログラムでも倍くらい遅いわ
elementsメソッドがobsoleteになってるからまぎらわしかったね
ちゃんとiteratorと書かなきゃ駄目だったね、いまさらだけどｗ

0677デフォルトの名無しさん

2009/11/21(土) 19:49:03

>>665 は、2.7.7 を前提として書きました。
2.8.0 のソースを見る限り、わざわざ takeWhile を自作する必要はないようなので、
2.8.0 の方は >>665 を無視してください。

0678デフォルトの名無しさん

2009/11/21(土) 19:54:26

基本的にはVerとか示すのが一番なんだろうけど
まぁ大体分かるしいいんじゃないの
宿題スレだと必須だけど

0679デフォルトの名無しさん

2009/11/22(日) 11:29:41

NetBeansのscalaプラグインってimportの保管してくれないの？

0680デフォルトの名無しさん

2009/11/22(日) 18:12:59

う～ん・・遅い・・・う～ん・・・

0681デフォルトの名無しさん

2009/11/22(日) 20:14:06

なんで関数型言語って並列処理に適してるんだ？いまいち理由がわからん。
あとerlangにしろscalaにしろアクターとかを言語レベルでサポートしてるのはなぜ？別に関数型言語にアクターは必ず必要ってわけではないよね？

0682デフォルトの名無しさん

2009/11/22(日) 20:19:19

アクターやCPSなどの並列モデルに関しては、
スレッドなどと一緒で、有望や成熟した物が、
徐々に主流なものにサポートされていくだけだとおもう。

元々の言語に向き不向きはあるかもしれないが。

0683デフォルトの名無しさん

2009/11/22(日) 20:20:35

関数型言語が並列に向いてると言われてるのは、
参照透明性があれば処理を別々にしやすいからじゃね

0684デフォルトの名無しさん

2009/11/22(日) 20:38:57

いままでの分散処理では、チューニングすれば速度の出るMPIとかは特別な用途向けで、
一般的なプログラム向けとしては、それを仮想的な共有メモリモデルに
当てはめて処理能力を上げるかを研究してきたというのがあった。
↓
それに対して、WebスケールのプログラムやPCでの同時処理数が一般的になるなかで、
共有メモリ上での処理は、CAP定理というので、結局スケールしないことも分かってた。
↓
DBにしろ言語にしろ共有しないで動作する機構を単位とするものが必要になってきて
それには、不変型で処理する関数型とかメッセージパッシングとかが必要だ。
↓
特殊な言語じゃなくて、Cのような主流の書き方が出来る言語で出来るようにしよう。
↓
Scala出来たよ。←今ここ
↓
C/C++とかJava/C#でもサポートされる。

0685デフォルトの名無しさん

2009/11/23(月) 01:04:16

>>681
関数⇒副作用無し(入力が一意なら出力も一意)⇒関数の依存関係だけで並列実行可能性が決まる⇒並行処理でウマー
というのが基本的な考え方。とは言え、実在の処理系でソレが実現できているかは別問題だったり。

あと、ScalaのActorはライブラリでの実装で、言語レベルでは何もしてないぞ。
Erlangの方は、そもそもアクターがないとまともなプログラムが書けない言語仕様。

0686デフォルトの名無しさん

2009/11/23(月) 01:15:28

Scalaは、なぜ関数の副作用の有無を判別出来るようにしなかったんだろう？
var/valみたいに。

0687デフォルトの名無しさん

2009/11/23(月) 06:15:41

実際には副作用があるけど外から見ると無いように見える関数とか作れるからじゃね
というかどっちにしろコンパイラが賢くないと意味なさげ

0688デフォルトの名無しさん

2009/11/23(月) 08:57:55

それを明示できるようになったとしたら、
Cのconst引数と同じで、コールスタックの深いところで副作用のある関数を
使わななきゃいけなくなったときにえらい目に合う気が

0689デフォルトの名無しさん

2009/11/23(月) 23:16:43

>>688みたいなこと、たまにやるわ。
自分の設計が悪いんだろうけどがっくりする。
一方でmutableなのかわかったほうがいいとも思う。
IDEのリファクタリングなどの機能でなんとかならんかね

0690デフォルトの名無しさん

2009/11/25(水) 23:16:28

lift本ってどう？

0691デフォルトの名無しさん

2009/11/25(水) 23:37:11

>690
索引が無いとか、有るはずのappendixが抜けてるとか、てきとーな作り。

でも、一通り読むと役に立つよ。一通り読んでもやっぱりソース読まないと
アプリ作れない気もするけど。

0692デフォルトの名無しさん

2009/11/26(木) 12:28:13

scala結構気に入ったけど
これは流行らないだろうな

0693465

2009/11/26(木) 14:28:57

Java7にクロージャが入ったし・・・

0694デフォルトの名無しさん

2009/11/26(木) 15:14:01

scala好きになれない…
やりたい事はわかるけど…
あっちこっちの言語の継ぎはぎにしか見えない。
統一感がない。美しくない。

0695デフォルトの名無しさん

2009/11/26(木) 15:39:00

>>693
Java 7に入る予定のクロージャは超劣化版といってもいいもので、
あれが入ったからといってScalaのメリットが無くなるとはいえないなあ。

>>694
あっちこっちの言語の継ぎはぎに見えるのは、君が中途半端に色々な言語
かじっているせい(で、そう思い込んでいる)だと思われ。少なくとも設計理念は
割と明確な言語だと思うよ

0696デフォルトの名無しさん

2009/11/26(木) 15:42:48

ちなみに設計理念てのは、オブジェクト指向プログラミングと関数型プログラミングの統合のことね。
OCamlなんかもオブジェクト指向と関数型のハイブリッドだけど、あっちはMLライクな型システムの上に
オブジェクト指向機能を足していったものなのに対して、ScalaはJavaライクな型システムと言語仕様の
上にどのような機能を載せれば関数型プログラミングが容易にできるかを考え抜いて作られた言語だと思う。
一見色々機能があってごちゃごちゃして見えるけど、ほとんどの機能が関数型プログラミングを容易にする
ためという点で一貫している。

0697デフォルトの名無しさん

2009/11/26(木) 16:58:04

Java見た後だとなんでも良く見える

0698デフォルトの名無しさん

2009/11/26(木) 18:29:20

>>691
感想ありがとうございます。
lift本ってGoogleグループにあるPDFファイルと内容は同じなの？

0699デフォルトの名無しさん

2009/11/26(木) 21:03:36

もう少し低能プログラマにも配慮しないと
普及は難しいだろうな

0700デフォルトの名無しさん

2009/11/26(木) 21:14:55

それってどこのJavaのこと？

0701デフォルトの名無しさん

2009/11/26(木) 21:30:59

その辺はIDE次第かな。

0702デフォルトの名無しさん

2009/11/26(木) 21:34:03

Emacsでも書けるほど簡潔な言語じゃないと駄目というのが俺の持論

0703694

2009/11/26(木) 22:08:50

>>696
>ごちゃごちゃして見える
言語の継ぎはぎだからでしょ？

>Javaライクな型システムと言語仕様の
>上にどのような機能を載せれば関数型プログラミングが容易にできるか
やりたい事はわかるよ。
美しくないだけ。

0704デフォルトの名無しさん

2009/11/26(木) 22:49:12

>>703
どう継ぎはぎなのか自分の言葉で説明してみたら？

0705デフォルトの名無しさん

2009/11/27(金) 03:25:52

デフォルトがpublicなのがいい

0706デフォルトの名無しさん

2009/11/27(金) 12:13:31

Groovyだと、groovy-all.jarをクラスパスに突っ込んでおけば、普通のJavaと同じように
java -jar hoge.jar
といった感じで実行できるのですが、
ScalaをJavaに混ぜた場合、このような形でプログラムを作るにはどうすれば良いでしょうか？

0707デフォルトの名無しさん

2009/11/27(金) 19:54:59

>>706
Groovyの場合とあんまり変わらん。scala-library.jarをクラスパスに通せばＯＫ

0708デフォルトの名無しさん

2009/11/28(土) 03:05:03

>>696
> オブジェクト指向プログラミングと関数型プログラミングの統合のことね。

統合なんてされてないが?
関数型的なはごく一部だし、
この程度なら今時の言語はほとんど入っているか、入れようとしている。

設計理念ならJoin計算とか型理論とかその辺だろ。

0709デフォルトの名無しさん

2009/11/28(土) 06:47:50

>>708
高階関数、パターンマッチ、代数的データ型、多相型、抽象型、…
現代的な(静的型)関数型言語が持っている機能はほとんど持っているよ。ファンクタでさえオブジェクト＋
抽象型でエミュレートできる。特にML系言語が持っているまともなパターンマッチ持っているのは
少数派だろ。いまどきの言語が取り入れてるのはせいぜい高階関数と多相型までで、パターンマッチ
とか代数的データ型取り入れてるのは少数派だ。あと、Scala自体はJoin計算とはあまり関係ないよ。
型理論はScalaの型システムを設計するに当たって駆使されてるのは間違いないが、それは設計理念
とは別の話だ。

0710デフォルトの名無しさん

2009/11/28(土) 11:10:56

確かにパターンマッチがあるのは地味に嬉しい
クロージャなんかは他の言語でもほとんど付くようになったけど

0711デフォルトの名無しさん

2009/11/28(土) 15:00:50

仮に「オブジェクト指向プログラミングと関数型プログラミングの統合」が設計理念だとしても、
その設計理念が「この言語は継ぎ接ぎですよ」の言い換えに見えるんだけど

0712デフォルトの名無しさん

2009/11/28(土) 15:10:37

それにたとえば、>>709なんていかに多くの機能を継ぎ接ぎして
取り入れているかという説明にしか見えないんだが？

0713デフォルトの名無しさん

2009/11/28(土) 15:14:47

一般的に、継ぎ接ぎという表現は「継ぎ目が見えている」ということに
ウェイトが置かれているものではないかな。
つまり、「統合しきれていない」という「現状・結果」のネガティブ表現であることが多いと思う。

だから「統合という理念」が「継ぎ接ぎの言い換え」であるという解釈は適切ではないように思う。

0714デフォルトの名無しさん

2009/11/28(土) 15:16:43

もっと具体的な話をしろや

0715デフォルトの名無しさん

2009/11/28(土) 15:17:43

>>713
「オブジェクト指向プログラミングと関数型プログラミングの統合」という
言葉か「継ぎ目が見えていない」をイメージする人は少数派で、
単に「同一言語に二つの機能が入っている」ことをイメージする人が多数派であると俺は思うよ。
そして、それは一般的には継ぎ目が見えていることを意味する。

0716デフォルトの名無しさん

2009/11/28(土) 15:22:56

Pythonの作者もScalaの型システムなどについて、コンセプトが
数多く含まれすぎているという趣旨の批判をしているな
これは継ぎ目が見えているという批判に他ならない
http://neopythonic.blogspot.com/2008/11/scala.html

0717デフォルトの名無しさん

2009/11/28(土) 15:35:16

継ぎ接ぎかどうかなんてどうでもいいよ。使い易くて醜くなければ。

0718デフォルトの名無しさん

2009/11/28(土) 15:38:23

動的言語の作者が静的な型の複雑さに文句を言うのはいつものこと

0719デフォルトの名無しさん

2009/11/28(土) 15:41:02

Haskellはなぜか褒めてるけどな

0720デフォルトの名無しさん

2009/11/28(土) 15:50:58

型がないPythonとかガチガチの関数型のHaskellの方が綺麗ってそりゃそうだろって感じだな
色んな機能を持ち合わせた上でどれだけ簡潔に書けるかってことだろ
その点でScalaはよくまとめてると思うよ

0721デフォルトの名無しさん

2009/11/28(土) 16:05:44

それは言い訳じゃないかな

0722デフォルトの名無しさん

2009/11/28(土) 16:06:48

勘違いしてる人が多いけど、Pythonの作者がScala自体を批判したのであって、
Pythonと比べて批判したわけではない

0723デフォルトの名無しさん

2009/11/28(土) 16:09:37

>>722
そりゃポジショントークなのは明らかだろ
まつもとだって他の言語をよく批判するし
とにかく他のやつの言葉をもってくるんじゃなくて
自分で気に食わない点を言えってことだな
抽象的な言葉じゃなくて

0724デフォルトの名無しさん

2009/11/28(土) 16:11:37

>>720
「～にしては」よくまとめているというが、それは
結局、そういうことを考慮しなければまとまっていないということだろう
動的言語の方がシンプルなのは当たり前というが、
だったら動的言語にすればいいこと
いろんな機能を持ち合わせた代償として複雑な
仕様になったというのなら、そのこと自体が間違っている
ことになる

0725デフォルトの名無しさん

2009/11/28(土) 16:13:46

>>723
で？批判されてることにかわりないわけだが

0726デフォルトの名無しさん

2009/11/28(土) 16:16:56

>>724
シンプルなことが全てじゃないってことだよ
シンプルなのが最強ならSchemeが最高だろうな
静的な型を持ってれば、宣言で汚くなるか、
ミルナーの推論の制約を受けて動的な言語よりやれることは少なくなる
だったら型チェックをやめればいいってのは暴論
あとはトレードオフとバランス感覚の問題

0727デフォルトの名無しさん

2009/11/28(土) 16:18:45

>>725
だったらこっちはScalaを褒めている有名人のリンク集でも作れっていうのか？
馬鹿馬鹿しいことになるだけだろ

0728デフォルトの名無しさん

2009/11/28(土) 16:21:10

>>726
結局、トレードオフやバランスの問題で、ほかよりつぎはぎな言語である
ということだろ

>>727
いや、ぜんぜんばかばかしいことはないよ
継ぎ接ぎではなく、シンプルな言語仕様に統一されている
という趣旨のリンク集が作られればとても参考になるだろう

0729デフォルトの名無しさん

2009/11/28(土) 16:25:20

継ぎ接ぎだらけであるという事実を覆すような
反論は何一つとして出ないな
「多数の機能を取り入れてるにしては」だのと、
条件付きでの反論があるだけで、結局、トレードオフとして
継ぎ接ぎだらけであると認めている意見しか出なかった
継ぎ接ぎだらけであるというのが結論のようだな

0730デフォルトの名無しさん

2009/11/28(土) 16:29:10

>>728 >>729
だから「つぎはぎ」って言いたいだけだろ
水掛け論にしかなってない
機能を減らせばシンプルになる、増やせばそれなりに複雑になる
そういうことでしかない
BASICから見れば、Javaだって複雑怪奇な言語にしか見えんだろうさ

0731デフォルトの名無しさん

2009/11/28(土) 16:33:28

やけに伸びてるかと思えば‥‥

0732デフォルトの名無しさん

2009/11/28(土) 16:37:38

機能の多い言語＝継ぎはぎだらけって定義なら、そりゃ言うまでも無く
Scalaは継ぎはぎだらけだろう。だが、そういう事言いたいわけじゃないだろう？
まず、継ぎはぎだらけというのがどういう事なのか、具体例を挙げて批判してくれ。
Guidoの批判は、Scalaをけなしといて一方でHaskellを褒めてるあたり、どう見ても
静的型システムを良く知らずに批判してますって感じで、全然あてにならん。

0733デフォルトの名無しさん

2009/11/28(土) 16:40:40

あ、>>728見ると、シンプルな言語仕様＝継ぎはぎではないって意図なのね。
じゃあ、>>728的にはScalaは継ぎはぎでいいよ、もう。Scalaの言語仕様が
そこそこ複雑なのは事実だから。だが、そんなこと言い出したら、Scheme以外
は皆継ぎはぎだらけみたいなあまり意味の無い結論しか出てこないぞ。

0734デフォルトの名無しさん

2009/11/28(土) 17:05:29

機能の実現ということでいうなら、Schemeはオブジェクト指向の機能も
関数型言語の機能も全て実現できるんだが

0735デフォルトの名無しさん

2009/11/28(土) 17:07:34

>>715
でもうまく行ってたら、たぶん継ぎ接ぎとは言われないんじゃないかな。

0736デフォルトの名無しさん

2009/11/28(土) 17:11:42

うまく行こうが行くまいが、悪くいう奴は出てくるからなぁ

0737デフォルトの名無しさん

2009/11/28(土) 17:15:45

Scala擁護してる人の中にSchemeが好きな人がいるみたいだけど、
Schemeを見ればScalaがいかに継ぎ接ぎだらけかということに気づかない？
マクロさえ使えばScala以上の機能がいくらでも使えるのにシンプルな言語仕様

0738デフォルトの名無しさん

2009/11/28(土) 17:25:09

だったらScheme使って日常のスクリプトとかサーバプログラミングとかやってみればいいさ
どれだけめんどいかわかるから

0739デフォルトの名無しさん

2009/11/28(土) 17:27:41

>>738
つ　普通のやつらの上を行け

0740デフォルトの名無しさん

2009/11/28(土) 17:31:40

>>737
Scheme厨乙。マクロがあれば、「頑張れば」大体なんでもできるのは事実だが、マクロで実現した機能だと
実行性能や分割コンパイルなど、実用的には色々難しい面があるってのを考えといた方がいいぞ。
Common Lispにそれなりに支持者が居る理由を考えてみた方が良い。
あと、ちゃんとした静的型システムは(少なくとも)Schemeのマクロだけで実現するのはまず無理。
型チェックを網羅的にやろうとすると、関数定義や変数定義は全部独自のマクロで定義したものしか
型付けできないみたいなことになって、本末転倒だから。

0741デフォルトの名無しさん

2009/11/28(土) 17:37:15

あとね、マクロって言っても本質的には所詮S式→S式のトランスレータが簡単に書けるというものでしか
無いわけで、マクロがあればどんな言語機能も簡単に実現できるわけじゃねーんだから、あんまりマクロ
を持ち上げ過ぎるのもどうかと思うよ。Scalaだってコンパイラプラグインがあって、言語仕様を好きなように
拡張できるんだから。

0742デフォルトの名無しさん

2009/11/28(土) 17:39:27

>>740
今回の議論に必要であり本質を突いているのは、最初の一行だけで
後はすべて揚げ足取りですね
そして、その本質である最初の一行であっさりとScala以上の方法が
ありうることを認めてしまってるな

0743デフォルトの名無しさん

2009/11/28(土) 17:41:15

>>741
マクロは言語仕様であって、コンパイラプラグインは言語仕様ではない
そして、今は言語仕様の話をしている

0744デフォルトの名無しさん

2009/11/28(土) 17:44:55

そりゃScalaは何でもできる言語じゃないよ
とりあえずevalができないじゃない
でもそういうのはトレードオフだからね
この人はいったい何が不満なんだろ
とりあえずClojureでも使えばいいんじゃないだろうか

0745デフォルトの名無しさん

2009/11/28(土) 17:44:59

別にScala以上の機能を持った言語を探してくる必要もないなあ
高機能だとか低機能だとかってのは継ぎ接ぎだらけであるかどうか
という点とはまた違った観点でしかないのだから

0746デフォルトの名無しさん

2009/11/28(土) 17:49:17

>>742
Scala以上の方法がありうることは最初から否定してないが？
マクロが万能かのような物言いをするから、そうじゃない例を挙げただけだ。

>>743
「今の話の文脈で」、言語仕様かどうかにどんだけ意味があるよ？大体、ScalaはいまんとこEPFLによる
実装しか存在しないんだから、実質、Scalaではコンパイラプラグインが使えると言っても差し支えない。
もちろん、一般論として言語仕様か独自拡張か区別することは重要だけど、少なくとも今の議論では
どうでもいいことだ。「Scalaではコンパイラプラグインさえ使えばどんな機能でも使える上に～」とか
言ってたら滑稽だろ？Schemeでマクロがうんたら言うのはそれと同レベルだってことだ。

0747デフォルトの名無しさん

2009/11/28(土) 17:50:54

>>746
こちらこそ、マクロが万能であるとは一言も言ってないが？
ただ、Scala以上の機能がいくらでも実現できることは確かだ
だからこそ、比較によって「感覚的に」継ぎはぎだらけだと思えるだろうに
と言いたいんだよ

0748デフォルトの名無しさん

2009/11/28(土) 17:53:33

>>746
今の文脈はどうみても「言語仕様が」継ぎ接ぎだらけだという文脈だろ
意味があるかどうかはまったく別の観点だ
だが、あえて別の観点であることを承知でいえば、言語仕様に
なっているものはコンパイラプラグイン以上に皆が共通で利用するのだから、
言語仕様のみに限って議論することに意味はあるだろう

0749デフォルトの名無しさん

2009/11/28(土) 17:54:05

>>747
Scala以上の機能をマクロ使ってうまく実装できる場合もあるが、そうでない場合もある。
試しに、とりあえずScalaと同じ静的型システムを持った言語をSchemeの「マクロだけで」実装することを
考えてみてくれ。無理でしょ？できても、その部分がScheme部分とは別言語になるだけで、新しい言語の
コンパイラを他の言語で一から書くのとと大して変わらん労力がかかってしまい、マクロである意味は無くなる。

0750デフォルトの名無しさん

2009/11/28(土) 17:55:02

>>749
だから、何でもかんでも全部そうだとは言ってない
君が認めるように「大部分は」うまく実装できる
それだけで事足りる話だ

0751デフォルトの名無しさん

2009/11/28(土) 17:56:59

他の動的な言語にマクロで何でもできると喧嘩ふっかけるならいいが
静的/動的の垣根を越えて比較するのは不毛なのではないか

0752デフォルトの名無しさん

2009/11/28(土) 17:57:53

>>750
いや、Scalaの仕様の複雑さの多くはその強力な静的型システムに起因してるから、そこがうまく
扱えるかどうかは重要。静的型システムがマクロでうまく取り扱えないので、それだけでもマクロで
カバーできない重要な領域があることになる。

0753デフォルトの名無しさん

2009/11/28(土) 17:59:10

また、静的だから違うといってごまかそうとする論理か
静的言語にScheme級のマクロがあったとしてもなんらおかしくはないんだけどな
マクロ以外の別の選択肢もありうるだろう

0754デフォルトの名無しさん

2009/11/28(土) 18:01:40

この板ってID出ないから誰が発言してるんだかわかりにくい。
名前欄に何か入れてよ。

0755デフォルトの名無しさん

2009/11/28(土) 18:02:08

>>752
だから、その強力な静的型システムを実現するために「複雑に」
なっていると認めているじゃん
Schemeはそれを実現していないから複雑でないんだろう
だったら、そこで話は終わりだ
Scalaは継ぎ接ぎだらけであると双方が結論を出した

0756デフォルトの名無しさん

2009/11/28(土) 18:03:40

>>753
いや、だって、発端の>>737が
＞Schemeを見ればScalaがいかに継ぎ接ぎだらけかということに気づかない？
＞マクロさえ使えばScala以上の機能がいくらでも使えるのにシンプルな言語仕様
みたいにSchemeと比較するんだから、しゃあない。マクロ以外の選択肢はそりゃあ
ありえると思うが、例も出さずに可能性だけの話しても意味無い。

0757デフォルトの名無しさん

2009/11/28(土) 18:03:54

静的型つきScheme
http://www.ccs.neu.edu/home/samth/typed-scheme/

0758デフォルトの名無しさん

2009/11/28(土) 18:05:36

>>756
だからといって、揚げ足取りみたいにSchemeより優位な点を挙げて
満足なのか？
元の文はどう見ても全体的な話をしているのに

0759752

2009/11/28(土) 18:05:36

>>755
複雑＝継ぎはぎだらけって意図ならそうだけど、そう取っていいわけ？
なら、話はそれで終わりだ。

0760デフォルトの名無しさん

2009/11/28(土) 18:07:47

>>759
どうやら結論が出たようだな

まあ、一応付け加えておくと、大体同じような意味ではある
多数の機能を実現するために、継ぎ目の見える複数のコンセプトを導入することを
継ぎ接ぎだらけと言っているから、言語仕様が複雑であるということと
ほとんど大差はない

0761デフォルトの名無しさん

2009/11/28(土) 18:08:29

マクロで彼女ができました

0762デフォルトの名無しさん

2009/11/28(土) 18:09:33

>>753
＞静的言語にScheme級のマクロがあったとしてもなんらおかしくはないんだけどな
おかしくないなら君が作りなさいよ

静的vs動的は古典的なネタだし、ここで繰り返しても意味ないと思うが
君の論法だと全ての静的な言語はマクロがないゆえに複雑な言語ってことになると思うが
Scalaに限定した話にしないと不毛って言ってるわけ

0763752

2009/11/28(土) 18:10:11

>>758
満足も何も、マクロさえ使えばScala以上の機能がいくらでも使えるっつうから、
そうでない例(静的型システム)出したわけだが？つまり、(Schemeの)マクロで
カバーできない(静的型付けという)重要な機能のためにScalaの言語仕様は
複雑になってるわけで、そこを抜きにしても

0764デフォルトの名無しさん

2009/11/28(土) 18:10:41

>>762
>>757

0765デフォルトの名無しさん

2009/11/28(土) 18:12:51

>>763
そのこと（マクロで実現が難しいことも存在するということ）と、Scala以上の機能がいくらでも使えるということは
なんら矛盾していないんだが？
しかも、その重要な機能のために複雑になっているんだろ？

0766752

2009/11/28(土) 18:13:13

途中で送信してしまった。
(続き) そこを抜きにして
＞マクロさえ使えばScala以上の機能がいくらでも使えるのに
と言っても、「Scala以上」が実現できてないじゃん、と言えるわけで。

0767デフォルトの名無しさん

2009/11/28(土) 18:14:06

>>764
その型つきSchemeを使って、Scalaと同等の機能を実現できるわけ？

0768デフォルトの名無しさん

2009/11/28(土) 18:14:52

>>766
単に、「Scala以上」の意味を誤解してるだけだな
Scalaのすべてを全部実現することではないからな

0769752

2009/11/28(土) 18:15:22

>>765
Scalaの静的型システムはScalaの重要な機能のうちの一つであって、しかもSchemeのマクロじゃ
実現が難しい例なわけだが？「Scala以上の機能がいくらでも使える」と聞くと、普通はマクロを使えば
Scalaの機能はすべて実現可能と取るでしょ。

0770デフォルトの名無しさん

2009/11/28(土) 18:15:46

>>767
できるかできないかでいえば、「できる」
困難かどうかでいえば、「困難」
そして、Scalaで実現できないことを実現できる

0771デフォルトの名無しさん

2009/11/28(土) 18:16:40

だから一般論として静的/動的の比較になっちゃ意味ないよ
今までの議論どおり、どっちも得意、不得意があるってことにしかならんのだから
同じ土俵で具体的にScalaの記述はここが冗長であるとか指摘できるならいいけど

0772デフォルトの名無しさん

2009/11/28(土) 18:17:13

>>769
別に取らないだろ
大体は実現できた上で、Scalaに実現できないことをいくらでも付け加えることができるのだし
そもそも、困難であって、できないわけではないだろ

0773デフォルトの名無しさん

2009/11/28(土) 18:18:34

>>771
同じ土俵で語ることが間違ってるな
土俵が間違ってるということも含めて議論しないと

0774デフォルトの名無しさん

2009/11/28(土) 18:20:08

>>773
土俵が間違ってるかどうかって、動的か静的かで結論出せってこと？
それこそ、このスレでやることじゃないよ

0775752

2009/11/28(土) 18:24:53

>>772
実用を度外視して、できるかどうかで言えばできるけど、それは、単に「SchemeでScalaの型チェッカを書ける」ってのと同レベル
の話であって、マクロを使うことによるメリットはほとんど無いと言っていい。仮にそのマクロを使って実現された埋め込み言語を
SScalaと名づけたとして、SScalaの中に任意のScheme式を埋め込むことはできないだろう(型付けしようが無いから)。
だから、実用的には「できない」と言ってしまっても差し支えない。一般的に言って、Schemeのような呼び出し形式のマクロは
型チェックとか、プログラムのグローバルな最適化とかみたいな横断的関心事扱うには全くもって向いてない。横断的関心事
扱うためのマクロシステムみたいな
のもあるにはあるが、それはSchemeとは別の話になるし。

0776デフォルトの名無しさん

2009/11/28(土) 18:26:46

>>774
結論出せとは言ってないけど、議論の一要素ではあるな
たとえば「動的言語にすれば継ぎ接ぎは少なくできるから
Scalaは継ぎ接ぎだらけで汚いんだ！」という主張はありうる
主張だろう
まあ、静的だとしてももっとほかに解があるという方向性の
主張もあるけどな
実際このスレでもPythonの作者がしているし、
静的Schemeみたいな同じ土俵の言語のURLが張られて
いるようだし

0777デフォルトの名無しさん

2009/11/28(土) 18:28:40

>>775
結局、君が言ってるのは、マクロでは静的型チェックの実現が困難だといってるに過ぎないだろ
静的型チェックを持つ言語がマクロを備えたら何の反論にもならないし、
実際そういう言語はもう存在している

0778デフォルトの名無しさん

2009/11/28(土) 18:30:46

>>733
お前ら、とりあえず落ち着いてこれでも食え

つ【Lua】

0779デフォルトの名無しさん

2009/11/28(土) 18:34:16

>>776
＞たとえば「動的言語にすれば継ぎ接ぎは少なくできるから
＞Scalaは継ぎ接ぎだらけで汚いんだ！」という主張はありうる
＞主張だろう

とりあえず、これのどこが「ありえる主張」なのかさっぱりわからんのだが

静的Schemeは、俺は使ったことない言語だから何も言えんが、
この中で誰か詳しい人いるの？　いないなら脇に置いておくべきだと思うが

0780752

2009/11/28(土) 18:34:59

>>777
いやだから、Schemeが比較対象になってるからそういう反論しただけであって、別の形の
反論までは否定してないよ。静的型チェックを持つ言語でかつマクロを持っている言語が
いくつかあることも知ってる。ただ、ひとつ言うなら、マクロを足したら言語仕様はその分
複雑になるわけで、君たちが言う「継ぎはぎ」の数はより多くなるんじゃないかな？

0781デフォルトの名無しさん

2009/11/28(土) 18:39:28

静的型を付け加えたSchemeは、言語仕様を議論するだけなら
想像して議論する価値があるだろうし、簡単にみんなが想像できるだろう
このことは、静的であること自体が言語仕様を複雑にしている大きな要因では
ないということも意味しているけど

0782デフォルトの名無しさん

2009/11/28(土) 18:40:43

>>780
その意味では継ぎ目はもちろん多くなるよ
でも、その多くなった継ぎ目で、別の継ぎ目がなくなるのであれば
総合的には継ぎはぎの数は少なくなるだろ

0783デフォルトの名無しさん

2009/11/28(土) 18:42:45

>>781
いや、だから型付きSchemeの仕様を具体的に知ってんのかと
それも知らんのに想像して議論する価値なんてないよｗ

0784デフォルトの名無しさん

2009/11/28(土) 18:44:26

>>783
型付きSchemeが複雑怪奇な仕様だとお前は思うわけ？
どうせ、わからないとか主張するんだろうけど
本音では思わないだろ？ｗ

0785752

2009/11/28(土) 18:44:26

>>781
静的型システムと言ってもピンキリで強力にしようとすればするほど
仕様が複雑になる(当たり前だけどね)。で、Scalaの型システムはかなり
強力で(高階の型すら扱える)、仕様が複雑になる大きな要因の一つになってる。
ちなみに、Haskellの型システムもかなり強力なので、やっぱりそれほど単純ではない
(Guidoはその辺知っててHaskellを推してるのかどうかは知らんが)。

0786デフォルトの名無しさん

2009/11/28(土) 18:48:59

>>784
いや、知らんよ
誰も知らん言語を想像で語る意味がないってだけ
どうせ頭の中でいいとこどりになるだけだろ

マクロなら何でもできる論もそうだが、可能性だけ想像して
Scalaの方が複雑と断言できる神経が理解できない

0787デフォルトの名無しさん

2009/11/28(土) 18:50:00

>>785
型システムに限らないことをいえば、強力であればあるほど複雑
になるというのは間違いだ
それこそ、Schemeを見ればわかる
そして、次に100歩譲って型システムに限れば、強力であればあるほど複雑になるとしても、
結局、強力であるがために継ぎ接ぎだらけであるという主張の反論にはなっていない
そして、さらに、型システム以外の点でも継ぎ接ぎだらけだ
たとえばGuidoは普通の括弧と中括弧の中でのセミコロンの挙動の違いをあげてるな

0788デフォルトの名無しさん

2009/11/28(土) 18:50:54

>>786
そんなに難しい話でもないだろ
ただ静的型チェックするだけだし

0789752

2009/11/28(土) 18:51:44

とりあえず、型付きSchemeのドキュメントざっと眺めてみた。レコード型や再帰型、多相型があって
SMLに割と近い感じがする。サブタイピングとか高階の型、型クラスなんかはなさげ。で、これを
土台にどう議論しろと？ScalaよりもHaskellよりも弱い表現力しかなくて、比較対象にできるものでは
無い感じだが。

0790デフォルトの名無しさん

2009/11/28(土) 18:53:43

サブタイピングとか高階の型、型クラスねえ
それこそ「マクロ」で簡単に同等なことを実現できそうだなw

0791デフォルトの名無しさん

2009/11/28(土) 18:56:07

pgr

0792デフォルトの名無しさん

2009/11/28(土) 18:57:20

これ以上、妄想言語と比較論やってもしょうがないわ
具体的にScalaと同等の機能を実現できるマクロを作ってから出直してくれ

0793デフォルトの名無しさん

2009/11/28(土) 18:58:46

>>792
その論理が間違いだといってるのに
じゃあ、Schemeと同等の機能を実現できないのに
Schemeより複雑怪奇なScalaは問題外ですな

0794752

2009/11/28(土) 19:00:00

>>787
＞型システムに限らないことをいえば、強力であればあるほど複雑
＞になるというのは間違いだ
＞それこそ、Schemeを見ればわかる
型システムの話をしてるんだが。で、型システムは一般に強力にしようとすればするほどどうしても
複雑になる。依存型とかでぐぐってみるとよろし。複雑だから強力とは限らないが、少なくとも強力な
型システムはある程度以上複雑だとは言える。

＞そして、次に100歩譲って型システムに限れば、強力であればあるほど複雑になるとしても、
＞結局、強力であるがために継ぎ接ぎだらけであるという主張の反論にはなっていない
いや、だから複雑＝継ぎはぎという主張なら反論はしないよ。

＞そして、さらに、型システム以外の点でも継ぎ接ぎだらけだ
＞たとえばGuidoは普通の括弧と中括弧の中でのセミコロンの挙動の違いをあげてるな
正直に言うと、シンタックスに限定して言えば、割と継ぎはぎが多いのは認めざるを得ない
(単に複雑という意味でなく、ad hocな挙動がいくつも見られる点で)。ただ、セマンティクスの話は
また別だ。Guidoが挙げてるのは静的型に対する見当違いの批判を除けば、ほぼシンタックス
の話なので、割とどうでもよい。

0795デフォルトの名無しさん

2009/11/28(土) 19:01:31

だからそういうのは静的/動的の一般論でしかないと
そっちがマクロがあればScalaの機能は実現できると主張してるわけだから
具体的にやってもらわんと

0796デフォルトの名無しさん

2009/11/28(土) 19:02:38

>>795
誰もそんなことは主張してないけど？
Scalaにない機能をいくらでも付け加えることができるとは言ってるが

0797752

2009/11/28(土) 19:04:36

>>790
じゃあ、やってみなされ。実際に型付きSchemeの処理系あるんだから、マクロ使ってそれをちょっと拡張するくらい
簡単なことでしょ？まあ、普通に考えていずれも型システム全体に影響する話だし、Schemeマクロだと無理だが。

0798デフォルトの名無しさん

2009/11/28(土) 19:04:42

>>796
じゃあ、それでいいんじゃない
Scalaでできないこともあるし、Schemeでしかできないこともある
それが一般論だって言ってるわけで
結局何が言いたいのかわからん

0799デフォルトの名無しさん

2009/11/28(土) 19:05:03

>>794
つまり、型システムに限定しても、反論ができない上に、
型システム以外ではフォローのしようすらないってこと？
何の意味があってそれを一生懸命言ってるのかわからないが
まあ、結論が出たならもういいか

0800デフォルトの名無しさん

2009/11/28(土) 19:06:52

>>797
わかった
そういう処理系があるなら、簡単にできそうだ
その点に関してはやってみてから結論を考えるよ

0801デフォルトの名無しさん

2009/11/28(土) 19:07:26

スレが進んでいると思ったら
能無しSchemerが暴れているだけか

0802752

2009/11/28(土) 19:07:32

>>796
ふーん。じゃあ、
Scheme: マクロでScalaに無い機能をいくらでも付け加えることができるが、静的型システムは実装できない
(型付きSchemeは方言(別言語)だし、マクロ使って書かれたとも書かれて無いから考慮しない)
Scala: マクロは無いが、標準で強力な静的型システムを持ってる
というわけで、単純には比較できないね。

0803デフォルトの名無しさん

2009/11/28(土) 19:08:30

>>798
そして、Schemeの方が言語仕様は小さい
そこから導かれる結論は、Scalaは継ぎ接ぎだらけである
ってことじゃないのか

0804752

2009/11/28(土) 19:10:18

>>799
継ぎはぎという言葉をちゃんと定義しないでテキトーに使うからでしょ？
複雑＝継ぎはぎなんて定義で話してるとは、思いもよらなかったよ。継ぎはぎというと
後から後からよく考えずに継ぎ足していくイメージがあるもんだからさ。

0805デフォルトの名無しさん

2009/11/28(土) 19:10:38

>>803
>>779もそうだけど、論理的な演繹ができないタイプの人間だね、君は

0806デフォルトの名無しさん

2009/11/28(土) 19:11:00

>>802
ドキュメントまで読んだそうだけど比較対象にしないの？
そのSchemeの言語仕様は複雑だったの？
比較すればいいじゃない

0807デフォルトの名無しさん

2009/11/28(土) 19:11:58

>>804
それほぼ同じだろ
後から後からよく考えずに継ぎ足していくから複雑になるんだし

0808752

2009/11/28(土) 19:11:59

>>803
わかっててやってるのかしらんが、>>798の
＞Scalaでできないこともあるし、Schemeでしかできないこともある
は
＞Scalaでしかできないこともあるし、Schemeでしかできないこともある
のtypoでしょ。

0809デフォルトの名無しさん

2009/11/28(土) 19:14:20

>>808
まことに申し訳ない
でもScalaでできないことがあるということがScalaの複雑性の証明にはならない
という意味では元の文でもある意味正しい

0810デフォルトの名無しさん

2009/11/28(土) 19:15:03

>>797
>普通に考えていずれも型システム全体に影響する話だし、Schemeマクロだと無理だが。

当然知ってると思うけど、CLOSやSOSを見てもそう思うの？

0811752

2009/11/28(土) 19:15:39

>>807
後から後からよく考えずに継ぎ足していくならば複雑になるが、
複雑ならば、後から後からよく考えずに継ぎ足していったとは限らない。
論理的に考えて当たり前のことでしょ？よく考えられているけど複雑という
事は往々にしてある。

>>806
型付きSchemeはSchemeとは別の言語だから、比較するなら仕切り直してからだろうと。
あくまで「Schemeっぽい」ってだけだし。

0812752

2009/11/28(土) 19:16:59

>>810
もちろん知ってるけど、あれらは静的型システムとは言えんでしょ？静的型チェック無いし。同列に扱えるとは
とても思えんが。

0813デフォルトの名無しさん

2009/11/28(土) 19:17:36

今日だけで100レスくらい伸びてるのは何なんだ。3行くらいでまとめてくれ。

0814デフォルトの名無しさん

2009/11/28(土) 19:17:37

>>811
そういう意味で言うなら、よく考えられているけど継ぎはぎだらけということも
往々にしてあるように思うのが普通だと思うんだが

0815デフォルトの名無しさん

2009/11/28(土) 19:18:33

>>812
でもマクロは動的なチェックと同様なお手軽さで静的なチェックができるでしょ？

0816デフォルトの名無しさん

2009/11/28(土) 19:19:02

>>813
Scala
継ぎはぎだらけ
主張

0817デフォルトの名無しさん

2009/11/28(土) 19:23:38

結局彼の言う「継ぎ接ぎ」というのが何なのかがわからんのが問題なんだよ
今の話はなぜか型システムの複雑性になってるし
Scalaという文字列をJavaに置換しても全く同じことが言える話ばっかで
複数のパラダイムを融合したゆえの複雑さの話になってない

0818694

2009/11/28(土) 19:24:33

>>704
暗黙の型変換をプログラマが勝手に組み込めるというのは継ぎはぎ感がありますね。
そもそも、静的型システムの目的と矛盾してると思います。
注意深く使うというなら動的に変更できる方が統一感があります。

また、参照透明性/副作用の点も
「varとval両方用意したから好きな方を使えるよ」
という安易な発想も継ぎはぎ感がありますね。

参照透明性/副作用の両方の利点を兼ね備えた
新たな仕組みを作るのではなく、「両方使えるよ」
というのは、実用的かもしれないけど美しくない。

全体にScalaの特徴は、いろんな機能を
「ただ、詰め込んだ」としか思えません。
しかも、それらの機能は他の言語で「便利」とわかっている機能。
「なるほど！」と思える興奮がない。

言語としての優劣ではなく、美しくないと思うだけです。

0819デフォルトの名無しさん

2009/11/28(土) 19:33:35

美しい言語使ってればいいんじゃん？

0820デフォルトの名無しさん

2009/11/28(土) 19:34:17

>>818
暗黙の型変換はそんなに継ぎはぎ感があるかねえ
ポリモーフィズムの一つとして、理解できる拡張なんじゃないかな
具体的な使われ方がJavaの型と合わせるためというのが多くてそう見えるかもしれないが

それに静的型システムと矛盾してるというほど強力じゃないよ
実際使えば、制約がきつくて動的言語ほど慎重になる必要なんてないということがわかると思う

val、varはまさにシンタックス上の問題という気がする
varだけなら継ぎはぎじゃなくなるのかとか

他の言語で便利だとわかっている機能を入れただけだというのは同意するが

0821694

2009/11/28(土) 19:35:06

ああ、すみません。
ここまで話をふっておいてなんですが、
私、Scalaの事、あまり詳しくありませんｗ

何かScala独自の機能があれば教えて下さい。
その機能がすばらしければ、好きになれるかもしれません。

0822デフォルトの名無しさん

2009/11/28(土) 19:35:38

val、varの件はまさしく、Guidoも言ってるHaskellの解決策が
良いっていいたいんだろうね

0823デフォルトの名無しさん

2009/11/28(土) 19:37:49

独自の機能ってのはあんまりないんじゃないの
新しいパラダイムを作る言語でないのは確か

0824デフォルトの名無しさん

2009/11/28(土) 19:38:31

詳しくないものを思い込みで批判するのはネガキャンっていうんじゃないの。

0825デフォルトの名無しさん

2009/11/28(土) 19:38:44

>>819
chinko

0826デフォルトの名無しさん

2009/11/28(土) 19:39:21

>>818
あなたの美意識に興味はないです。
あなたのレスは美しくないのでこれ以上読みたくないです

0827デフォルトの名無しさん

2009/11/28(土) 19:45:25

Scalaはこの数カ月くらいでにわかな人がけちをつける対象としてクローズアップされているかのようだな。

0828デフォルトの名無しさん

2009/11/28(土) 19:45:44

ライブラリ込みならJavaに依存しまくる現状が美しくないというのはその通りだと思うが
今新しい言語を作るとして、Scalaと同等の機能を持ちつつ、
Scalaより美しく作るってのは相当しんどいんじゃないかな
暗黙の型変換とかmutableなところとかを削っていくというならわかるが

0829デフォルトの名無しさん

2009/11/28(土) 19:47:01

っていうか、マクロの本当の意義は、

>>型チェックを網羅的にやろうとすると、関数定義や変数定義は全部独自のマクロで定義したものしか型付けできないみたいなことになって、本末転倒だから。

ここなんだけどな。

コンパイラへ情報を与えることによって、どんな言語にでも化けられるところ。

0830752

2009/11/28(土) 19:47:05

>>814
そういうことも往々にしてあるかもね。で、複雑⇒継ぎはぎだらけだと言いたいの？

>>815
Schemeマクロみたいな、明示的な呼び出しを必要とするマクロはそれだけでは型チェックみたいに
グローバルに作用するチェックは書けない。(typed (+ 1 1))みたいに明示的にラップ
しなくちゃいけなくて台無し。関数定義にしても、そのための専用マクロを用意しなくちゃ
いけない上に、型付けされた関数に普通のSchemeの値をそのまま渡すことはできない
だろうし…。結局、実用的にはマクロだけで作った静的型システムを使おうと思うと
面倒過ぎるのが容易に想像できる。実用性を考えなくて良いのなら、原理的には
もちろん可能だけどね。

0831752

2009/11/28(土) 19:55:42

>>818
個々の暗黙の型変換は継ぎはぎであったりなかったりとあるだろうけど、暗黙の型変換のユーザ定義
という機能自体は継ぎはぎ的には見えない。var/val両方用意したのは、まあ日和ってる感じはあるね。
でも、何かくっつけたわけではないし、どの辺が「継ぎはぎ」？(varが継ぎはぎということかな？)「ただ、詰め込んだ」か
どうかは個人的には異論があるが、まあここは個人の印象なので反論しても仕方ないか。

0832デフォルトの名無しさん

2009/11/28(土) 19:58:54

正直そろそろ他所でやってほしい

0833デフォルトの名無しさん

2009/11/28(土) 20:04:57

そうだね、プロテインだね

0834デフォルトの名無しさん

2009/11/28(土) 20:09:37

未踏Lisp作るほどLispは言語として
優秀だろ？なぜScalaなんて使うんだ？

0835デフォルトの名無しさん

2009/11/28(土) 20:13:49

いやそんな釣りはいらないんだけど

0836デフォルトの名無しさん

2009/11/28(土) 20:31:31

>>813
荒らす人
構う人
皆ヒマ人

0837デフォルトの名無しさん

2009/11/28(土) 20:31:39

痴話喧嘩は余所でやれ

0838デフォルトの名無しさん

2009/11/28(土) 20:35:16

いえ、同族嫌悪ですね

0839デフォルトの名無しさん

2009/11/28(土) 21:06:02

前にHaskellとawkで同じような論調なのを見たな。
もしかして改変ネタなのか。

○○は好きになれません。○○は美しくありません。Haskellなら○○です。
ちなみに○○は詳しくありません。だから○○のいいところを教えてください。
やはり美しいとは思えません。Haskellなら（ｒｙ

0840デフォルトの名無しさん

2009/11/28(土) 21:08:08

それはawkで受けて立った人が凄いｗ

0841デフォルトの名無しさん

2009/11/28(土) 21:13:58

「型システムなんてLispのマクロで」「いやマクロではできないでしょ」っていうやり取りもScalaスレで昔にもみたような。同じ人かな？

0842デフォルトの名無しさん

2009/11/28(土) 21:15:45

一人で自作自演してるかと思ったぜ

0843752

2009/11/28(土) 21:41:24

>>293-339
辺りだな。結局、マクロだと無理か困難ということで決着がついたっぽいけど(一応言っておくけど、
こっちの方の議論は俺は関わってないよ)。

0844デフォルトの名無しさん

2009/11/28(土) 21:48:53

ここでマクロがどうとか言ってるやつは絶対Scheme使ってないんだろうな

0845デフォルトの名無しさん

2009/11/28(土) 21:55:03

Scalaは継ぎはぎということで決着がついたみたいだな

0846デフォルトの名無しさん

2009/11/28(土) 21:56:14

Go＞＞＞＞Scala

0847デフォルトの名無しさん

2009/11/28(土) 21:58:08

>>846
コンパイルスピードの話か

0848デフォルトの名無しさん

2009/11/28(土) 22:05:37

継ぎ接ぎの無さではGoが上だな

0849デフォルトの名無しさん

2009/11/28(土) 22:07:01

まだ言ってるのか
これだけ無知を指摘されて恥ずかしくないのだろうか

0850デフォルトの名無しさん

2009/11/28(土) 22:08:00

>>849
コテンパンに論破されて悔しくないの？

0851デフォルトの名無しさん

2009/11/28(土) 22:10:18

Goは美しい
Scalaは糞だ

0852デフォルトの名無しさん

2009/11/28(土) 22:11:39

休みなのに熱いなぁ、お前等
気に入らなきゃ使わなきゃいいし、改善して欲しければ参加するか、要望出せばいいだけじゃね？

0853デフォルトの名無しさん

2009/11/28(土) 22:12:31

なんか、反論できないかわりにSchemeを攻撃し続けて
見当違いなごまかしをしようとしていた人がいたみたいだな

0854デフォルトの名無しさん

2009/11/28(土) 22:13:05

頭がおかしい奴は独自の語意や新語を何の断りも無しに使う法則が
今回も当たった。

0855デフォルトの名無しさん

2009/11/28(土) 22:15:03

そうだな、人には継ぎ接ぎという言葉の定義の説明を求めるくせに、
自分は最後まで明らかにしなかった人がいたね

0856デフォルトの名無しさん

2009/11/28(土) 22:18:58

>>854
まともな議論になっちゃ困るんだろうな
きっと多少は自覚があるんじゃね

0857デフォルトの名無しさん

2009/11/28(土) 22:19:59

まともな議論では継ぎ接ぎだと決着しちゃったからなあ
なんか独自の新語でごまかすしかないんだろうね

0858デフォルトの名無しさん

2009/11/28(土) 22:22:34

>>857
お前理解できない言葉があったのか
まあ、素直でいいことだ

0859デフォルトの名無しさん

2009/11/28(土) 22:24:30

>>858
本人だけはマトモな言葉だと思ってるから、まぁそういう反応になるよね。

0860デフォルトの名無しさん

2009/11/28(土) 22:24:37

752の言う継ぎはぎの意味は理解できなかったな
独自定義の新語だったからな

0861デフォルトの名無しさん

2009/11/28(土) 22:27:59

>>860
結局「継ぎはぎ」という言葉をあいまいにすることで
詭弁をこねくりまわしてただけだからな
よくこれで半日も粘着しようと思うわ
あまり知識はないけどプログラマっぽいことは言いたいって感じなんだろうな

0862デフォルトの名無しさん

2009/11/28(土) 22:32:46

このスレでNetBeansがいいってレスあったから入れてみたけど、いい所一つもない

0863デフォルトの名無しさん

2009/11/28(土) 22:34:54

継ぎはぎだらけって言うのはね、服のほころびたところなどに
布を当てて繕うことをいうんだよ
つまり、一つの生地で整った服を作っているんじゃなくて、
たくさんの生地・布を使って、足りない部分を補いつつ一つの
服を作り上げてるような様を言うんだよ

オブジェクト指向っぽい機能が足りないからクラスをくっつけよう、
イミュータブルな変数もミュータブルな変数も使いたいから
varとvalをくっつけよう、簡単に書けるようにしたいから～～をくっつけよう
型システムが～～
こういうのを継ぎ接ぎだらけという

0864デフォルトの名無しさん

2009/11/28(土) 22:35:15

>862
Eclipseだと編集すらままならない状態になる事無い？
一回閉じて開き直せば直るけど。

0865デフォルトの名無しさん

2009/11/28(土) 22:35:43

eclipseだと自動整形機能がない

0866デフォルトの名無しさん

2009/11/28(土) 22:37:47

EclipseもNetBeansも欠点ありそうなのだが、何がScala編集の決定版なのかね

0867デフォルトの名無しさん

2009/11/28(土) 22:43:43

>>863
後段が前段の例になってないと思う。
後段で言ってるのは、現在の素材だけでは成し得ない機能を、別の素材を使うことで
実装することについてでしょ？
それだと、「服の前を留めたいからボタンをくっつけよう」なんてのも継ぎ接ぎの一種になるよ。

0868デフォルトの名無しさん

2009/11/28(土) 22:46:57

もうかまうな。

0869デフォルトの名無しさん

2009/11/28(土) 22:49:28

>>866
scala-mode

0870デフォルトの名無しさん

2009/11/28(土) 22:52:01

>>867
ものの例えに例外があるのは常だけど、
その例でいくと、ボタンがないのに前が開いた服を作ること
自体ちょっと考えづらい

0871デフォルトの名無しさん

2009/11/28(土) 22:55:33

>>867
継ぎ接ぎをするということは、現在の素材でなしえない機能を、別の素材を使うことで
実装することでもあるでしょ

0872デフォルトの名無しさん

2009/11/28(土) 22:55:49

>>869
scala-modeはflymakeがfscでも遅すぎて使えないという問題が

0873デフォルトの名無しさん

2009/11/28(土) 22:58:01

>>870
この場合は、前が開く服を作りたいからボタンを導入しよう、みたいな形になるかと。

0874デフォルトの名無しさん

2009/11/28(土) 23:00:19

>>873
それも継ぎ接ぎの例だろうね
普通は生地に対して使うから、継ぎ接ぎとは言わないだけで
概念としては同じものだろうね

0875デフォルトの名無しさん

2009/11/28(土) 23:03:11

>>866
Intellij

0876デフォルトの名無しさん

2009/11/28(土) 23:07:08

Intellijって最近オープンソース化されたんだっけ
使ってみようかな

0877デフォルトの名無しさん

2009/11/28(土) 23:11:40

EclipseはNetBeansに比べて継ぎはぎだらけ

0878デフォルトの名無しさん

2009/11/28(土) 23:15:02

Eclipse最近ダメダメだな
一時はすごい人気だったのにどうしてこうなった

0879デフォルトの名無しさん

2009/11/28(土) 23:15:23

日本人技術者は、中韓に比べて
技術スキルが継ぎはぎだらけ

0880デフォルトの名無しさん

2009/11/28(土) 23:17:03

今Eclipse衰えてるの？

0881デフォルトの名無しさん

2009/11/28(土) 23:24:27

>>880
Eclipseは開発資金枯渇してきて
コミュニティ崩壊しそう

0882デフォルトの名無しさん

2009/11/28(土) 23:25:52

Eclipseって無いよりマシだけど、ゴジャゴジャしすぎなんだよな。
Visual Studioと比べると洗練されていないというか。
使いなれていないのかも知れんが。。

0883デフォルトの名無しさん

2009/11/28(土) 23:29:25

>>882
有償のVisual Studioと比べたら駄目だろ。あれは別格だよ。

0884デフォルトの名無しさん

2009/11/28(土) 23:31:25

Eclipseの方がVSよりマシだろ

0885デフォルトの名無しさん

2009/11/28(土) 23:50:38

長かった。やっと読み終えたよ。次回からは名前付けるなりしてもらえると追いやすくて助かる。
で、読んでて気になったのが一点。
>>823
>独自の機能ってのはあんまりないんじゃないの
implicit conversionはScala独自で相当すごい機能だと認識してた。
これがあるからScalaはExpression Problemが解決できる訳だし、
実際例えばRichStringとかには知らずのうちに結構お世話になってるはず。
implicit conversionって意外と評価されていないのかしら。

0886デフォルトの名無しさん

2009/11/28(土) 23:55:55

それ関数や演算子の多重定義があればさほどいらなくない？

0887デフォルトの名無しさん

2009/11/28(土) 23:55:57

Javaに依存してなきゃ最初からRichStringなんてものはいらんわけで、
なかなかその辺は褒めづらい

0888デフォルトの名無しさん

2009/11/29(日) 00:02:40

RichStringはimplicit conversionを使ってない訳だが

0889デフォルトの名無しさん

2009/11/29(日) 00:08:10

例を挙げるならBigDecimalとか

0890デフォルトの名無しさん

2009/11/29(日) 00:23:13

そんな馬鹿な、と思って2.8のソース見てみたら、
LowPriorityImplicits.scalaでWrappedStringってのに変換されてた、なにこれ
もう2.8のコードやだ、読みづらすぎだろ

0891デフォルトの名無しさん

2009/11/29(日) 01:56:57

>>886
implicit conversionは、既存のクラスに後からメソッドをくっつける手段(いわゆるオープンクラス)の
一種だから、演算子の多重定義とかとは無関係だよ。

>>887
Javaに依存してなくても、既存の手を入れられないクラスに後からメソッドくっつけたいという
需要は存在するわけで、Javaに依存してるせいとも言い切れない。たとえば、Scalaの標準
ライブラリには自分で手を加えられないので、Scalaのコレクションにimplicit conversionで
メソッド足して使ったりする。

0892デフォルトの名無しさん

2009/11/29(日) 01:58:47

あ、Scalaの標準ライブラリには手を入れられないってのは、Scalaの単なるユーザにとって、という
話ね。Scalaの開発者にとっては手をいれられない存在がJavaのクラスになるだけで問題は
同じってのが言いたかったこと。

0893デフォルトの名無しさん

2009/11/29(日) 07:20:40

implicit conversionで実現した機能って、やっぱboxingみたいに重いんだよね？
それとも、特殊な最適化が掛かってたりする？

0894デフォルトの名無しさん

2009/11/29(日) 08:29:13

Scala遅くて使い物にならない
Javaですら遅いのに

0895デフォルトの名無しさん

2009/11/29(日) 08:40:41

いまどき、Javaより速い言語って限られると思うが

0896デフォルトの名無しさん

2009/11/29(日) 09:20:48

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より早い言語なんていくらでも・・・

0897デフォルトの名無しさん

2009/11/29(日) 12:13:59

>>893
私は「boxingみたい」ってのがよく分かってないんだけど、
implicit conversionは、型の変換が必要なときにその型変換にマッチするimplicit defで
定義された関数を一つ挿入する（コンパイル時に）だけなので、
特別重くなることを心配することはないと思う
そもそも暗黙的じゃきゃ自前で書かなきゃコンパイル通らないだけだし、それを自動でやってくれている

0898デフォルトの名無しさん

2009/11/29(日) 13:01:27

>>896
GCCのC, C++, Ada, Free Pascal, ATSだけじゃん

0899デフォルトの名無しさん

2009/11/29(日) 21:24:52

Javaは実行速度云々以前に起動が遅いからヤダ

0900デフォルトの名無しさん

2009/11/29(日) 21:47:33

>>898
機械語やアセンブリ言語も一応言語じゃね？ｗ

0901デフォルトの名無しさん

2009/11/30(月) 01:19:58

>>900
お前が書いても遅いだけだけどなw

0902デフォルトの名無しさん

2009/11/30(月) 07:47:58

>>897
暗黙の型変換によるメソッド呼び出しのたびに、インスタンス生成するって事について、いっているんだと思う。

0903デフォルトの名無しさん

2009/12/04(金) 08:11:05

scala で DI コンテナの使用例ってないのかな？
Java で DI コンテナ使うのに慣れちゃったから、scala でも使いたいけどいまいちパターンがつかめない。
Java と同じように使うってのも、どうも scala の良さを生かせてない気がしてねぇ・・・

0904デフォルトの名無しさん

2009/12/04(金) 14:23:47

2.8っていつ頃出るのですか？
期限は過ぎているように思うのですが。

0905デフォルトの名無しさん

2009/12/04(金) 19:19:56

>>904
まあ、遅れてるけど、2.8.0 beta RC2という謎のリリース番号のが出てきてる辺り、
betaバージョンが公開されるのはもうそろそろという気がする。正式リリースは…
今の調子だとあと半年くらいしないと出ないんじゃないか？

0906デフォルトの名無しさん

2009/12/05(土) 09:55:07

Intelij IDEAは、コミュニティ版が日本語化されないと手が出しにくいなー
どこかで日本語化パッチとか提供されてたりしない？
ちょっと探しただけじゃ見つかんなかったんだけど。

0907デフォルトの名無しさん

2009/12/05(土) 10:58:06

>>906
そうか？英語でも使っているうちに慣れると思うが・・・

0908デフォルトの名無しさん

2009/12/05(土) 11:25:58

コミュニティ版はRubyとか色々と使えないのか。
Maven使ってLiftプロジェクト作れる？

0909デフォルトの名無しさん

2009/12/05(土) 13:55:23

Scalaをアンストした
世話になったな
さがさないでくれよ

0910デフォルトの名無しさん

2009/12/05(土) 14:19:16

つ三くだり半

0911デフォルトの名無しさん

2009/12/06(日) 03:40:54

>>908
Liftはためしていないけど、Maven つかった Scala プロジェクトは動いた。
多少設定がいるかもしれんけど、Eclipse で Scala やるよりかは快適。

0912904

2009/12/06(日) 10:37:42

>>905

ありがとうございます。
当初予定からだいぶ遅れているのですね。
なんか問題有ったんでしょうか？
2.8で結構仕様が変わるという噂を聞いていたので2.8リリースされてから勉強しようと考えていました。
取り敢えずは日本語訳の本が出たので2.7.7で勉強を開始しようと思います。

0913デフォルトの名無しさん

2009/12/08(火) 21:04:00

補完ならIntelliJが一番良さそうだが、まだベータ版なのがちょっとなあ。

0914デフォルトの名無しさん

2009/12/10(木) 08:04:27

>>913
いまのところ、IntelliJ が一番よいのは同意だけど、import 文の自動挿入と整形がいまいちなのが残念。

0915デフォルトの名無しさん

2009/12/10(木) 17:58:29

いつの間にかIntelliJ9の最終リリース版が出てるのか。

0916デフォルトの名無しさん

2009/12/11(金) 20:19:53

simple-build-toolって便利？

0917デフォルトの名無しさん

2009/12/11(金) 21:38:07

maven より手軽らしいよ。

0918デフォルトの名無しさん

2009/12/12(土) 00:03:46

Scalaのビルドツールって何がメジャーなの？
やっぱりmaven？それともIvyに移行したりしてんの？

0919デフォルトの名無しさん

2009/12/12(土) 02:10:06

>>916
Liftもmavenベースからsbtベースに移行しようという意見も出てるらしい
使い勝手という意味では、pure scalaのアプリ作るならmavenより便利だと思う

0920デフォルトの名無しさん

2009/12/12(土) 08:01:22

IntelliJを使ってみたんだがscala.swingパッケージなんかねえ、と言われてしまう。
scala 2.7.7, IntelliJ 9, scala-plugin 0.3.312 でそれぞれ最新のはずなんだが。
ほかに設定があるのかな

0921デフォルトの名無しさん

2009/12/12(土) 10:35:40

>>920
IntelliJは商用版じゃないと動かない
公式が認めてるから諦めろ

0922デフォルトの名無しさん

2009/12/12(土) 13:08:44

>>920
scala.swingはjarファイルが別になってるからたぶんそのせい(IntelliJのデフォルトの
設定では、scala-library.jarしかクラスパス通って無いはず)。scala-swing.jarを
クラスパスに追加すれば動くはず
>>921
何の話かわからんが、オープンソース版でちゃんとscala plugin動くよ。

0923デフォルトの名無しさん

2009/12/12(土) 14:33:12

IntelliJってScala2.7.7使えないの？
直接ライブラリー選択すれば動きそうではあるけど。

0924デフォルトの名無しさん

2009/12/12(土) 21:31:22

>>922
確かにswingのjarにパスが通ってなかっただけみたいでした。
2.7.7のjarを指定しても問題なく動いてます。
ありがとうございます

0925デフォルトの名無しさん

2009/12/13(日) 22:47:13

今日ダウンロードしたんですけど遅いですね・・・
がっかりしました。

0926デフォルトの名無しさん

2009/12/14(月) 02:19:25

遅いって何が？

0927デフォルトの名無しさん

2009/12/14(月) 02:54:22

ダウンロード速度が

0928デフォルトの名無しさん

2009/12/14(月) 02:56:41

すいません
16進数のm56cc82を10進数に直してもらえませんか？

0929デフォルトの名無しさん

2009/12/14(月) 03:04:49

やっとくから、元旦になったらこのスレ見て！

0930デフォルトの名無しさん

2009/12/14(月) 03:20:31

>>929
ありがとうございます。
でも何か悲しいです

0931デフォルトの名無しさん

2009/12/14(月) 07:54:03

mってなんやねん。

0932デフォルトの名無しさん

2009/12/14(月) 14:38:06

minus

0933デフォルトの名無しさん

2009/12/14(月) 19:41:11

Liftの情報少ないな。
基本的に公式のwiki見れば足りるの？

0934デフォルトの名無しさん

2009/12/14(月) 20:12:53

NetBeans6.8がリリースされましたけど、ScalaプラグインはRC1版のものだと
動かないですね...

0935デフォルトの名無しさん

2009/12/14(月) 20:54:41

IDEはどれも今一だな。
もうsbtでいいよ。

0936デフォルトの名無しさん

2009/12/14(月) 21:46:48

>>933
ttp://groups.google.com/group/the-lift-book?pli=1
こんなのもありんす
売ってる本は色々と抜けていて完成度低いらしい、pdfを落としてくると幸せになれるかも

0937デフォルトの名無しさん

2009/12/14(月) 22:01:26

>>936
ありがとう。参考にします。

しかし、売ってる本の完成度が低いってのはどうなんだろうｗ

0938デフォルトの名無しさん

2009/12/15(火) 00:18:13

>>937
文句言いまくれば品質上がるよ？
英語で言えばの話だけど

日本と違って、文句言って素直に聞けない著者は
技術本書く人間として屑というのが常識だから

0939デフォルトの名無しさん

2009/12/15(火) 00:25:43

日本人はやり合って質を高めるというのが苦手だからね。
文句の質も屑。
ノータッチか罵倒かのどっちかになっちゃう。

0940デフォルトの名無しさん

2009/12/15(火) 00:28:35

この掲示板のこと？

0941デフォルトの名無しさん

2009/12/15(火) 01:14:09

Liftアプリは、本読んだ上でMLのログをそれっぽいキーワードで検索すれば
組めると思う。ソースも時々読む必要があるかな？

本体＋サンプルアプリのソースをgrepしても使用例の出てこない関数も
たまにあるね。

0942デフォルトの名無しさん

2009/12/15(火) 11:35:15

ScalaでHaskellのように中置演算子を定義することは可能ですか？
例えば($)のような演算子を作りたいのです。
f $ g $ x

0943デフォルトの名無しさん

2009/12/15(火) 13:29:09

Haskell のようなってのが、関数って意味なら難しい。
中置演算子として使えるメンバメソッドなら、1引数であれば良いだけ。

0944デフォルトの名無しさん

2009/12/15(火) 18:47:06

>>934
そうなのか。暫く6.7使うしかないかな。
IntelliJでもいいけど、CEだと機能的に十分なんだろうか。

0945デフォルトの名無しさん

2009/12/16(水) 14:23:59

>>943 ありがとうございます。つまりHaskellの($)演算子を作るには
class Fun[A,B](f: A=>B) { def $ (x:A) = f x }
のようなクラスを作る必要があるのですね。

0946デフォルトの名無しさん

2009/12/16(水) 23:14:14

>>938
そういう意味じゃないはずだよ・・・
買った人じゃないよな？

同じ本のドラフトが>>936で、
こっちの草稿では、付録や索引がついてたのに
印刷物では、抜けているという・・・・
あとは、プリンターの問題か文字化けしてる記号があったりもする。

この本は、タイトルやページ数が変わってるのに、出版社のページがそのままだったり、
2冊別々に表示されてたり、値段がクロスしてたり、いろいろあったから、
その影響で、出版社の校正素通りか、間引きされて印刷されちゃったのかもしれないね。

0947デフォルトの名無しさん

2009/12/16(水) 23:26:48

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

0948デフォルトの名無しさん

2009/12/17(木) 21:31:37

IntelliJでLiftのプロジェクト作るとboot.scalaで
「Cannot resolve symbol ::」が出る。何で？

0949sage

2009/12/18(金) 20:01:17

最近は Eclipse プラグインって少しはまともになったのかな？

0950デフォルトの名無しさん

2009/12/18(金) 20:10:58

俺も今ちょうどそれを聞きたかった。

0951デフォルトの名無しさん

2009/12/18(金) 23:23:03

ついでにおれも

0952デフォルトの名無しさん

2009/12/18(金) 23:36:30

じゃあ、俺も耳を貸してやるよ

0953デフォルトの名無しさん

2009/12/18(金) 23:49:28

じゃあ俺も俺も・・・って、誰も使ってないのかよっ(w

0954デフォルトの名無しさん

2009/12/19(土) 18:44:07

全然アップデートしてないんじゃないか？
素直にemacs使ってろ

0955デフォルトの名無しさん

2009/12/19(土) 22:43:32

>>949
元がどうだったか知らないけど最近使ってるよ
.scalaファイルを読み込む（エディタに表示する）ときに
謎なエラーダイアログがポップアップしてくる事多数
それ以外は特に困らない
リアルタイムにコンパイルエラーを教えてくれるのは助かるし、
メソッド名の候補が出てくるのも嬉しい
ちなみにVista+eclipse 3.5+plugin最新版

0956デフォルトの名無しさん

2009/12/20(日) 08:50:08

>>948
自己レスだが・・・、Lift 1.1-M8で作ったら
エラーが出なくなったからまあ良しとする。

0957デフォルトの名無しさん

2009/12/20(日) 09:04:34

>>956
と思ったが駄目でした・・・

0958デフォルトの名無しさん

2009/12/20(日) 10:18:25

そんなオチで客が喜ぶとでも思ってるのか！
入場料返せ！

0959デフォルトの名無しさん

2009/12/20(日) 12:17:01

ワロタｗ

おまえら、何でコード書いてるの？
EmacsかVimなの？

0960デフォルトの名無しさん

2009/12/20(日) 12:35:25

とりあえずvim。ビルドはAnt
IntelliJは試してみて、割と使えそうだなと思ってたけどIntelliJの操作に慣れてないので
常用するのはしばらく先になりそう

0961デフォルトの名無しさん

2009/12/20(日) 14:28:45

ためしにIntelliJを使ってみてるが、::がエディタ上でエラー表示になることあるな。
コンパイルは普通に通るので問題ないけど。

ちょっと使った感じだと、NetBeansとくらべてリアルタイムでのエラー表示機能が弱いような

0962デフォルトの名無しさん

2009/12/22(火) 22:33:22

>>961
IntelliJのScalaプラグイン、新しいバージョン出てたから
更新してみたんだけど、その不具合解消されてるっぽい。

0963デフォルトの名無しさん

2009/12/24(木) 19:42:24

Eclipseのプラグインはエラーメッセージ吐きすぎて使えない
NetBeansはあまり補完が働いてくれない気がする
IntelliJはどうなん？

0964デフォルトの名無しさん

2009/12/25(金) 18:50:47

関数型言語を学ぼうと思ってて、haskellとscalaのどちらかじっくりやろうと思ってます。
そこで知りたいんだけど、scalaはどのくらい”関数型言語”よりなんですかね？
scalaをある程度使えるようになったとして、それはすなわち関数型言語を理解出来てること
になるのか、ってところが知りたい。
scalaの方が日本語の情報多そうなんで出来れば使いたいんですけど•••
関数型ってのがあまり分かっていないので変な質問しか出来ないんだけど、
回答してくれるとありがたいです。

0965デフォルトの名無しさん

2009/12/25(金) 19:40:09

>>964
Scalaは関数型でない方法でも書けるから、使えるからと言って関数型を理解したことになるかは微妙
あとHaskellのほうが日本語の情報が多いと思う

0966デフォルトの名無しさん

2009/12/25(金) 21:21:49

関数型言語を学びたいならHaskellの方だろ

0967デフォルトの名無しさん

2009/12/25(金) 21:48:28

>>964
Scalaは関数型言語じゃない。やめとけ。

0968デフォルトの名無しさん

2009/12/25(金) 21:52:33

万能を目指したがどれも半端だった。

0969デフォルトの名無しさん

2009/12/25(金) 21:54:39

Scalaに関数型言語として足りない機能はなによ

0970デフォルトの名無しさん

2009/12/25(金) 21:55:27

>>969
これだから低能は

0971デフォルトの名無しさん

2009/12/25(金) 22:00:08

>>970
プログラム板ってこういうところが嫌だな
まともなプログラミングの話ができない
2chにそういうのを期待しちゃ駄目なのかしら

0972デフォルトの名無しさん

2009/12/25(金) 22:00:48

>>970
これだから博士様は・・

0973デフォルトの名無しさん

2009/12/25(金) 22:16:42

最近のScalaスレだけの傾向じゃないかな。

0974デフォルトの名無しさん

2009/12/25(金) 22:29:57

>>971
うまく共存することを考えなさい

0975デフォルトの名無しさん

2009/12/25(金) 22:33:16

>>967
関数型言語じゃないってのならとりあえずその根拠くらい述べようぜ

0976デフォルトの名無しさん

2009/12/25(金) 22:36:12

>>967
博士様、教えて下さいませ

0977デフォルトの名無しさん

2009/12/25(金) 23:03:23

>>974
そういう小学生みたいな糞レスはいいから、Scalaに関数型言語として足りない機能を書きなよ。

0978264

2009/12/25(金) 23:28:03

>>965
>>966
haskellのほうがより”関数型言語”であることは知っていましたが、
正直なんか難しそうで(モナドがどうとか)、そういう意味でも
scalaでも関数型言語が学べるのならそっちにしようと思っていたんですが•••
RealWorldHaskellを買うかな•••
学びやすさの点でいったらどちらが上ですか？
ちなみにc言語とobjective-cの経験があります。

0979964

2009/12/25(金) 23:29:17

264じゃなくて964だった。

0980デフォルトの名無しさん

2009/12/25(金) 23:30:42

>>978
３Ｐの経験は？？

0981デフォルトの名無しさん

2009/12/25(金) 23:40:41

¿¿

0982デフォルトの名無しさん

2009/12/25(金) 23:47:38

>>978
学ぶならそのパラダイムしか使えない言語のほうがいいと思うよ
HakellよりOCaml系のほうが簡単かもしれない
でも日本ではHaskellのほうが人気があって、情報が多いんだよな
やっぱり関数型ならHaskellが一番かと

0983デフォルトの名無しさん

2009/12/25(金) 23:55:42

「関数型言語の勉強」が目的なら、Schemeが一番だと思うが。

0984デフォルトの名無しさん

2009/12/26(土) 00:17:21

関数型言語つってるのにLisp系勧めるのは詐欺だろ

0985デフォルトの名無しさん

2009/12/26(土) 00:23:49

clojureはLispっぽい関数型、
それとも関数型っぽいLispか

0986デフォルトの名無しさん

2009/12/26(土) 00:38:27

Haskellのモナドで四苦八苦するのが、「関数型言語の勉強」として
正しい姿なのかどうかは疑問だが。

0987デフォルトの名無しさん

2009/12/26(土) 00:43:17

ノマドで四苦八苦するか、Thunkで七転八倒するか
人生それぞれ

0988デフォルトの名無しさん

2009/12/26(土) 00:44:41

モナド＊

0989デフォルトの名無しさん

2009/12/26(土) 01:02:40

C#みたいに中途半端においしいとこだけもらうのがベストってことだな

0990デフォルトの名無しさん

2009/12/26(土) 01:11:26

C#はラムダ式を関数型のように使わせない工夫をしてる節がある。
関数型から直接借用したというより、RubyやPythonのような動的言語から借りてきた。

0991978

2009/12/26(土) 01:31:31

>>982
amazonでRealWorldHaskellを注文したんで、
とりあえずhaskellをやろうと思います。

>>986
調べてみた限り、モナドというのは関数型言語に必要な概念というよりは
”純粋である”ことを実現するために導入した概念みたいですね。
関数型言語を学びたいのであって、その”純粋である”ことにこだわっている
わけではないので、言語としてはOCamlの方がいい気がするんですけどね。
982さんのいうように情報がかなり少ないっぽい•••
モナドで挫折するまでは、haskellでいこうと思う。

0992デフォルトの名無しさん

2009/12/26(土) 01:45:43

Scalaがダメ言語に思えてきた➘➘➘

0993デフォルトの名無しさん

2009/12/26(土) 01:46:35

>>991
> 関数型言語を学びたいのであって、その”純粋である”ことにこだわっている
> わけではないので、

Schemeが目的に合ってるな。Haskell, OCamlでもいいと思うけれども。
たとえそう割りきってもScalaは目的に合ってない。

0994デフォルトの名無しさん

2009/12/26(土) 01:50:56

哲学的な議論はおいといてもScalaはいろいろに書けるから、
関数型的な使い方までたどり着かない。

0995デフォルトの名無しさん

2009/12/26(土) 01:53:26

演習問題じゃなく、すぐに実用アプリを作れないと学習意欲を維持できないって人には、
豊富なJava用ライブラリを呼び出せるScalaが有利かと。

0996デフォルトの名無しさん

2009/12/26(土) 01:59:28

それこそjavaっぽいアプリ作って完結しそう

0997デフォルトの名無しさん

2009/12/26(土) 06:24:22

つーか Scala って Java っぽいアプリをサクサク作ろうって趣旨じゃねーの？

0998デフォルトの名無しさん

2009/12/26(土) 07:22:10

ちょっと次スレ立ててくる

0999998

2009/12/26(土) 07:26:17

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

1000デフォルトの名無しさん

2009/12/26(土) 07:34:04

>>999
乙

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。