関数型プログラミング言語Haskell Part10

関数型プログラミング言語Haskell Part10 at TECH

1:デフォルトの名無しさん
09/01/14 00:51:13
haskell.org
URLﾘﾝｸ(www.haskell.org)

日本語サイト
URLﾘﾝｸ(www.sampou.org)
URLﾘﾝｸ(www.shido.info)

過去ログ
関数型プログラミング言語Haskell
Part1 URLﾘﾝｸ(pc.2ch.net)
Part2 ｽﾚﾘﾝｸ(tech板)
Part3 ｽﾚﾘﾝｸ(tech板)
Part4 ｽﾚﾘﾝｸ(tech板)
Part5 ｽﾚﾘﾝｸ(tech板)
Part6 ｽﾚﾘﾝｸ(tech板)
Part7 ｽﾚﾘﾝｸ(tech板)
Part8 ｽﾚﾘﾝｸ(tech板)
Part9 ｽﾚﾘﾝｸ(tech板)
・2chの仕様により、行頭の半角スペースは表示されません。
　コードをインデントしたいときは、代わりにまたは全角スペースを使うことができます。

2:デフォルトの名無しさん
09/01/14 00:51:48
関連書籍
・Introduction to Functional Programming Using Haskell
　URLﾘﾝｸ(www.amazon.co.jp)
・Haskell: The Craft of Functional Programming
　URLﾘﾝｸ(www.amazon.co.jp)
・The Fun of Programming
　URLﾘﾝｸ(www.amazon.co.jp)
・The Haskell School of Expression: Learning Functional Programming Through Multimedia
　URLﾘﾝｸ(www.amazon.co.jp)
・入門Haskell
　URLﾘﾝｸ(item.rakuten.co.jp)
・ふつうのHaskellプログラミング
　URLﾘﾝｸ(item.rakuten.co.jp)
・Programming in Haskell
　URLﾘﾝｸ(www.amazon.co.jp)
・Real World Haskell
　URLﾘﾝｸ(www.amazon.co.jp)

3:デフォルトの名無しさん
09/01/14 00:52:14
関連スレ
・関数型言語Part IV
　ｽﾚﾘﾝｸ(tech板)
・【数学者】Haskellはクソ言語【オナニー】
　ｽﾚﾘﾝｸ(tech板)
・純粋関数型言語Concurent Clean
　ｽﾚﾘﾝｸ(tech板)
・関数型言語ML(SML, OCaml, etc.), Part 5
　ｽﾚﾘﾝｸ(tech板)
・Lisp Scheme Part25
　ｽﾚﾘﾝｸ(tech板)
・【入門】CommonLispその4【質問よろず】 --DAT落ち、次スレなし
　ｽﾚﾘﾝｸ(tech板)
・Emacs Lisp 3
　ｽﾚﾘﾝｸ(tech板)

4:デフォルトの名無しさん
09/01/14 00:52:45
・日本語の扱いについて

Haskell98によると、Charは一つのUnicode文字を表す(6.1.2)。
これに従って、比較的新しいHugsやGHC(6.4系を含む)ではCharは32ビット整数になっている。
ただし、どちらも入出力に際しての変換が完全でない。具体的には、
・ソースコード中の文字列リテラル
・System.IOライブラリでの入出力
が問題になる。

1. GHC6.4.2以前
ソースコード・入出力ともLatin-1を仮定する。Latin-1ではバイト値と
コードポイントが一致するので、入力時には外部エンコードの各バイトがそのままCharに
入り、出力時にはCharの下位8ビットのみが出力されるような実装になっている。
このため、あるエンコーディング(Latin-1とは限らない)の入力をgetLineで受け取り、
それをそのままputStrで表示すれば、入力時とおなじエンコードにおいて正しく表示される。
これを利用して、[Char]を、本来のコードポイントの列としてではなく、特定のエンコードの下での
バイト列として使うことができる。ただし文字列リテラルについては、GHCはLatin-1として
不正な文字を受け付けないので、EUC-JPのような例外を除くと、単純にリテラルを使うことはできない。

2. GHC6.6
ソースコードにはUTF-8、入出力にはLatin-1を仮定する。このため、EUC-JPでリテラルを直に
書くことはできない。

(続く)

5:デフォルトの名無しさん
09/01/14 00:53:10
(続き)

3.最近のHugs(非WindowsかつCのwchar_tがUnicodeの環境、というかLinux)
ソースコード・入出力ともロケールのエンコードを利用する。

4.最近のHugs(Windows)
ソースコード・入出力ともLatin-1を仮定する。ただし文字列リテラルにShift-JISを使ってもエラーにならない。

5.最近のHugs(それ以外)
未調査。

・結局どうするか。
規格どおりにCharにUnicodeを入れるか、Charを単なるバイトとして扱うかの二択。

i. CharをUnicodeとして扱う
(3)以外の場合入出力で変換が必要。(2)または(3)以外の場合文字列リテラルでは
明示的なエスケープ(たとえば"\22234")が必要。

ii. Charをバイトとして扱う
(3)ではファイルをバイナリモードで開くなどの対策が必要。(1)でEUC-JPを使う場合と(4)
を除き文字列リテラルでは明示的なエスケープ(たとえば"\143\153")が必要。
lengthやisAlphaのような関数、およびwin32パッケージの関数(win32API)が正しく動作しない。

6:デフォルトの名無しさん
09/01/14 00:53:44
　　　　　　　／/
　　　　　／　 /　　　ﾊﾟｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ　まピョーん☆
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

7:デフォルトの名無しさん
09/01/14 00:54:06
前スレ11 ：デフォルトの名無しさん：2008/05/17(土) 20:00:31
そろそろ、テンプレの GHC 6.6 の日本語の取り扱いについて書き改めて欲しい。
1. ソース中の文字列 hello = "こんにちは" :: String は UTF-8
2. これを ghci で表示することは可能：(ただし、環境変数 LANG を UTF-8 にしておくこと、
また、ターミナルも UTF-8 で入出力できるようにしておくこと)
Main> print hello
こんにちは
Main>
3. 入出力 IO は Latin-1 だが、
package utf8-string (URLﾘﾝｸ(code.haskell.org))
を導入することにより、入出力を UTF-8 にすることができる
4. その他の文字列エンコード(ShiftJIS, JIS, EUC-JP など) は、
package iconv (URLﾘﾝｸ(hackage.haskell.org))
で UTF-8 な文字列にする
とまあ、こういうことで、日本語表示できるわけだ。iconv package は MacOSX と *BSD では
cabal を少しいじらなければいけないことに注意しろよ(iconv.cabal のコメントに書いてある)
よろしくたのむ、な。

