プログラミング言語 Scala 7冊目
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2011/09/04(日) 20:07:34.70ttp://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 6冊目
ttp://hibari.2ch.net/test/read.cgi/tech/1307416864/
■Scalaの紹介文（さわり）
Scalaは簡潔かつ優雅で型安全な方法でよくあるプログラミングパターンを表現できるように
設計された汎用プログラミング言語です。
Scalaはオブジェクト指向と関数型言語の特徴をスムーズに統合しておりJavaやその他の言語を扱う
プログラマをより生産的にすることができます。（以下略）
ttp://www.scala-lang.org/node/25
■Scalaに関する書籍（英語）
ttp://www.scala-lang.org/node/959
リファレンスマニュアルや草稿のPDFなども充実しているのでそちらも参照してください。
日本語の資料には、チュートリアルの訳やIBM dW、IT Proの連載記事、各々で開かれた勉強会の資料などがあります。
0357デフォルトの名無しさん
2011/10/22(土) 14:00:01.44連載っていうか、もともとは月刊雑誌の一回だけの特集を、Webに乗せただけ。
日経ソフトウェアの2011年6月号 pp.78-79 が、
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370488/
変数とクラスを学ぶ---Scalaの基本1
同じく pp.85-87が
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370491/
Scalaプログラミングに欠かせない機能---Scalaの基本4
だから、最初から これで完結だよ。
0358デフォルトの名無しさん
2011/10/24(月) 00:33:03.64直接さらしてしまう、という欠点を持っているけど
Scalaではケースクラスにしつつ内部表現を隠蔽することも簡単にできるらしい
これってどういうこと？
0359デフォルトの名無しさん
2011/10/24(月) 08:36:24.45なんかOCamlとかでもできそう。
0360デフォルトの名無しさん
2011/10/24(月) 10:03:50.82内部と外部の境界がモジュールなので、クラスとかに比べたら少し大きい
0361デフォルトの名無しさん
2011/10/24(月) 17:22:44.52ありがたがってる土俵が関数型のプログラミングではあまりありがたみが
ないというのはよく有りそうだよ。
0362デフォルトの名無しさん
2011/10/24(月) 17:53:53.250363デフォルトの名無しさん
2011/10/24(月) 18:15:42.33何を言っているのか理解できないので
くわしく教えて
0364デフォルトの名無しさん
2011/10/24(月) 19:49:26.90をやるなら重宝するんだけど。でもScalaをやってる人のソースを見てるとやっぱり
関数型っぽくないというのかJavaの後継という使い方に見える。
関数型のスタイルでScalaをやってるブログなどがあったらぜひ見てみたいので
英語でもいいし教えてね。
0365デフォルトの名無しさん
2011/10/24(月) 20:13:16.660366デフォルトの名無しさん
2011/10/24(月) 23:01:42.68それも詳しく知りもしないくせに
0367デフォルトの名無しさん
2011/10/24(月) 23:11:28.45いいじゃん別に
disらせとけば
なんか不利益でも被ってんの？
0368デフォルトの名無しさん
2011/10/24(月) 23:20:17.71どうせScalaをdisられたら顔真っ赤にして反論するくせにw
0369デフォルトの名無しさん
2011/10/24(月) 23:31:42.662chの言語スレに来てグダグダいうよりはよっぽど
0370デフォルトの名無しさん
2011/10/24(月) 23:41:40.60ocamlのvariantもモジュールで隠蔽できるから、
たぶんそれ書いた人の勘違いじゃないか？
0371デフォルトの名無しさん
2011/10/25(火) 00:42:22.72たぶん書いた本人です。
>>358はちょっと誤解で、元の発言は
http://twitter.com/#!/kmizu/status/128044795615653888
http://twitter.com/#!/kmizu/status/128045117264248832
これはこれでちょっとわかりにくいですけど、要はパターンマッチ使いたかったら
variantの内部構造さらさなきゃいけないけど、Scalaだとパターンマッチのために
内部構造さらさなくても良いよね、という話です。
Haskellだとviewパターン、F#ならActive Patternがあるので似たような事が比較的簡単に
できますが、少なくともOCamlではvariantの構造をさらさなければパターンマッチング
できない(モジュールにvariantの構造を隠蔽しちゃうと外からパターンマッチングはできない)と
認識しています。もし間違っていたら、文献へのポインタを教えていただけるとありがたいです。
>>364
>>365が挙げてるようにscalaz界隈の人(単なるマニア向けライブラリに見えますが、意外にこれ
使ってるScalaプロジェクトは多いです)はかなり関数型的なスタイルやってますし、sbtも
かなり関数型的なコードになってます。全体的に見て、関数型スタイルでScalaプログラミング
やってる人は以前に比べてかなり増えてる印象です(少なくとも海外は)。
あと、ブログでも、関数型的なスタイルでScalaやってるところは、たくさん見つけられるかと。
@djspiewak さんのブログとか、@jamesiry さんのブログとか、色々ヒットしますよ。
0373デフォルトの名無しさん
2011/10/25(火) 00:58:38.49Int型の値に代入すると怒られるんだが，match文使わずにエレガントに
代入したい．
0374デフォルトの名無しさん
2011/10/25(火) 07:44:36.51variantの構造、で何を指してるのかがイマイチわからない
例があると良いと思う
0375デフォルトの名無しさん
2011/10/25(火) 08:02:14.78あれと同じことをOCamlでやるにはパターンガード使うしか無いけど、
それでパターンマッチできてるとは言わないわな
0376デフォルトの名無しさん
2011/10/25(火) 08:14:15.470377デフォルトの名無しさん
2011/10/25(火) 08:20:26.47(つまり、forall をいろんなところにつけれる)
例えば:
def foo(id : [A]. A => A) : Unit =
id(id)(())
これが普通にできればMLやHaskellより明らかに強力と言えるのではないか。
0378デフォルトの名無しさん
2011/10/25(火) 08:38:11.46ですよねー
0379デフォルトの名無しさん
2011/10/25(火) 08:46:09.53(* データ型の隠蔽 *)
module type S1 = sig
type r
type s
type t = Foo of r | Bar of s
end
(* コンストラクタの隠蔽 *)
module type S2 = sig
type t = private Foo of int | Bar of string
end
(* 幽霊型 *)
module type S3 = sig
type s = Foo | Bar
type 'a t constraint 'a = s
end
0380デフォルトの名無しさん
2011/10/25(火) 11:55:40.54http://martin.jambon.free.fr/mikmatch-manual.html#htoc10
0381デフォルトの名無しさん
2011/10/25(火) 16:32:39.86書いてみた
import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id.apply[Unit])(())
foo(new Forall[({ type X[A] = A => A })#X] { def apply[A] = identity })
0382デフォルトの名無しさん
2011/10/25(火) 17:30:56.34import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id[Unit])(())
foo(Forall[({ type X[A] = A => A })#X](_(identity)))
0383デフォルトの名無しさん
2011/10/25(火) 18:57:12.81ありがと いくつかのブログ漁ってみるよ。
0384デフォルトの名無しさん
2011/10/25(火) 22:36:49.23ファイル入力のSource.fromFileに対応するようなものです。
今はFileOutputStream〜PrintWriterといったJavaのAPIを使ってますが正直面倒です。
0385デフォルトの名無しさん
2011/10/25(火) 22:50:02.400386デフォルトの名無しさん
2011/10/27(木) 08:47:25.77自力でFunction2にラップする？
そういうユーティリティが既にある？
0387デフォルトの名無しさん
2011/10/27(木) 13:41:22.80scala.Function1をimportして
new Function1<Integer,Integer>() { public Integer apply(Integer i) {...}}
とすればよいのではないか。
0388デフォルトの名無しさん
2011/10/27(木) 13:56:12.49ScalaのtraitはJavaのinterfaceになるから、具体メソッドはすべてつぶされてしまう(ヒドス)。
Function1はtraitなのでJavaから便利に使うためにabstract classにする。
==========scala============
abstract class Fun[-A,+B] extends Function1[A,B] {
override def andThen[T](g: (B) => T): (A) => T = this.andThen(g)
override def compose[T](g: (T) => A): (T) => B = this.compose(g)
override def toString(): String = this.toString()
}
0389デフォルトの名無しさん
2011/10/27(木) 13:59:31.00import scala.Function1;
import scala.Some;
public class Main {
public static void main(String[] _args) {
Fun<Integer,Integer> f = new Fun<Integer,Integer>() {
@Override
public Integer apply(Integer n) {
return n+1;
}
};
System.out.println(new Some(3).map(f));
}
}
0390386
2011/10/28(金) 08:38:52.69さんきゅー！
基本は388&389の方針に従った。
scala側は
abstract class Func1[-A,+B] extends Function1[A,B]
で十分みたい。
andThen,compose,toStringは勝手に生成されたよ。
実装のあるtraitをabstract classでextendsしたら
その実装を引き継ぐコードが自動生成されるみたいだね。
(Int)=>Intの関数は、JavaではFunction1<Object,Object>に
見えるらしく、Java側はこんなコードになったけど、
まあ、我慢できる範囲かな。andThenもこのまま使えたよ！
| Func1<Object,Object> f = new Func1<Object,Object>() {
| @Override public Object apply(Object v) {
| return (Integer)v + 1;
| }
| };
ありがと！
0391デフォルトの名無しさん
2011/10/28(金) 11:37:21.630392デフォルトの名無しさん
2011/10/28(金) 19:04:31.14Sourceはなぜこんな非対称な仕様なんだろう…
0393デフォルトの名無しさん
2011/10/28(金) 20:59:19.04どうだろう？
| def using[T](out : OutputStream)(f : Outputstream => T) : T = {
| try {
| val r = f(out)
| out.close()
| r
| } catch {
| e => out.close(); throw e
| }
| }
0394デフォルトの名無しさん
2011/10/28(金) 21:01:17.450395デフォルトの名無しさん
2011/10/28(金) 21:07:42.43usingFile("foo.txt") {
out =>
val w = new PrintWriter(out)
w.println("firstLine")
w.println("secondLine")
}
0396デフォルトの名無しさん
2011/10/28(金) 22:17:31.96out => ってどこから使えるようになったの？
0397デフォルトの名無しさん
2011/10/28(金) 22:43:58.48仮引数だよ。
list.map { a => a+1 }
の a と一緒。
0398デフォルトの名無しさん
2011/10/28(金) 22:47:46.220399デフォルトの名無しさん
2011/10/28(金) 22:49:50.13それなに？まだよくわからん
引数と違うの？
0400デフォルトの名無しさん
2011/10/28(金) 23:15:58.69仮引数ってのは正確な物言いじゃあないかもしらんが、Java でも何でも一般的な概念でしょう。
0401デフォルトの名無しさん
2011/10/28(金) 23:21:54.39つか仮引数とかって基本情報とかに出てきたような過去の記憶が。
0402デフォルトの名無しさん
2011/10/29(土) 08:05:34.67関数を引数として渡すときに #Scala ではしばしば {}で囲って表現する。
someArray.foreach(x => save(x); println(x)) って書くよりも
someArray.foreach {
x =>
save(x)
println(x)
}
って書いた方がDSLぽくてカッコいいでしょ。
0403デフォルトの名無しさん
2011/10/29(土) 09:07:43.26> Function1はtraitなのでJavaから便利に使うためにabstract classにする。
>
> ==========scala============
> abstract class Fun[-A,+B] extends Function1[A,B] {
その目的のためには、scala.runtime.AbstractFunction1が既に標準で用意されている也。
0404デフォルトの名無しさん
2011/10/29(土) 09:24:30.22気になってるのは out が前触れなしに出てきたからでしょ。
これってたとえば 「def add1(a: Int) = a + 1」 の add の直後に出てくる a つまり仮引数と一緒なんですよ。
で、もう最初に気になったあたりを見直すと、
def using[T](out : OutputStream)(f : Outputstream => T)
ってなってて、結果的に usingFile の 2 つめの引数の型は「Outputstream => T」になる。
これは「Outputstream を一つ引数にとり T を返す関数」を要求してることになるから、
(out: Outputstream) => hogehoge....
と書くところを
out => hogehoge...
と書けるわけ。
0405デフォルトの名無しさん
2011/10/29(土) 13:54:53.12def using[T](out : OutputStream)(f : Outputstream => T)
って表記されればわかった。
REPLってなんで定義した関数の型とか引数の情報も
詳しく出してくれないのですか？F#ならでるのですが
0406デフォルトの名無しさん
2011/10/29(土) 23:47:25.13え、嘘、出るだろ！？と思ってやってみたら出たけど、
どういう時に出ないの？
0407デフォルトの名無しさん
2011/10/30(日) 02:18:06.25SIP-12 - Uncluttering Scala's syntax for control structures.
http://docs.scala-lang.org/sips/pending/uncluttering-control.html
(なぜか過去のコメントが見られなくなってしまったようです)
個人的には、利点があまり感じられない上に、
ユーザ定義の制御構造との統一感が無くなるので、
賛成できないのですが。
0408デフォルトの名無しさん
2011/10/30(日) 03:02:51.57他はどっちでもいいかな
0409デフォルトの名無しさん
2011/10/30(日) 09:40:42.29#Scala がますます #Haskell や #OCaml みたいになるな。
しかしあまりJavaと離してしまうと、Javaユーザーが導入しづらくなり、
ポストJavaの立場がやばくなるのでは。scalaユーザが増えてほしい俺としては
ちょっと反対。
0410デフォルトの名無しさん
2011/10/30(日) 09:51:31.15その#は何？
0411デフォルトの名無しさん
2011/10/30(日) 09:54:00.13個人的には、もっと早いタイミングで導入するのならアリだった。
シンタックスがよりJavaっぽくなくなってしまうことはそれほど問題じゃないと思う。
ただ、2.10のタイミングで、こういう、言語の表現力を上げるわけでもない「些細な」
構文的変更入れてしまうのは、反対というか遅すぎるな。
まだSIPの段階なんで入ると決まったわけじゃない。提案者が
Odersky先生ではあるけれど、まだpendingだし、MLで反対票が
多ければ入らない可能性も十分ある(2.8のときに、Seq -> Sequence
の名前変更が、反対が多くて断念したという実例とか)。
今は当時よりもScalaを実用で使ってるユーザが増えてるので、幅広く
意見集めれば反対票も出てくるのでは、と思う。
0413デフォルトの名無しさん
2011/10/30(日) 11:10:07.78Javaユーザが敬遠してしまう要因を増やすことになると思うがそれはよい？
JavaユーザがScalaへ移行することは重要ではないと言っている？
最初の問いについては、元々Scalaの構文はJava互換でないので、>>407くらいの
変更が入ったところで、敬遠する要因が増えるかというとそんなに変わらないのでは、というのが自分の考え。
ただ、「2.10のタイミングで」これを入れるのは、Scalaへの移行を検討しているJavaユーザを遠ざける
要因になり得るので、反対(既存の構文がすぐに使えなくなるわけではないにせよ、
しばらく、旧構文と新構文を使ったコードの両方が出てきて、無用な混乱を招きそう)。
二つ目の問いについては、重要だと思っている。だからこそ、SIP 12に対しては反対。
なら行動起こせよ、と言われそうなので、説得力のある反論をまとめて、>>407のページに
コメントする事は検討中。
0415デフォルトの名無しさん
2011/10/30(日) 12:20:19.45お前も然るべきところで意見できるように精進しろよ＾ｗ＾
0416デフォルトの名無しさん
2011/10/30(日) 12:31:12.240417デフォルトの名無しさん
2011/10/30(日) 13:17:07.97できれば導入して欲しいな。
せっかく一引数関数のかっこを不要にしてるんだから。
0418デフォルトの名無しさん
2011/10/30(日) 15:46:25.800419デフォルトの名無しさん
2011/10/30(日) 16:42:09.31Javaなんて忘れて新しい秩序をつくるんだ
0420デフォルトの名無しさん
2011/10/30(日) 16:45:16.71未だにJavaで満足してる奴はもう切り捨て！いらね！
というわけで「Javaっぽさ」という視点はもうScalaには不要
0421デフォルトの名無しさん
2011/10/30(日) 20:38:06.81カッコは必ず書く派としては賛同できんな。
言語仕様として「できる」ようにする事には必ずしも反対ではないが、原則は書くべき。
0422デフォルトの名無しさん
2011/10/30(日) 20:49:46.820423デフォルトの名無しさん
2011/10/30(日) 21:53:06.95現在の
if (expression) expression else expression
という構文は廃止して
if expression then expression [else expression]
という構文になるってことか。
ただ、expression の外側に "( )" をつけてもそれはexpression だから、
if ( expression ) then expression [else expression]
はOKなんだよね？
つまり、then 必須になるってこと？
0424デフォルトの名無しさん
2011/10/30(日) 22:23:50.380425デフォルトの名無しさん
2011/11/04(金) 10:06:39.96scala.swingのフレームに張り付けるなんてことは可能でしょうか？
scala.swingは薄いラッパーといわれているので、Javaとまぜて使えないかと期待してます。
0426デフォルトの名無しさん
2011/11/05(土) 15:30:38.80できるよー。scala.swingのコンポーネントには、peerというメソッドがあって、対応するSwingの
コンポーネントを取り出すことができる。
val panel : scala.swing.Panel = ...
val peer = panel.peer
みたいな感じで
0427デフォルトの名無しさん
2011/11/05(土) 16:12:50.58横からだけど便利だな〜
objectにしておいてくれたほうが良かった気がするけど。
何か理由があるのかな？
0428デフォルトの名無しさん
2011/11/05(土) 21:19:41.59ありがとうございます。
私のやりたかったこととは逆（scalaで書いていた部品をJavaに取り込む方法ですよね？）
ですが、便利そうです。
なお私のやりたかったことはwrapでできるということがわかりました。
0429デフォルトの名無しさん
2011/11/07(月) 01:00:13.70もうScala不要じゃね？
0430デフォルトの名無しさん
2011/11/07(月) 01:13:52.900431デフォルトの名無しさん
2011/11/07(月) 03:15:48.89? extends とか読めない
Scalaのほうが良いと思う
0432デフォルトの名無しさん
2011/11/07(月) 07:32:22.170433デフォルトの名無しさん
2011/11/07(月) 10:58:20.13これぐらいしかnewsがないな。
xtext2.1リリースで、xtendもバージョンアップしたのかな？
http://www.infoq.com/jp/news/2011/06/xtext-20
0434デフォルトの名無しさん
2011/11/08(火) 14:15:14.590435デフォルトの名無しさん
2011/11/08(火) 14:21:55.62val predicate = [ Person person | "Hans" == person.name ]
0436デフォルトの名無しさん
2011/11/08(火) 17:42:24.870437デフォルトの名無しさん
2011/11/08(火) 19:57:24.06もちろん皆 vimだよな？！
0438デフォルトの名無しさん
2011/11/08(火) 23:03:23.170439デフォルトの名無しさん
2011/11/08(火) 23:05:28.630440デフォルトの名無しさん
2011/11/09(水) 00:10:47.06JetBrainsのKotlin といい、 ほとんど同じような言語開発する暇あったら、
Scala を手伝ってやれよ、って思ってしまう。
言語ばっかり乱立しても、共倒れするだろうに。
0441デフォルトの名無しさん
2011/11/09(水) 00:19:08.57JVM上のbetter javaのCeylonやKotlinとはちょっと意味合いが違うと思う。
0442デフォルトの名無しさん
2011/11/09(水) 00:27:54.68Javaのシンタックスシュガーに徹するんならJSRにのせたりしないのかね。
0443デフォルトの名無しさん
2011/11/09(水) 00:59:45.83仕様は日和っているわりに、これから実装しますとか実用性もない状態で、誰が使おうと思うのだろう
0444デフォルトの名無しさん
2011/11/09(水) 03:11:09.070445デフォルトの名無しさん
2011/11/09(水) 06:07:14.92Scalaより単純で実用的と言ってるんだから、使える標準ライブラリとひとまとめにしてさっさと公開すればよいのにね
結局、現時点でScalaの方が基本インフラ整ってる分実用性が高いとか皮肉すぎる
0446デフォルトの名無しさん
2011/11/09(水) 06:33:03.79発想が「ぼくのかんがえた さいきょうの Better Java」だから、だろうねぇ。
0447デフォルトの名無しさん
2011/11/09(水) 10:14:51.22http://www.infoq.com/jp/news/2011/11/xtext21
scalaこれで実装したら遅くなるんだろうな
0448デフォルトの名無しさん
2011/11/09(水) 23:00:13.38理想と現実の妥協点がよく考えられてるんだけど、後発のおいしい所取り狙ってる言語は、
なんかよくわからずにテキトーにScalaの一部分持ってきてるだけに見えるんだな
0449デフォルトの名無しさん
2011/11/10(木) 00:58:45.17あんまり学会発表しなくなった？
http://www.scala-lang.org/node/143
0450デフォルトの名無しさん
2011/11/10(木) 01:10:23.66もしかして、こっちで少し指導してる？
並列とDSLだね。（C++テンプレート使った奴が何年か前かなり流行ってた。最近はHaskellとかも）
0451デフォルトの名無しさん
2011/11/12(土) 05:41:40.07よりなだらかになったと考えるべきじゃね。だから Scalarはむしろ
xtendを大歓迎すべきだと思う。そしてxtendに新しい機能が追加される
度に「あーそれ2年前にやったわー」と言っておけばよい。
問題はむしろJavaがいつまでも使われ続けること。
0452デフォルトの名無しさん
2011/11/12(土) 06:33:46.170453デフォルトの名無しさん
2011/11/12(土) 06:43:17.48単体テストしたりコミットしたりするだろ？それを考えると
そこまで大差ないと思うんだが。
0454デフォルトの名無しさん
2011/11/12(土) 06:52:33.300455デフォルトの名無しさん
2011/11/12(土) 12:52:56.770456デフォルトの名無しさん
2011/11/12(土) 13:50:53.98■ このスレッドは過去ログ倉庫に格納されています