8:デフォルトの名無しさん
09/01/14 00:56:06
テンプレここまで。
関連書籍に二冊追加。
Unicodeの入出力について、誰かまとめてくれるとうれしい。

9:デフォルトの名無しさん
09/01/15 18:24:13

　　　　　　　　　　　　　　　　　　　　　　　　　刀、　　　　　　　　　 , ヘ
　　　　　　　　　　　　　　　　　　／´￣｀ヽ／: : : ＼＿＿＿＿＿／: : : : ヽ、
　　　　　　　　　　　　　　,.　-‐┴─‐- ＜＾ヽ、: : : : : : : : : : : : : : : : : : : : : : }
　　　　　　　　　　／: : : : : : : : : : : : : :｀.ヽl____: : : : : : : : : : : : : : : : : : ／
　　　　　,.　-─「｀: : : : : : : : :　:ヽ: : : : : : : : :＼｀ヽ￣￣￣フ: : : : :／
　　　／: :.,.-ｧ: : : |: : : : : : : : :　　　 :＼: : : : :: : : :ヽ　＼　／: : : :／
　　　￣￣／: : : : ヽ: : : . . . . . . . . . . .､＼=--: : : :.i　／　/: : : : :/
　　　　／: : 　　　 ∧: ＼: : : : : : : : : : ヽ: :＼: : : 〃}/　　/: : : : :/　　　　　　　　、
.　　　 /: : /　　. : : :! ヽ: : l＼_＼／: : : : :＼: ヽ彡: : |　　/: : : : :/　　　　　　　 |＼
　　　/: : ｨ: : : : :.i: : | 　＼!___／ヽ:: : : : : : :＼|:.:.:.:/:!　 ,': : : : /　　　　　　　 |: : ＼
　　 / ／ !: : : : :.ト‐|-　　ヽ　　　　＼: : : : : l::::__:' :/　 i: : : : :{　　　　　　　　 |: : : :.ヽ
　　 l/ 　 |: : :!: : .ｌ: :|　　　　　　　　　＼: : : l´r. Y　　 {: : : : :丶＿＿＿＿＿__.ノ: : : : : :}
　　　　　 l: : :ｌ: : :ﾄ､|　　　　　　､＿__,ィヽ: :| ゝﾉ　　 '.: : : : : : : : : : : : : : : : : : : : : : ／
　　　　　 |: : :ﾄ､: |: :ヽ ___,彡　　 ´￣´　　ヽl-‐'　　　　＼: : : : : : : : : : : : : : : : : : イ
　　　　 !: :从ヽ!ヽ.ﾊ=≠'　, /////　///u /　　　　　　　　￣￣￣￣￣￣￣￣
　　　　　　V　ヽ|　　 }///　 r‐'⌒ヽ　　イ〉、
　　　　　　　　　　　　ヽ､______ｰ‐‐' ィ´　/:/:7rt‐---､　　　　　　　こ、これは>>1乙じゃなくて
　　　　　　　　　　　　　　　　　　ィ幵ﾉ　./:/:./:.! !: : : : :!｀ヽ　　　　　ポニーテールなんだから
　　　　　　　　　　　　　　r‐'T¨「 |: | !:.∨:/:./: :| |: : : : .l: : : :＼　　　変な勘違いしないでよね！
　　　　　　　　　　　　 /: : .|: :|　!:.!ィ¨¨ヾ、:.:/　!: : : : l: : : : : :.＼

10:デフォルトの名無しさん
09/01/17 15:11:50
今Emacs使ってHaskellやってますが、引数の型とかに合わせた候補リストみたいなの
出す機能があるエディタってありますでしょうか。

11:デフォルトの名無しさん
09/01/17 15:40:04
>>10
emacsでも出来た気がするけどね。
なんていうモードだったか忘れたけど。

viでもjeditでも出来るよ。
jeditはわりと惜しいエディタでもある。java製だし、プラグインのAPIは洗練されてないし、不安定だし、という理由で。

12:デフォルトの名無しさん
09/01/17 17:21:47
>>11
emacsのhaskell-modeは使ってますけど、型から候補を出したり補完したり
するのは知りませんでした。

13:デフォルトの名無しさん
09/01/17 17:42:09
viで出来るってのも初耳なんだが、どうやるの？

14:デフォルトの名無しさん
09/01/17 21:43:26
vim にはプラグインがあったような。詳細は覚えてないけど、ググればすぐ見つかるはず。

15:デフォルトの名無しさん
09/01/17 23:30:53
haskell for vim のことを言ってるのであれば
そんな高度なことは出来なかった気が

16:sage
09/01/19 12:26:27
>>11
最新の haskell-mode for Emacs には hoogle と hayoo 用のインターフェースがついてる。
ネット経由で、型から関数の一覧をとってこれる。今、試したら hayoo はお休み中みたいだが。
ここ参照な。

Haskell mode for Emacs - HaskellWiki
URLﾘﾝｸ(www.haskell.org)

hoogle
URLﾘﾝｸ(www.haskell.org)

hayoo
URLﾘﾝｸ(holumbus.fh-wedel.de)

17:デフォルトの名無しさん
09/01/28 12:38:00
初心者質問ですが、derivingというのは特定classのみ許される仕様なんでしょうか。

自分でderivableにする方法ってありますか？

18:デフォルトの名無しさん
09/01/28 20:36:35
Haskell98にはない
GHC拡張に似たようなものがある
URLﾘﾝｸ(www.haskell.org)

19:17
09/01/28 22:35:28
>>18
ありがとうございます。拡張なんですねぇ。頑張って理解してみます。

Javaなどの言語をやってきたんですけど、同じ関数名で引数の型が
相違するようなのを簡単に作れないのかなぁ、と思ったのです。組み込み
のclass(Eqなど)で通常は十分、ということなんでしょうかね。

20:デフォルトの名無しさん
09/01/29 00:00:02
>同じ関数名で引数の型が相違するようなのを簡単に
Javaのどういうコードが念頭にあるのか分からんけど、
もし実装の継承がしたいということなら>>18は大して訳に立たないと思う
手でインスタンス宣言を書くしかないんじゃないか

21:デフォルトの名無しさん
09/01/29 00:47:19
単にオーバーロードのことを言ってるように思えるのだが
どっちにしてもderiving関係なくね

22:17
09/01/29 20:03:34
すみません、ちょっと曖昧でした。オーバーロードではなくて、
多相な関数を定義する簡易的な方法についての質問です。

>>18というのは、Lispのマクロ的なものなんでしょうか。

23:デフォルトの名無しさん
09/01/29 22:04:42
本当にderivingが使える型クラスを作りたいなら>>18でいい(ただしできることは限られる)んだけど、
>>19や「多相な関数を定義する簡易的な方法」を聞くと違うような気がする
(Javaにはderivingに相当する機能はないよな？)
なにか具体例を見せてくれれば分かると思うが

derivingの意味を誤解してるかもしれないので念のためまとめると、
・Haskellの型クラスはインタフェースを表現する(Javaのinterfaceみたいに)
・ある型クラスの規定するインタフェースについて、個々の型における具体的な実装を書くのがインスタンス宣言
・定型的なインスタンス宣言を自動生成する機構がderiving

>>18のは、自分で定義したクラスに対してこの自動生成を可能にする方法の一つ
構文的にはderivingというキーワードを使わないけど、やってることは同じ

24:デフォルトの名無しさん
09/01/29 23:07:40
存在型(forall)のことかな？

25:デフォルトの名無しさん
09/01/30 07:46:36
>>22
多相な関数って、例えばこんな関数？

id :: * -> *
id x = x

26:17
09/01/30 11:24:58
>>23
ありがとうございます。どうもJavaのイメージとごっちゃになってる
部分があって、勘違いしてるような気がしてきましたw

型ごとに振る舞いが違う関数であれば、個別にinstanceしなければ
ならないでしょうし、そうでなければ>>25のような形になるわけですね。

27:17
09/01/31 12:06:49
もう一つclass関連での疑問なのですが、そもそも、オーバーロードが必要な場合
には逐一class宣言とinstance宣言が必要だ、というのは何か必然性があるんで
しょうか。class書いてもいいけど、書かなくても裏で同様のつじつま合わせをして
くれてもいいように思えるのですが。

28:デフォルトの名無しさん
09/01/31 14:01:03
>>27
つじつまあわせなんてしたら型推論なんてできなくなる。

型推論は、関数のこの引数はこの型じゃなければならないから･･･
みたいなことを繰り返して型を確定していくのに、
すべての関数がオーバーロードされているかもしれないんじゃ、
型を確定させることができない。

そもそもJavaなどで簡単にオーバーロードができるのは、
引数として渡される値の型が簡単に分かるから。
引数として渡される値の型と、オーバーロードされている関数の型を比較すれば
実際に呼び出すべき関数が簡単に分かる。
しかし、型推論のある言語では、型が簡単には分からないので、
class,instance宣言必須という制限をつけて範囲を限定している。

29:デフォルトの名無しさん
09/01/31 14:26:12
Java的な意味でオーバーロードがしたい場合は単に違う関数名を付けるのが普通
Haskellの型クラスは実行時多態を行うためにある

用語がややこしいけど、
Haskellでいうオーバーロード(クラスを使う) <=> Javaでいうポリモーフィズム
Javaのオーバーロードに対応する機能はない

30:17
09/01/31 14:37:11
>>28
> つじつまあわせなんてしたら型推論なんてできなくなる。

ああ、そうでした。型推論の問題なんですね。納得です。

>>29
> Java的な意味でオーバーロードがしたい場合は単に違う関数名を付けるのが普通

やはりそうなんですね。自分はコード書く際に名前付けるのが一番悩んでしまう
ので、その辺がスッキリならんのかなぁと思ったのですが。そこは仕方ないんですね。

どうもありがとうございました。

31:デフォルトの名無しさん
09/02/05 02:48:48
日本人待望のGHC用Unicode入出力のパッチが来てるな
テスト希望、議論希望、それからWindowsで動かせるようにしてくれたら嬉しいだとさ
URLﾘﾝｸ(www.haskell.org)

32:デフォルトの名無しさん
09/02/05 18:20:14
utf8-string てのが前からあったでしょ？なんか変わったの？

33:デフォルトの名無しさん
09/02/05 18:57:29
普通のStringを普通にputStrして普通に文字が出る
外部コードもUTF-8固定じゃなくて選べるし、デフォルトでロケールに合わせてくれる

34:デフォルトの名無しさん
09/02/07 20:44:03
各種schemeインタプリタのようなaproposはghciにもありますか？
これがあるとシンボルの入力補完のシステムとかが楽に組めて便利なんですが

35:デフォルトの名無しさん
09/02/07 21:09:03
ghciのUIにはないと思う
ghciに補完機能がある以上内部では持ってるはずだから、
やりたいことによってはGHC APIが役に立つかも

36:デフォルトの名無しさん
09/02/09 20:19:27
ちょっと前に2chで関数型ユーザーを叩いてみたのだけど、
やっぱり関数型の内実は80%ほどが幻想だな、という感想を持った。
Lisp,Schemeのユーザーはすぐ折れたがHaskellのユーザーは頑固だった。
まあ純粋で美しいから信者になってしまったのだろうけど、
純粋な美しさでHaskellに勝てるものはいないだろうと思う。
しかし自然言語を目指さず数学的な記述を目指したところでいいプログラムは書けない。
数学は定理を証明するための言語で、プログラミングは定理の証明ではない。
証明出来るならプログラムなんか書く必要ないしな。

37:デフォルトの名無しさん
09/02/09 20:28:06
curry howard correspondence

38:デフォルトの名無しさん
09/02/09 20:29:09
あぁ、あとこのスレは過疎もいいところだから関数型言語叩くならhaskell-cafeにおいで

39:デフォルトの名無しさん
09/02/09 20:46:24
このスレは過疎な訳じゃなくて話題がないだけだろ
見てる奴は多いだろうからいいネタがあれば盛り上がると思うぜ

40:デフォルトの名無しさん
09/02/09 20:52:12
そういやCleanって最近話題聞かないな

41:デフォルトの名無しさん
09/02/09 22:40:16
>>36
Haskellユーザーとは痛み分けだったろ。それにSchemeのほうも一年以上
かかってたじゃねぇか。

42:デフォルトの名無しさん
09/02/09 22:41:35
Haskellの強みを論理的に教えてください。

43:デフォルトの名無しさん
09/02/09 23:15:21
あなたにとっての「強い」を論理的に説明してください

44:デフォルトの名無しさん
09/02/09 23:17:24
>>43
あなたはもう発言しなくてよろしい

次の方どうぞ

45:デフォルトの名無しさん
09/02/09 23:26:37
>>42
チューリング完全なら、ぜんぶ同じでは？

46:デフォルトの名無しさん
09/02/09 23:27:20
瞬殺された>>42が朝まで暴れるとみた

47:デフォルトの名無しさん
09/02/09 23:28:39
>>36は勝利宣言だけかいｗ

48:デフォルトの名無しさん
09/02/09 23:30:41
難しい話じゃなし、疑問があるなら勉強すればいいんだよ
絡みたいだけの奴はやっぱスレに張り付いてんだなあ

49:デフォルトの名無しさん
09/02/09 23:34:37
>>48
言わせてもらいますが、
Haskellの強みをはっきり書いた論文も書籍もありませんよ。

50:デフォルトの名無しさん
09/02/09 23:36:40
関数型言語はなぜあなたのコンプレックスを刺激するのか論理的に説明してください

51:デフォルトの名無しさん
09/02/09 23:39:39
モナドのすべてにでてくる各種モナドがイミフだったから
あれらの定義を仕様を表す論理式から導き出せるようになりたい
使ってるうちに解るとは到底思えないぐらいイミフ

52:デフォルトの名無しさん
09/02/09 23:41:39
IOモナドが意味不明だったので、Lispも糞だと結論付けました

53:デフォルトの名無しさん
09/02/09 23:44:38
攻撃的な発言は発言した内容が自分自身にそのまま当てはまると内心で思っている証拠だということに最近気づいたところなんだよ。

54:デフォルトの名無しさん
09/02/09 23:49:37
だから相手を攻撃するということは自分自身の弱さを曝け出すことにもなるんだよ。

55:デフォルトの名無しさん
09/02/09 23:54:31
こういう話題になると
今までみんなどこに居たんだと思うぐらいレスが付くなあ

56:デフォルトの名無しさん
09/02/10 00:12:59
>>45
全然話の流れと関係ないとこで気になったんだが
チューリング完全なら全部一緒という論調ってどこか違和感がある

CのプリプロセッサとCはどちらもチューリング完全性だと思うが
単純に構文糖衣という意味以上に、能力的にはCのほうが高いと思う。
スケーラビリティの点で。
Cで関数引数nに、簡単に大きな引数を指定出来るのに対し
プリプロセッサで同じことをやろうとすると、
大きな引数nの値と同じ数だけ自分でデータを作る必要が
あったように思う

そういう意味でプログラム自身をデータと見なせるLispは
かなりスケーラビリティ的な意味で能力が高いと思うわ
しかし、プログラム自身をデータと見なせるだけでは
まだスケーラブルにならない世界もあるんじゃ無かろうか
うまく説明できんが、
自然数→整数→実数→複素数の進歩のように

57:デフォルトの名無しさん
09/02/10 01:12:25
どうでもいいところに突っこむが、Cプリプロセッサのための任意長整数ライブラリは存在するよ
URLﾘﾝｸ(sf.net)
とか

58:デフォルトの名無しさん
09/02/10 01:36:36
>>36
Haskellユーザーよりも、Lisp,Schemeの方が、バカの扱いに慣れているって事が分かりました。

59:デフォルトの名無しさん
09/02/10 14:26:27
自然言語を目指すとか10年古い釣りワードが入ってるし

60:デフォルトの名無しさん
09/02/10 14:54:02
10年どころか、30年古いぞｗ

61:デフォルトの名無しさん
09/02/11 01:18:09
ネタかと思ったら、本気だったのか。
URLﾘﾝｸ(d.hatena.ne.jp)

62:デフォルトの名無しさん
09/02/11 01:27:05
>>61
この子大学生かな。
知らないことも多そうだし、覚えたての言葉を使いたくて仕方が無いようにみえる。
もう少し論文とか読めばどんな研究している人がいるのかもわかってくるだろうし、
今からあんまり頭固くしてほしくないなぁ。

63:デフォルトの名無しさん
09/02/11 01:34:10
2chで煽って騒いだってしょうがねーだろ。
本気で相手してくれるやつなんていないのわからないのかなぁ。
ここのやつらも本気で相手にしてるのは論文の方だと思うし、2chは遊びと割り切ってるはず。

関数型言語が今後どういう風に発展していくのかという展望がまだ掴めていないなら、
まずは論文をたくさん読めば良いと思うよ。
言いたいことがあるなら論文で書いてくれ。

とマジレス

64:デフォルトの名無しさん
09/02/11 02:19:51
論文読むより実用的アプリを書くほうが実際ためになると思うが。

65:デフォルトの名無しさん
09/02/11 02:27:51
>>64
もちろん手を動かしてプログラミングしてみないとわからないこともある。
論文を読むのは、自分が気づかなかった別の価値観を発見することでもあり、
ほかの人がどういうことに興味を持っていて
どうすればその人たちの助けになるのか知るためでもあるんだよ。

66:デフォルトの名無しさん
09/02/11 02:32:06
こういうことを書くとブログや掲示板でも良いじゃないか、と思うかもしれないが、
ブログや掲示板は雑音に埋もれてしまうのが常だから、
言いたいことがあるなら是非とも論文で書いてくれ。

67:デフォルトの名無しさん
09/02/11 08:35:48
>>61
多分LINQあたりで「やべ、C#って最強言語じゃね？」ってなって、一気に信者化したんだろうな。
かわいいねぇ。

68:デフォルトの名無しさん
09/02/11 09:30:55
馬鹿の壁

69:デフォルトの名無しさん
09/02/11 10:44:28
自分は一般プログラマなんですけど、実際のところ研究者たちの実験的ツール
としてのHaskell、ではなくて実用アプリへの具体的な一歩を目指そう、という
動きはありますか？

例えば、RubyはRailsで目立ったわけですけど、似たようなキラーフレームワーク
のようなものが開発中とか、企業で予算をつけてやってるとか、そういう動きはあるん
でしょうか。

Haskellの本を色々見てると実に楽しいんですが、やっぱりHaskellerの大半は
研究として興味あるのであって、実用アプリについてはあまり興味ないのかな
とも感じます。

70:デフォルトの名無しさん
09/02/11 11:23:36
そんなあなたにRealWorldHaskell

71:デフォルトの名無しさん
09/02/11 11:45:01
>>69
> 自分は一般プログラマなんですけど、実際のところ研究者たちの実験的ツール
> としてのHaskell、ではなくて実用アプリへの具体的な一歩を目指そう、という
> 動きはありますか？
それが研究なんだけどｗ

72:デフォルトの名無しさん
09/02/11 12:04:09
>>61の奴はpmokyの別blogな。
pmokyはやねう企画の内部告発して2chに勝利宣言してたキチガイ。
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)

73:69
09/02/11 12:28:31
>>70
そうなんですけど、あれは一般に広まってるアプリの実装例の解説書ですよね。

やっぱり、JavaやRubyにあるようなFrameworkと等価なもの、且つ関数型の
魅力が発揮できてるものが無いと火がつかないんじゃないかなぁ。

C#なんかは、自分は好きじゃないですけど、そういう利便性の追求という点
ではそれなりによく出来てるとは思います。皆が欲しがりそうなものをよく
揃えてるなぁと。

Haskellerはそういうのは興味なくて、もっと言語自体の面白さを追求する
ことが多いんじゃないでしょうか？

74:デフォルトの名無しさん
09/02/11 12:35:26
>>73
JavaやRubyで使われているフレームワークと等価なものがほしいなら
JavaやRubyではどうしてダメでHaskellなのか
というのが論文では必要になりますね。
それが言えなければHaskellで実装する必要も無いでしょう。

75:デフォルトの名無しさん
09/02/11 12:41:29
>>73
> Haskellerはそういうのは興味なくて、もっと言語自体の面白さを追求する
> ことが多いんじゃないでしょうか？
というよりもむしろ純粋関数型言語で実用的でコミュニティも活発なのがHaskellぐらいしかないので、
関数型言語でもっとも効率的にプログラミングするにはどうすればいいか、
というのを研究する材料に使われることが多いというだけですね。
既存技術を持ち込むことにはあまり興味がないというのは正しい見方かもしれないけれど。
既存技術を持ち込むのに適した関数型言語ならOcamlとかのほうが適任かもしれないね。
むしろ、そういう考え方をHaskellに持ち込まないでほしいというのが俺の思いでもあるし、
多くのHaskellerもそう思っているはず。

76:デフォルトの名無しさん
09/02/11 12:44:34
既存技術っていうのはオブジェクト指向で培った技術という意味ね。
既存技術って言ったらいろいろ含まれすぎだから。。

77:69
09/02/11 12:59:24
もちろん、オブジェクト指向とか持ち込む必要ないですよ。等価という言葉に
語弊があったかな。

そうではなくて、こうすりゃ簡単にWebアプリができちゃいますよ、みたいな
ものが必要じゃないのかなと。だけど、Haskeller一般はそんな量的な問題
関心なくて、もっと質的なことを追求したい、という感じがするわけです。

Railsのように実装手順が簡易且つ明確で、しかも副作用の無いことから
くる不具合の低減、並列処理の親和性なんかをアピールした、お手軽
フレームワーク、ライブラリが出てくるとぐっと違ってくると思うわけです。

要するに、Haskellが世間でお金になる。そういう状況ってこないのかなぁと。

78:デフォルトの名無しさん
09/02/11 13:07:54
>>77
オブジェクト指向に親和性が高い技術ってあるでしょ？
そういうのはそのまま持ち込めない、あるいは持ち込んでも不細工。
例えばオブジェクト指向で人気が高いデザインパターンとかはそのまま関数型言語に持ち込んでも不細工だし、
Railsにしたってオブジェクト指向を基盤としているからそのまま関数型言語で使うと不細工。

関数型言語で似たような機能をどのように違和感無く実現するか、っていうのは一つの研究テーマになってるよ。
まだ研究が実っていない部分が多いから、こうすればいいのになんでやらないんだ、っていう外部の感想は良く聞くけどね。

79:デフォルトの名無しさん
09/02/11 13:08:44
OCamlは一応オブジェクト指向機能がついているからオブジェクト指向の技術がそのまま持ち込めるんだよ。
だから関数型言語の中ではわりと人気が高いのかな。

80:69
09/02/11 13:17:50
>>78
いや、ちょっと分からないです。Javaなどで使われてる実装パターンがHaskellにも
応用なんかする必要ないと思いますよ。

自分が言ってるのは、RailsをHaskellに移植しろ、って話じゃないんですよね。そうじゃ
なくて、Haskellならではの、だけど利便性ではRailsに負けないライブラリが欲しいなぁ
ということなのです。

Haskellが広まってそれが普通の開発でお金が取れるようにならないかな？っていう
素朴な願望なんですね。

81:デフォルトの名無しさん
09/02/11 13:21:40
不細工だろうが何だろうがとりあえず動くなら持ち込めばいいと思うけどな
それがなされてないなら需要がないんだろ

>>77
HAppS
A web framework for developers to prototype quickly, deploy painlessly, scale massively, operate reliably, and change easily.
URLﾘﾝｸ(happs.org)

こういうの？使ったことないけど

82:デフォルトの名無しさん
09/02/11 13:24:17
>>80
> Haskellならではの、だけど利便性ではRailsに負けないライブラリ
そういうのも含めて言っているよ。

研究中としかいいようがない。
文句言う前に論文あさって、やりたいことがあるなら人に言う前に自分で作ったら良いじゃん。
できたら論文にするなり、製品にするなりしたほうが自分のためになるよ。

83:デフォルトの名無しさん
09/02/11 13:25:30
Haskellが得意とするのは二つだ
lambda-calculus と pi-calculus
オブジェクト指向？どこの原始人ですか、あんたｗ

84:デフォルトの名無しさん
09/02/11 13:32:59
Haskellerは言語自体の信者なんであって
実用ソフト書くことになんか興味ないだろ
もともと言語自体実用的じゃないし

85:デフォルトの名無しさん
09/02/11 13:35:40
>>82
(1) モノをつくる、(2) 論文を書く、(3) 文句を言う、の中で
わざわざ2chで、どんなバカでもお手軽に自尊心にエサをやれる(3)を選んでるヤツに対して無茶いうなw

86:デフォルトの名無しさん
09/02/11 13:40:21
>>84
Haskeller全体の傾向のことは分からんが、実用に興味がある奴はそれなりに居るよ
ライブラリがそれなりに整備されていってるのが証拠

言語仕様が実用的じゃないってのは意味不明

87:デフォルトの名無しさん
09/02/11 13:41:35
>>84
あなたにとっての「実用的」を論理的に説明してください

88:デフォルトの名無しさん
09/02/11 13:50:01
>>87
実用プログラムが簡単に書けることだな
テキストエディタとか、表計算ソフトとか、お絵かきソフトとか
人の楽しみや金銭的利益を発生させる役に立つことが出来るプログラムが
簡単に書けることだ

89:デフォルトの名無しさん
09/02/11 13:52:00
>>88
そんなのも書けないなら一からHaskellの勉強(笑)やり直せ

90:デフォルトの名無しさん
09/02/11 13:56:23
>>89
お前しょうもないやつだな

91:デフォルトの名無しさん
09/02/11 14:02:16
そろそろ勝利宣言とかくるのかな？

92:デフォルトの名無しさん
09/02/11 14:05:12
Yiとか割と夢が広がるようなソフトもあるけど、
これは俺がemacs厨なだけかもしれん

93:デフォルトの名無しさん
09/02/11 14:09:33
>>79
OCamlはオブジェクト指向の技術があるからわりと人気が高いってそれマジで言ってんのww？

94:デフォルトの名無しさん
09/02/11 14:11:53
>>93
大真面目。
実際、ただのCamlだったころはほとんど人気が無かった。
オブジェクト指向でも開発できる、というのが心理的な安心感を与えるのだろう。

95:デフォルトの名無しさん
09/02/11 14:12:58
お前らってオブジェクト指向をやってる奴は全員バカだと思ってるの？

96:デフォルトの名無しさん
09/02/11 14:15:09
OCamlはF#人気に便乗してるだけだろ
もっとも、F#はオブジェクト指向は排除されたようだが

97:デフォルトの名無しさん
09/02/11 14:16:08
違うって。
F#はOCaml人気の後に出てきた後発組

98:デフォルトの名無しさん
09/02/11 14:16:44
まぁ、GUIソフトをうまく書けるのか、っていうのはそれなりに重要な点だと思う。

でも、GUIソフトの書き方で、これがすばらしい、理想的だっていう
言語、フレームワークにはまだ出会ってないので、
何が必要なのかとかはよく分からん。

GUIはいろいろ考えるよりも、実直に状態マシンで仕様化して、
それを書き下したほうが結局は分かりやすくなるような気もするし、
そういう意味では、Haskellはむしろ書きやすい言語なのかもしれない。

99:デフォルトの名無しさん
09/02/11 14:18:10
Yampaとか全然使い方がわがんね

100:デフォルトの名無しさん
09/02/11 14:18:16
>>88
３点質問します
・あなたはどの程度Haskellが使えますか？
・言語仕様とラブラリやコンポーネントの話がごっちゃになっているのは何故？
（それとも何のライブラリも使わずに0からお絵描きソフトや表計算ソフトを作るってこと？）
・BtoCだけでなくBtoBも考えたら、どの言語が一番「金銭的利益を発生させる役に立つことが出来ている」と思いますか？

101:デフォルトの名無しさん
09/02/11 14:21:03
xmonadのソースでも読んでみたら?

102:デフォルトの名無しさん
09/02/11 14:23:29
言語として副作用もまともに扱えないのにGUIもクソもないでしょう

103:デフォルトの名無しさん
09/02/11 14:25:32
>>95
いやそうじゃなくて、OCamlのオブジェクト指向部分はかなり悪評高いんだよ。

>>94
OCamlのオブジェクト指向はかなり人気がないことをもちろん知った上での発言だよね？
何かそれでもOCamlのOOP部分に利点があるというならそれはどんな点？

104:デフォルトの名無しさん
09/02/11 14:25:40
GUIの書き方はGrapefruitが個人的な理想にかなり近い
ライブラリ自体は全然実用段階ではないけど

105:デフォルトの名無しさん
09/02/11 14:26:29
てか>>102=84なのか？
だったらマジで勉強しなおしたほうが良いと思うぞ。

106:デフォルトの名無しさん
09/02/11 14:27:44
副作用無しでイベント駆動系が綺麗に実装できたら面白いなぁとか思ってるけど
gtk2hsはIORef使いまくりで吹いたｗ

107:デフォルトの名無しさん
09/02/11 14:28:20
>>102
たぶんHaskellを誤解してるな
Haskellに副作用はないけど、副作用とは別の方法でちゃんと入出力ができるから心配要らんよ

108:デフォルトの名無しさん
09/02/11 14:29:13
>>103
コミュニケーションが取れないな。
お前はOCamlまたはF#の人気の根拠は何だと思っているんだ？

109:69
09/02/11 14:30:40
>>81
> HAppS

そういうの。だけど、Jakartaプロジェクトにあるようなレベルとはやっぱり違うんですよね。

>>82
> 文句言う前に論文あさって、やりたいことがあるなら人に言う前に自分で作ったら良いじゃん。

あはは。すみません、自分はそこまでできません。

Haskellerの皆さんって頭イイ人多いと思うんですよ。そこでうまく金にする方向へは行かない
んでしょうかね。

110:デフォルトの名無しさん
09/02/11 14:34:11
>>109
お前、名大のOB？

111:デフォルトの名無しさん
09/02/11 14:37:09
>>108
＞F#の人気の根拠
そもそも人気ではないと思うんだが。

＞OCamlの人気の根拠
型推論とかがあるからじゃないかな。
で、Haskellみたいにモナドにくるんだりせずに直接副作用操作が書ける、という手軽さ。
　　　　　　　　　　　　　　　　＋
実用的なライブラリもそこそこ揃ってる。GUIツールキットとか。

112:デフォルトの名無しさん
09/02/11 14:37:16
>>106
Grapefruitはgtk2hsのラッパとして動くけど、そのへんをうまく隠蔽してるよ
ボタン一個を表示して、クリックされる度にボタン上のテキストの"*"が増えていくサンプル
Grapefruit付属のexampleから抜粋

mainCircuit :: (StdToolkit toolkit) => UICircuit Window toolkit era () (DSignal era ())
mainCircuit = proc () -> do
　　 rec let

　　　　　　 title = pure "Simple"

　　　　　　 text 　= SSignal.scan "*" (const . ('*' :)) push

　　　　 X :& Closure ::= closure `With` X :& Push ::= push
　　　　　　 <- window `with` just pushButton
　　　　　　　　 -< X :& Title ::= title `With` X :& Text ::= text
　　 returnA -< closure

113:デフォルトの名無しさん
09/02/11 14:43:16
GUIにあんまり興味ないけど、HaskellのGUIライブラリとか親和性とかについて前に誰かまとめてくれてたね。
nobsunだっけ？

114:デフォルトの名無しさん
09/02/11 14:45:58
横からすまんが
>お前はOCamlまたはF#の人気の根拠は何だと思っているんだ？
OCamlやF#って人気あるの？
単なるあなたのマイブームでない「人気」の証拠を、示してもらえますでしょうか？
Radditとか見てもあまり話題にあがってないと思います。

115:デフォルトの名無しさん
09/02/11 14:49:52
日本ではF#発表されるまで全くの無名だろ>OCaml
日本語の本なんてここ3年にでたのしかないし。

116:デフォルトの名無しさん
09/02/11 14:49:59
>>114
MicrosoftがVisual StudioにF#を乗っけようとしているから。

117:デフォルトの名無しさん
09/02/11 14:52:32
Microsoftは合理的な資本主義の営利企業だから儲からないことはやらないだろう。
そのMicrosoftがF#を打ち出してるんだから人気がある、あるいは人気が出る、あるいは人気を出させる、
と判断したからだろう。

118:デフォルトの名無しさん
09/02/11 14:54:09
>>117
Visual J#って覚えてる？あとその人気についても。

119:デフォルトの名無しさん
09/02/11 14:58:28
当てが外れることもあるから商売＝ギャンブルは成り立つんだよ。

120:デフォルトの名無しさん
09/02/11 15:14:37
で、F#はどのへんで人気なの？

121:デフォルトの名無しさん
09/02/11 15:16:33
うるせーよ自分で調べろよ

122:デフォルトの名無しさん
09/02/11 15:40:41
じゃあHaskellはどの辺で人気なの？

123:デフォルトの名無しさん
09/02/11 15:42:13
人気なんてありませんよ。
人気がある言語をお望みでしたらどうぞお帰りください。

124:デフォルトの名無しさん
09/02/11 15:50:27
>>112
今の普通の言語だと

コンストラクタ
{
...
　button.Click += button_click;
}

void button_click()
{
　button.Text = button.Text + "*";
}

こんな風になるわけじゃない
こんなんと比較してどの辺が優れてるの？

125:デフォルトの名無しさん
09/02/11 15:55:59
カレーハワードの対応でリストに相当するもんはなんなんでしょうか
試しにzipwith :: (a->b->c)->[a]->[b]->[c]を場合分けで証明して、
そこからカレー(ry対応でhaskellのコードに変換したかったんですが
リストをどう処理していいのかわかりませんでした

126:デフォルトの名無しさん
09/02/11 16:37:41
よし、今日の晩飯はカレーだ

127:デフォルトの名無しさん
09/02/11 16:42:03
>>121
GUIの要素って、いくつかの入力といくつかの出力のある部品とみなせるじゃん
たとえばボタンなら、表面のテキストや、無効化されているかどうかの状態が入力で、クリックイベントが出力
Grapefruit(や、その他のFRPライブラリ)だと、こういう部品をいくつか繋げてより大きな部品を作る、という操作を簡単に
(定型的なイベントハンドリングのコードを手で書くことなく)行なえて、それを繰り返してGUIプログラムを書くことになる
個々の部品はそれぞれ独立して記述・テストできるし、プログラムの構造がGUIの構造を反映するから、保守しやすくなると思う
(小さいもの(たとえば関数)を組み合わせて順次大きいものを作るというスタイルが有効なのは、プログラマなら良く知ってるはず)

>>112の例だと、まずボタンの出力であるクリックイベントをscan(Data.List.scanlのアナロジー)を使って'*'の羅列に加工し、
それをボタンのテキスト入力にフィードバックした回路を作ってる
その回路がウィンドウに入っていて、全体として入力が空で出力がウィンドウを閉じるclosureイベントだけ、という回路になっている

あと細かい点として、部品の合成をするときは、部品の実体を直接繋ぐんじゃなくて、
部品の設計図(Haskellではアローで表現される)を合成して、最後に一括してインスタンスを作る
部品はコピーできないけど設計図はコピーできるので、扱いやすい
この設計図は通常の値なので、パラメタを指定すると設計図を返す関数、みたいなのも自然に書ける

こういう特徴をまとめてdeclarativeだというんじゃないかな…

128:デフォルトの名無しさん
09/02/11 16:42:57
ごめん、>>127は>>124へのレス

129:デフォルトの名無しさん
09/02/11 16:51:41
>>125
良く分からんが、
zipWith f xs ys = []
という自明な証明がある自明な命題っぽい

130:デフォルトの名無しさん
09/02/11 16:58:26
>>125
言っている意味がわかりません。

131:デフォルトの名無しさん
09/02/12 21:32:21
Haskellerってやっぱゴリゴリアプリ作るよりも、論文読んで理論理解を進める
ことを主にしてるんですかね。

132:デフォルトの名無しさん
09/02/12 22:31:27
Haskellerって言っても色々いるだろ
俺はHaskellの論文読んでる時間よりHaskellのコード書いてる時間の方が圧倒的に長い

133:デフォルトの名無しさん
09/02/12 23:35:47
Haskellと量子計算
> 第1回　関数型プログラミングの世界へようこそ
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
URLﾘﾝｸ(www.cs.nott.ac.uk)

134:デフォルトの名無しさん
09/02/13 00:00:15
つうか論文ってどこで読むの（＾ρ＾）

135:デフォルトの名無しさん
09/02/13 00:02:05
>>134
学会の論文誌

136:デフォルトの名無しさん
09/02/13 00:02:23
haskell wikiにおいで

137:デフォルトの名無しさん
09/02/13 06:32:45
やっぱHaskellerってGHCのコードは全部読んだことあるの？

138:デフォルトの名無しさん
09/02/13 06:46:01
>>134
とりあえず手始めに
Simon Peyton Jonesのサイトにいくのはどう？

139:デフォルトの名無しさん
09/02/13 09:33:20
rts以外は全部読んだよ

140:デフォルトの名無しさん
09/02/13 09:33:36
>> 94
OCamlはオブジェクト指向があるからというより、単に実効速度が早いからじゃね？
型推論があって短く書けるし、コンパイルも早いし、
副作用もかけるからモナドが分かんなくても大丈夫だし
静的型があるから実行時の信頼性も高いし
サーバーサイドでOCamlは結構使われているんじゃないかなぁ。
でもOCamlの人はHaskell好きが多い気がする。

141:デフォルトの名無しさん
09/02/13 20:14:26
OCaml好きの俺は↑の通り速度+強い型付けに惹かれて始めた。
型推論の便利さは始めてから気づいたが
オブジェクト指向部分にはさして興味ない

Haskellはインデント強制と遅延評価が嫌いだが
それ以外の部分は、かじった程度には好きかなぁ

142:デフォルトの名無しさん
09/02/13 20:17:55
>>141
もともとLISP好きとか？

143:デフォルトの名無しさん
09/02/13 20:50:17
Common LispはわからんけどSchemeは好き。
C++のSTLさわるようになってちょっとたった頃
自分のやりたいことはC++では面倒だと悟って
Scheme→OCamlに至る

144:デフォルトの名無しさん
09/02/13 20:51:55
>>139
すげえな、やっぱみんなそうなのか。。

145:デフォルトの名無しさん
09/02/13 21:23:55
プログラミング習得の流れ
VB.net => C# => F# => OCaml => Haskell => Agda => Coq
もしくは
Java => Scala => Scheme => OCaml => Haskell => Agda => Coq

146:デフォルトの名無しさん
09/02/13 21:28:36
>>132
どんなコードを普段書いてるんですか？仕事で？

147:デフォルトの名無しさん
09/02/14 01:23:46
>>146
仕事＝研究

148:デフォルトの名無しさん
09/02/14 04:31:57
>>144
俺は全く読んだことないよ。

149:デフォルトの名無しさん
09/02/14 07:19:22
Real World Haskell 全文公開
URLﾘﾝｸ(book.realworldhaskell.org)

こりゃすげえ

150:デフォルトの名無しさん
09/02/14 08:54:49
Real World Haskellは研究者の方から見るとどういう位置づけ
の本になりますか？

「新しいこと何もないじゃん。ツマンネ」って感じでしょうか。

151:デフォルトの名無しさん
09/02/14 09:24:21
>>145 ちょ、オレまだJavaだよ。まだまだだな。

152:デフォルトの名無しさん
09/02/14 12:03:36
>>145 これが選民思想ってやつか。

153:デフォルトの名無しさん
09/02/14 17:15:09
>>145
右に行くほどWindowsに冷たくなっていくのがなぁ
関数型言語やり始めて初めてWindowsが嫌われる理由がわかったよ・・・

154:デフォルトの名無しさん
09/02/14 17:59:45
>145
ScalaとかOCamlとかやったことねぇｗ

155:デフォルトの名無しさん
09/02/15 19:06:31
OCaml速いの？Cleanの方が速いってイメージがあるけど。

156:デフォルトの名無しさん
09/02/15 20:35:41
Cleanってもうずっとメンテとまってるじゃん。

157:デフォルトの名無しさん
09/02/16 01:05:48
>145
確かにプログラムすごい人はみんな右側を目指している気がする。
現在のビジネス現場に用いられるかは別だけど。

158:デフォルトの名無しさん
09/02/16 01:47:40
Agdaもcoqも知らなかった
軽量スレッドとSTMとSIMD向き機能と
豊富なライブラリが有れば十分だと思う
いい線行ってるのは、Haskell,Clojure,F#じゃない?

159:デフォルトの名無しさん
09/02/16 15:54:04
clojure って、注目、集めてるのかな?

俺、ちょっと前、Webで引っかかって、
へ～と、思っただけだったんだけど。

Java ベースって所で、軽く読んだだけで
済ませちゃった。

160:デフォルトの名無しさん
09/02/16 16:02:42
Javaベース＝ウンコ　→　終了

161:デフォルトの名無しさん
09/02/16 17:55:35
今更かもしれないけど
URLﾘﾝｸ(hackage.haskell.org)
ghci-haskeline だと windows でも ghci でタブで補完が効きます、お試しあれ。

162:デフォルトの名無しさん
09/02/16 21:59:40
>>160
なんでJavaベースでやろうとするんだろな。
Scalaとかそれだけで敬遠してるわ。

163:デフォルトの名無しさん
09/02/16 22:10:38
>>162
処理系作るのが簡単だから。

164:デフォルトの名無しさん
09/02/16 22:29:33
いいじゃん Java ベースでも。Clojure は実用性も強く意識
してる、いい言語だと思うよ。

165:デフォルトの名無しさん
09/02/16 22:47:01
>>164
Javaの仮想マシンが不安定なんです。

166:デフォルトの名無しさん
09/02/16 23:52:26
不安定って話は聞いた事が無いな。
ちょこちょこREPLを立ち上げる様な使い方だと、
相性が良いとは言えないとは思うけど。

167:デフォルトの名無しさん
09/02/17 00:02:29
GCがウンコなんで、Javaもウンコ。
もう仕様が悪いとしか言いようがありません。

168:デフォルトの名無しさん
09/02/17 00:18:05
・Java以外の言語でコーディング --> Javaバイトコード生成
・JVM(サーバ、クライアント共に)がきちんとクロージャなどをサポートするように進化
の条件が揃えば商用アプリ作成がしやすくなるんでは?
Java言語自体は衰退するかもしれんが。

169:デフォルトの名無しさん
09/02/17 00:23:53
>>166
おれも、Java だからという理由で気になるのは起動速度くらいだなぁ。
REPL といえば、ghci も起動速度遅いよね。hugs は早いの？

170:デフォルトの名無しさん
09/02/17 02:34:49
ぱっと見、興味を持ったとこ。
lazy-cons defn when-let あと、lisp-1
arcより、面白そうな気もする。

javaを嫌う人は結構いるだろうから、
もし、このlispがはやったら、
nativeで書く人が出てくるんじゃない。

けど、class library使えなくなっちゃうか。

次ページ