5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2009/01/14(水) 00:51:13
haskell.org
http://www.haskell.org/

日本語サイト
http://www.sampou.org/cgi-bin/haskell.cgi
http://www.shido.info/hs/

過去ログ
関数型プログラミング言語Haskell
Part1 http://pc.2ch.net/tech/kako/996/996131288.html
Part2 http://pc2.2ch.net/test/read.cgi/tech/1013846140/
Part3 http://pc8.2ch.net/test/read.cgi/tech/1076418993/
Part4 http://pc8.2ch.net/test/read.cgi/tech/1140717775/
Part5 http://pc8.2ch.net/test/read.cgi/tech/1149263630/
Part6 http://pc11.2ch.net/test/read.cgi/tech/1162902266/
Part7 http://pc11.2ch.net/test/read.cgi/tech/1174211797/
Part8 http://pc11.2ch.net/test/read.cgi/tech/1193743693/
Part9 http://pc11.2ch.net/test/read.cgi/tech/1211010089/
・2chの仕様により、行頭の半角スペースは表示されません。
 コードをインデントしたいときは、代わりに または全角スペースを使うことができます。

2 :デフォルトの名無しさん:2009/01/14(水) 00:51:48
関連書籍
・Introduction to Functional Programming Using Haskell
 http://www.amazon.co.jp/exec/obidos/ASIN/0134843460/
・Haskell: The Craft of Functional Programming
 http://www.amazon.co.jp/exec/obidos/ASIN/0201342758/
・The Fun of Programming
 http://www.amazon.co.jp/exec/obidos/ASIN/1403907722/
・The Haskell School of Expression: Learning Functional Programming Through Multimedia
 http://www.amazon.co.jp/exec/obidos/ASIN/0521644089/
・入門Haskell
 http://item.rakuten.co.jp/book/1794880/
・ふつうのHaskellプログラミング
 http://item.rakuten.co.jp/book/4052963/
・Programming in Haskell
 http://www.amazon.co.jp/exec/obidos/ASIN/0521692695/
・Real World Haskell
 http://www.amazon.co.jp/exec/obidos/ASIN/0596514980



3 :デフォルトの名無しさん:2009/01/14(水) 00:52:14
関連スレ
・関数型言語Part IV
 http://pc11.2ch.net/test/read.cgi/tech/1083649982/
・【数学者】Haskellはクソ言語【オナニー】
 http://pc11.2ch.net/test/read.cgi/tech/1128011645/
・純粋関数型言語Concurent Clean
 http://pc11.2ch.net/test/read.cgi/tech/1075629340/
・関数型言語ML(SML, OCaml, etc.), Part 5
 http://pc11.2ch.net/test/read.cgi/tech/1186292994/
・Lisp Scheme Part25
 http://pc11.2ch.net/test/read.cgi/tech/1231856193/
・【入門】CommonLispその4【質問よろず】 --DAT落ち、次スレなし
 http://pc11.2ch.net/test/read.cgi/tech/1201402366/
・Emacs Lisp 3
 http://pc11.2ch.net/test/read.cgi/tech/1191875993/

4 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/01/14(水) 00:53:44
       //
     /  /   パカッ
     //⌒)∩__∩
    /.| .| ノ     ヽ
    / | |  ●   ● |     
   /  | 彡  ( _●_) ミ  まピョーん☆
   /  | ヽ  |∪|  /_
  // │   ヽノ  \/
  " ̄ ̄ ̄ ̄ ̄ ̄ ̄(..ノ


7 :デフォルトの名無しさん:2009/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 (http://code.haskell.org/utf8-string/)
を導入することにより、入出力を UTF-8 にすることができる
4. その他の文字列エンコード(ShiftJIS, JIS, EUC-JP など) は、
package iconv (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/iconv)
で UTF-8 な文字列にする
とまあ、こういうことで、日本語表示できるわけだ。iconv package は MacOSX と *BSD では
cabal を少しいじらなければいけないことに注意しろよ(iconv.cabal のコメントに書いてある)
よろしくたのむ、な。



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

9 :デフォルトの名無しさん:2009/01/15(木) 18:24:13

                          刀、           , ヘ
                  /´ ̄`ヽ /: : : \_____/: : : : ヽ、
              ,. -‐┴─‐- <^ヽ、: : : : : : : : : : : : : : : : : : : : : : }
               /: : : : : : : : : : : : : :`.ヽl____: : : : : : : : : : : : : : : : : : /
     ,. -──「`: : : : : : : : : :ヽ: : : : : : : : :\ `ヽ ̄ ̄ ̄ フ: : : : :/
    /: :.,.-ァ: : : |: : : : : : : : :    :\: : : : :: : : :ヽ  \   /: : : :/
    ̄ ̄/: : : : ヽ: : : . . . . . . . . . . .、 \=--: : : :.i  / /: : : : :/
     /: :     ∧: \: : : : : : : : : : ヽ: :\: : : 〃}/  /: : : : :/         、
.    /: : /  . : : :! ヽ: : l\_\/: : : : :\: ヽ彡: : |  /: : : : :/            |\
   /: : ィ: : : : :.i: : |   \!___/ ヽ:: : : : : : :\|:.:.:.:/:!  ,': : : : /              |: : \
   / / !: : : : :.ト‐|-    ヽ    \: : : : : l::::__:' :/  i: : : : :{              |: : : :.ヽ
   l/   |: : :!: : .l: :|            \: : : l´r. Y   {: : : : :丶_______.ノ: : : : : :}
      l: : :l: : :ト、|         、___,ィ ヽ: :| ゝ ノ    '.: : : : : : : : : : : : : : : : : : : : : : /
      |: : :ト、: |: :ヽ ___,彡     ´ ̄´   ヽl-‐'     \: : : : : : : : : : : : : : : : : : イ
        !: :从ヽ!ヽ.ハ=≠' , ///// ///u /           ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
      V  ヽ|    }///  r‐'⌒ヽ  イ〉、
              ヽ、______ー‐‐' ィ´ /:/:7rt‐---、       こ、これは>>1乙じゃなくて
                  ィ幵ノ ./:/:./:.! !: : : : :!`ヽ     ポニーテールなんだから
              r‐'T¨「 |: | !:.∨:/:./: :| |: : : : .l: : : :\   変な勘違いしないでよね!
               /: : .|: :| !:.!ィ¨¨ヾ、:.:/ !: : : : l: : : : : :.\

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

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

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

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

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

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

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

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

Haskell mode for Emacs - HaskellWiki
http://www.haskell.org/haskellwiki/Haskell_mode_for_Emacs

hoogle
http://www.haskell.org/hoogle/

hayoo
http://holumbus.fh-wedel.de/hayoo/hayoo.html

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

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

18 :デフォルトの名無しさん:2009/01/28(水) 20:36:35
Haskell98にはない
GHC拡張に似たようなものがある
http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-classes.html

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

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

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

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

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

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

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

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

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

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

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

id :: * -> *
id x = x

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

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




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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の方どうぞ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

61 :デフォルトの名無しさん:2009/02/11(水) 01:18:09
ネタかと思ったら、本気だったのか。
ttp://d.hatena.ne.jp/haruyutaka/20090208/p3

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

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

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

とマジレス


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

>>77
HAppS
A web framework for developers to prototype quickly, deploy painlessly, scale massively, operate reliably, and change easily.
http://happs.org/

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

109 :69:2009/02/11(水) 14:30:40
>>81
> HAppS

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

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

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

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

110 :デフォルトの名無しさん:2009/02/11(水) 14:34:11
>>109
お前、名大のOB?

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

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

112 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/02/11(水) 14:43:16
GUIにあんまり興味ないけど、HaskellのGUIライブラリとか親和性とかについて前に誰かまとめてくれてたね。
nobsunだっけ?

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

133 :デフォルトの名無しさん:2009/02/12(木) 23:35:47
Haskellと量子計算
> 第1回 関数型プログラミングの世界へようこそ
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060801/244812/
ttp://www.cs.nott.ac.uk/~txa/talks/ottawa-03.pdf

134 :デフォルトの名無しさん:2009/02/13(金) 00:00:15
つうか論文ってどこで読むの (^ρ^)

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

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

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

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

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

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

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

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

142 :デフォルトの名無しさん:2009/02/13(金) 20:17:55
>>141
もともとLISP好きとか?

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

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

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

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

147 :デフォルトの名無しさん:2009/02/14(土) 01:23:46
>>146
仕事=研究

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

149 :デフォルトの名無しさん:2009/02/14(土) 07:19:22
Real World Haskell 全文公開
ttp://book.realworldhaskell.org/read/

こりゃすげえ

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

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

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

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

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

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

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

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

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

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

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

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

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


160 :デフォルトの名無しさん:2009/02/16(月) 16:02:42
Javaベース=ウンコ → 終了

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

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

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

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

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

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

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

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

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

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

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

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


171 :デフォルトの名無しさん:2009/02/17(火) 07:21:29
Javaな時点でJavaを越えられないんだから夢が無いわ

172 :デフォルトの名無しさん:2009/02/17(火) 09:18:12
CALの話が全く出てこないな…

173 :デフォルトの名無しさん:2009/02/17(火) 09:45:21
>>166
起動してから3時間ぐらいスリープで無限ループしてからほかの処理をさせると、
いきなりエラーはいて終了することが良くあるんだけど原因は何なの?

174 :デフォルトの名無しさん:2009/02/17(火) 18:36:42
今は史上初めて関数型がメインストリームに躍り出そうな瞬間、だね。
Java->Scalaと.NET->F#によって。
それでもJavaはJavaのほうが使われるだろうし
.NETはVB/C#のほうが使われるだろうけど。

175 :デフォルトの名無しさん:2009/02/17(火) 18:39:57
マイクロソフトのおかげでJavaプログラマは激減の一途です。
まもなくJava終了のお知らせが来るでしょう。

176 :デフォルトの名無しさん:2009/02/17(火) 21:28:09
>>174
F#ってギャグかと思ってたんですが、結構使われそうな雰囲気なんですか?

177 :デフォルトの名無しさん:2009/02/17(火) 22:05:36
HaskellやOCaml知ってる人が現場で.Netで作ってね って言われても、C#、VBは嫌じゃね?

金儲けではF#, 趣味や研究ではHaskellってのがこれからはよくあるんじゃないかなぁ。

178 :デフォルトの名無しさん:2009/02/17(火) 22:09:42
よくわからないんだけど、他人がソース読むこと考えたらC#は嫌とかいってらんないと思うけどなあ
結局関数型でないと見通しが悪くなったり、特殊なことがやりたいときくらいになるんじゃないかなあ

179 :デフォルトの名無しさん:2009/02/17(火) 22:10:18
仕事でやるなら楽だから結構好き>C#

180 :デフォルトの名無しさん:2009/02/17(火) 23:26:30
>>167
GCはもう文句をつける部分じゃなく、どうやって付き合って行くかを
考える部分だぞ。それくらい完全に浸透している。
しかもJavaVMのGCはかなり充実していて、バカに出来る物じゃないぞ。
特に並列GCについてはかなり頑張っていると思う。

181 :デフォルトの名無しさん:2009/02/17(火) 23:32:20
>>180
GCの実装にはいろいろアルゴリズムがあるけど、Javaの仮想マシンに使われてるGCのアルゴリズムには苦情が多いよ。

182 :デフォルトの名無しさん:2009/02/17(火) 23:36:36
付き合っていく以前に、Java自体衰退してるじゃん。既に。
アメリカじゃJavaが捨てられて混沌の世界になってるらしい。

183 :デフォルトの名無しさん:2009/02/18(水) 00:30:28
>>182
ttp://sourceforge.jp/magazine/09/01/27/0039208
GoogleCodeに登録されているプロジェクトの使用言語を見るとJavaがCに次いで多い。
Haskellは話題にはのぼるけど実際に使われることが少ないのな。人が少ないからか。

184 :デフォルトの名無しさん:2009/02/18(水) 00:38:38
>>181
どんな苦情があるの?

マルチプロセッサであれだけスケールしてくれるGCは他にはあまり無いし、
実装はきちんとしているイメージなんだが。

185 :デフォルトの名無しさん:2009/02/18(水) 00:43:20
>>183
それは昔からの蓄積でしょ?
オープンソースが大きく取り扱われるようになった頃とJavaの流行が重なってるから、登録もその頃のものだろう。

186 :デフォルトの名無しさん:2009/02/18(水) 00:44:48
もしくは商業ベースでのJavaプロジェクトがほとんど無くなったのでオープンソースに流れてきたのかな?
ともかくJavaが衰退してきているってよく聞くよ。

187 :デフォルトの名無しさん:2009/02/18(水) 00:51:51
過去、C++が終わったという話をずっと聞き続けて来た気がするが、
『終わった事にする商法』はいつ終わるんだろうな…

188 :デフォルトの名無しさん:2009/02/18(水) 01:00:13
プログラマは常にマーケッターに騙され続ける生き物

189 :デフォルトの名無しさん:2009/02/18(水) 01:10:57
>>173
そんな話は知らんけど、ヘボプログラムだったんじゃないの?
暇を見て調べておくからエラーログと再現プログラムをくれ。

190 :デフォルトの名無しさん:2009/02/18(水) 01:23:15
そろそろ Haskell の話題に戻ろうぜ↓


191 :デフォルトの名無しさん:2009/02/18(水) 07:20:32
>>177
本当に「知っている人」はどんな言語でもちゃんと使えるよ。
半端な奴が「関数型じゃないとイヤ」とか言う。

192 :デフォルトの名無しさん:2009/02/18(水) 07:26:29
私怨を持ち込む奴が半端物でなくてなんであろう

193 :デフォルトの名無しさん:2009/02/18(水) 11:20:08
>>176
ギャグどころかやつらは本気みたいだぞ
ttp://igeta.cocolog-nifty.com/blog/2008/09/fsharp.html

むしろこのまま突っ走って行ってほしいところ

194 :デフォルトの名無しさん:2009/02/18(水) 13:01:46
言語を作る人と言語を使う人(信者)の2種類いる

195 :デフォルトの名無しさん:2009/02/18(水) 19:53:05
>>193
そいつただの実験厨じゃんw
実験厨は実験してるだけで実用的なアプリは作らないので
使われたことにはなりません

196 :デフォルトの名無しさん:2009/02/19(木) 07:34:57
>>195のようなことを言う奴が実用的なアプリをつくっている例を見たことない。

197 :デフォルトの名無しさん:2009/02/19(木) 10:58:06
>>196
実用的なアプリを作っている奴が>>195のような書き込みをしたことがないという証拠がない。

198 :デフォルトの名無しさん:2009/02/19(木) 11:13:11
>>197
あのさ、事実のあるなしじゃなくて、事後確率の問題なんじゃねーの?
統計にがてだった?

199 :デフォルトの名無しさん:2009/02/19(木) 11:25:26
>>198
君ってどこまで負けず嫌いなの?
統計と言うなら数字を出すべきだし、それ以前に偏見を持って物事に当たるべからずっていう行間の意味が理解できないほど国語苦手だったの?^^;

200 :デフォルトの名無しさん:2009/02/19(木) 11:28:45
実験厨のあとは同一認定厨が登場しました。次は何厨房が出るんでしょう?

201 :デフォルトの名無しさん:2009/02/19(木) 11:29:36
なんだ、ただの釣り師か。

202 :デフォルトの名無しさん:2009/02/19(木) 11:32:20
>>201
いいから頭冷やせって、>>196さんよぉ

203 :デフォルトの名無しさん:2009/02/19(木) 11:34:27
どうでも良いけど最近arrowの話題めっきり聞かなくなったな。

204 :デフォルトの名無しさん:2009/02/19(木) 11:40:21
一時はすべてのhaskellライブラリがarrowで書き換えられるんじゃないかって勢いだったのに、
所詮は一過性の流行でしかなかったということか。

205 :デフォルトの名無しさん:2009/02/19(木) 12:25:55
arrowへの書き換え作業が、なぜメインストリームに乗ると考えるかが不思議。

206 :デフォルトの名無しさん:2009/02/19(木) 16:24:46
まぁ、実際arrowに書き換えないと乗り遅れるとみんなが思っていた時期もあった。

207 :デフォルトの名無しさん:2009/02/19(木) 17:12:55
arrowが分かってない人だけじゃね

208 :デフォルトの名無しさん:2009/02/19(木) 17:44:54
うむ。 おじいちゃんもがんばってるんだから みながんばれ
ttp://www.cmas60.com/index.php

209 :デフォルトの名無しさん:2009/02/19(木) 22:20:57
おじいちゃん、F#にのりかえたようですが

210 :デフォルトの名無しさん:2009/02/19(木) 22:52:40
情報処理学会誌で、和田先生がHaskellのコラム書いてたのを思い出した

211 :デフォルトの名無しさん:2009/02/19(木) 23:08:58
そのおじいちゃんすごいな、しかもForthちょうど今日完成したんだな。おめでたい

212 :デフォルトの名無しさん:2009/02/20(金) 01:24:25
初心者です。
WIndows + Hugs でウィキペディアからデータをとるプログラムを作ろうとしているのですが、
いきなり文字化けでつまずいています。

module MediaWiki where

import System.IO
import Network

loop :: IO a -> IO a
loop a = a >> loop a

test = do
h <- connectTo "ja.wikipedia.org" (PortNumber 80)
hPutStr h "GET / HTTP/1.1\nHost: http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8\n\n"
f <- openFile "D:/test.txt" WriteMode
loop (hGetLine h >>= hPutStr f)

きちんとループ処理していないので、エラーで終了しますが、とりあえずデータは取れます。
しかし、文字化けしています。文字化けを回避する方法はないでしょうか。

213 :デフォルトの名無しさん:2009/02/20(金) 01:36:45
自己解決しました。
お騒がせして、すみません…

214 :デフォルトの名無しさん:2009/02/20(金) 01:44:20
>>213
どうやって解決したの?

215 :デフォルトの名無しさん:2009/02/20(金) 02:17:05
>>214
テキストエディタ(Notepad++)が、コーディングをうまく認識しなかったようです。
メモ帳でUTF-8を指定して開くと読めました。

216 :デフォルトの名無しさん:2009/02/20(金) 02:54:57
notepad++はやめときな。
あれはバグが多すぎて、書いたものや開いたものの安全は保障できないぜ。

217 :デフォルトの名無しさん:2009/02/20(金) 02:57:21
winやったらxyzzyあたりでいいんじゃないの

218 :デフォルトの名無しさん:2009/02/20(金) 03:06:07
xyzzyの機能はmeadowの劣化版だし、スクリプトに互換性ないでしょ。

219 :デフォルトの名無しさん:2009/02/20(金) 03:14:58
使う気があるなら、ntemacsでもmeadowでも良いと思うよ。
ただ、notepadあたりを使ってる人に導入が簡単だろうか?
と思ったからだよ。notepadよりはマシだろ?
本当はemacsのhaskell-modeは欲しいね。

220 :デフォルトの名無しさん:2009/02/20(金) 12:14:18
ghcって、バイナリ作るところまで担ってるの?それともアセンブラまで生成
して、アセンブルは外部に丸投げ?

221 :デフォルトの名無しさん:2009/02/20(金) 12:33:48
アセンブルは丸投げ

222 :デフォルトの名無しさん:2009/02/20(金) 12:46:47
GHCはCコードを生成してCコンパイラに渡す

223 :デフォルトの名無しさん:2009/02/20(金) 12:48:58
>>220
アセンブラを生成って・・・
処理系を生成するわけじゃないんだからw
この文脈の場合は アセンブリ言語を生成 って言ったほうが誤解を招かないよ。

224 :デフォルトの名無しさん:2009/02/20(金) 12:49:59
つうことはwindowsならgccでなくcl.exeを使うようにすることもできるのか

225 :デフォルトの名無しさん:2009/02/20(金) 12:52:20
>>224
-pgmcオプションかな。

226 :デフォルトの名無しさん:2009/02/20(金) 13:31:36
デフォルトはCを介さずアセンブリを直接生成じゃね?
少なくとも俺の環境(x86, Linux, ghc-6.10.1)だとそうだ

>>224
中間Cコードはgcc依存じゃないだろうか
gccが生成したアセンブリに後処理を加えてるくらいだから

227 :デフォルトの名無しさん:2009/02/20(金) 19:23:33
アセンブラソースかアセンブリソースって言わないかな?

GCCのcc1もバイナリ生成しないし、自分の知ってる処理系では
MSC系とTurboC系ぐらいしかないな、直接オブジェクト吐く
コンパイラって。

228 :デフォルトの名無しさん:2009/02/20(金) 19:26:49
じゃマシンコードで

229 :デフォルトの名無しさん:2009/02/20(金) 19:52:34
turboC懐かしいなぁ・・ 初めて親に買ってもらったCコンパイラがturboCなんだが、もう20年も昔のことなのか。

230 :デフォルトの名無しさん:2009/02/20(金) 20:29:12
このブルジョアめ…

231 :デフォルトの名無しさん:2009/02/20(金) 20:37:59
金無くて、BASICでCコンパイラ書いてる奴も居た。
または8bitマシン語でメタコンパイラとか。
ghcもメタコンパイラと言えるんだろうか?

232 :デフォルトの名無しさん:2009/02/20(金) 20:53:01
以前、川合史朗さんが書いたものだったと思うのですが、Haskellはトップダウン
なプログラミングでScheme(Lisp)はボトムアップだ、という話題を読んだことが
あります。

結局、Haskellの型チェックがコンパイル時に入るために、ごにょごにょと試しつつ
トップレベルの構造に至る、という作り方ができないんだと。

これってそうなんでしょうか。最初にピシッと構成が見えてないとプログラミングが
できない、ってのは不便な気がします。

233 :デフォルトの名無しさん:2009/02/20(金) 21:27:24
>>223
ごめん、アセンブラリルの区別に自信なかった。
やっぱ間違ってたか。

234 :デフォルトの名無しさん:2009/02/20(金) 21:31:13
>>232
Haskell だからってそんなことないと思うけどね。

Functional Parser のチュートリアルでよくあるじゃん。
プリミティブな部品(char とか)を作って、それを組み合わ
せて高度なもの(many とか)作って、さらにそれを組み合
わせて・・・っていう流れ。これってボトムアップだよね。

235 :デフォルトの名無しさん:2009/02/20(金) 21:45:22
>>232
トップダウン、ボトムアップの部分は知らないけど、使っていて特にそう感じた事は無いけどなあ。
Haskellは多相型が強力なのと、未知の値->取り敢えずモナドに放り込む、未知の関数->取り敢えずArrow
で組んでいけるから構成が事前に固まっていなくても問題無い。

LISP系(Sheme、Gauche他)も、こんなオペレータがあればいいのにと思った時点ですぐ実装できる。

最初に構成が見えていないプロジェクトがやりにくいと感じるケースは、言語というより体制
(大人数・ウォーターフォールでやってて、コーダーに完成形の仕様書を渡す必要あり、など)に
原因ありの場合が多かった。
まあこれはC、Javaでも言える事なんで、むしろどんなケースで困ったのかが興味ある。

236 :デフォルトの名無しさん:2009/02/20(金) 22:22:32
>>234
そのFunctional Parser自体をつくる時点でトップダウンという罠

237 :デフォルトの名無しさん:2009/02/20(金) 23:54:46
>ghci
Prelude> let m3 x = 3 * x
Prelude> m3 5
15
Prelude> let m3 x = (*) 3 x
Prelude> let m3 = (*) 3
Prelude> let m3 = (* 3)
Prelude> m3 5
15

ここまではOK

Prelude> let mm x = x * x
Prelude> let mm = ?????

上記の?????が判らんorz

238 :デフォルトの名無しさん:2009/02/21(土) 00:07:04
let mm = \x -> x * x

239 :デフォルトの名無しさん:2009/02/21(土) 00:11:08
型限定版で
let mm = (** 2)

240 :デフォルトの名無しさん:2009/02/21(土) 00:13:18
>>238,239
サンクス。 しばらく他(多)言語使ってたんでちょっと混乱してたw


241 :デフォルトの名無しさん:2009/02/21(土) 12:12:04
>>234>>235
なるほど。自分はHaskellコードをそれなりの規模で書いた経験が無いので
実感できてないのかも知れないのですが、川合さんがおっしゃってるような
ことはよく感じちゃうんですね。

末端の補助関数みたいなものを、後からこのほうがいいな、と思ってちょっといじ
っただけで、バーっと型エラーになってしまうという。そうなると、最初にどうある
べきなんだろうか、とある程度の見通しを立ててからじゃないと手戻りが多い
気がしてます。

慣れの問題なんでしょうかね。

242 :デフォルトの名無しさん:2009/02/25(水) 02:30:14
ここのエバンジェリスト ってだれ?

243 :デフォルトの名無しさん:2009/02/25(水) 13:44:12
>>235
>Haskellは多相型が強力なのと、未知の値->取り敢えずモナドに放り込む、未知の関数->取り敢えずArrow
>で組んでいけるから構成が事前に固まっていなくても問題無い。


試行錯誤する例として短めのサンプルコードはあるでしょうか?

244 :デフォルトの名無しさん:2009/02/25(水) 19:13:37
モナドやArrowを後から変更することはあるけど、
書き始める時点で全く未知ってのは、少なくとも俺の場合はないな。

245 :デフォルトの名無しさん:2009/02/25(水) 21:53:08
実用性ってことでは、ライブラリに「なるほどこう使うのか」と分かるサンプルコードが付属しているのが大事だと思う。
オレがプログラミングで試行錯誤するのは、ライブラリの使い方が良く分からなくて、自分のやりたいことができるのか、どうできるのかを確認するのが大半のような気がするから。

246 :デフォルトの名無しさん:2009/02/26(木) 00:51:13
素人です…
仕事で関数を使った表をやれと言われました


何にも知識無い人間でもできるもんですか?

247 :デフォルトの名無しさん:2009/02/26(木) 00:59:20
>>246
http://pc11.2ch.net/test/read.cgi/bsoft/1235573810/

248 :デフォルトの名無しさん:2009/02/26(木) 02:01:40
>>246
言っている意味が分かりません。
excelの話ですか?

249 :デフォルトの名無しさん:2009/02/26(木) 02:34:32
総あたりでの素因数分解です
ある程度の汚さはアルゴリズム由来なのかもしれませんが、もっと格好よく書きたいです
state monadとかを使えば格好よく書けるでしょうか

http://codepad.org/5PUyX0zV

250 :デフォルトの名無しさん:2009/02/26(木) 03:30:54
>>249
アルゴリズム的には、n < m の場合を考えてるのが変。
Haskell的には f の返り値が変。

f 1 _ = []
f n (m:ms)
 | q == 0    = m : f b (m:ms)
 | otherwise = f n ms
 where
 (b, q) = n `divMod` m

g n = f n [2..]

251 :デフォルトの名無しさん:2009/02/26(木) 03:46:50
こんなんでました。

f _ [] = []
f n ps@(m:ms) = let (b, q) = n `divMod` m in if q == 0 then m:(f2 b ps) else f2 n ms

main = print $ map (\x->(x, f2 x [2..x])) [1..100]

252 :251:2009/02/26(木) 03:48:33
あ、>>250のほうが美しい。

253 :デフォルトの名無しさん:2009/02/26(木) 05:05:45
数学的には 1 に [1] を返そうとしてるのが変。

254 :デフォルトの名無しさん:2009/02/26(木) 10:41:48
>>249は末尾再帰の形にしようとして苦労してるように見える
Haskellだと直接consを返してもスタックが伸びていくことはないから、
consが返せるならその方が綺麗になることが多いし、逆にメモリ使用量が減ることもある

例えばmapの定義
map f [] = []
map f (x:xs) = f x : map f xs
は、呼び出し側が結果のリストを先頭から順に読み捨てていく限り、定数空間で動く

>>250
n < mのテストがないと再帰が止まらんだろ
>>250のコードでn == 1のテストをしてるのと同等

255 :デフォルトの名無しさん:2009/02/26(木) 18:07:04
すごい読解力

256 :デフォルトの名無しさん:2009/02/26(木) 19:18:54
返すのが ret だけなら末尾再帰にしようとしてるっぽいけど、
n や m まで返そうとしてるのは、単に関数型言語に不慣れなんじゃないかな。

257 :249:2009/02/26(木) 19:50:35
皆様回答ありがとうございます
(_, _, a)とかでてくる時点でおかしいとは思ったんですが、随分綺麗に書けるものなんですね
>>249のコードは手続き型のループによる繰り返しを使ったアルゴリズムを元に考えたので
末尾再帰の形っぽくなったんだと思います

258 :デフォルトの名無しさん:2009/02/27(金) 18:26:14
Finally! Fast Unicode support for Haskell
http://www.serpentine.com/blog/2009/02/27/finally-fast-unicode-support-for-haskell/

259 :デフォルトの名無しさん:2009/02/28(土) 00:14:51
>>258
グレート! haskellはあまり触ってないけど、この件はもっと盛り上がってもよいとおもう。

260 :デフォルトの名無しさん:2009/03/02(月) 20:42:29
http://www.atmarkit.co.jp/news/200902/27/langs.html

Real World Haskellって売れ行き順位とか結構高かった気がするんだけど、
これが入っていたら少しは変わったのかな。

C#なんか本買う必要あるんかねぇ。よく分からん。

261 :デフォルトの名無しさん:2009/03/02(月) 20:55:06
>>260
MS王国が大好きなんちゃうか?

262 :デフォルトの名無しさん:2009/03/03(火) 22:52:37
この言語がメジャーになる日が来ると思う?
どうなったらメジャーになれると思う?

263 :デフォルトの名無しさん:2009/03/03(火) 22:57:53
>>262
こっちの系統は。。。scalaのほうがウケそう。
こんかれんとはすける とかならありえそう?<じぇむす。ぶれーく

264 :デフォルトの名無しさん:2009/03/03(火) 23:18:00
もっとポータビリティが向上すればok
yhcもっとガンガレ

265 :デフォルトの名無しさん:2009/03/03(火) 23:28:42
>>264
そういえば、ghcってデカイよな。中性脂肪たっぷりってかんじ。

266 :デフォルトの名無しさん:2009/03/03(火) 23:33:39
別にメジャーにならんでいい

267 :デフォルトの名無しさん:2009/03/04(水) 00:21:41
メジャーになってライブラリの質と量が上がれば嬉しいけどなー

268 :デフォルトの名無しさん:2009/03/04(水) 00:38:07
ライブラリ充実しても、普通に使えるようになるまでのハードルの高さが
ネックになってメインストリームにはならないんだろうね

269 :デフォルトの名無しさん:2009/03/04(水) 00:41:29
メジャーになったらHaskellで飯くえるぞ (笑)

270 :デフォルトの名無しさん:2009/03/04(水) 09:05:40
yhcがhaxeみたいになったらいい

271 :デフォルトの名無しさん:2009/03/04(水) 09:52:23
Pythonのpy2exeみたく実行に必要なファイルをまとめて1個のexeファイルとかに出来ると良いんだけど。

272 :デフォルトの名無しさん:2009/03/04(水) 09:53:16
>>271 は yhcの話しです。

273 :デフォルトの名無しさん:2009/03/04(水) 09:54:29
>>269
メジャーになったら飯が食えるというのは幻想です。
良い物がメジャーになってない場合、市場規模は小さいから仕事を探すのは大変ですが、
特殊技能者として高給をもらえる可能性があります。
日本じゃないけど金融なら Haskell で 3000万円/year な所はありますよ。

飯食えんとか言ってる人はそもそも飯食ってやろうという覚悟のない人か、
現在の市場で雇われるにはまだ能力が足りない人。

メジャーになったらIT土方が大量に流入してくるので当然単価が下がります。
ま、Haskell で土方やりたいんだったらどんどんメジャーにしてくださいw
(まぁHaskell は比較的土方が流入しにくい構造にはなってると思うが。)


274 :デフォルトの名無しさん:2009/03/04(水) 10:03:32
土方だって「飯は食える」よ。
ただIT土方は本物の土方と違って就業時間が厳しいが。

275 :デフォルトの名無しさん:2009/03/04(水) 10:18:49
んなこと言ってるから買いたたかれて土方になっちまうんだよ。


276 :デフォルトの名無しさん:2009/03/04(水) 10:22:06
cで土方やるよりhaskellで土方やる方がまだマシ

277 :デフォルトの名無しさん:2009/03/04(水) 12:48:31
正直、どうやったらITドカタにならざるを得ない状況になるのか分からない。
就職口もシステムエンジニアか研究職ばっかりだし、派遣だったら一発で分かるし、ブラック企業って臭いで分かるし、
ITドカタの人に聞きたいけどどういう仕事探ししてるの?

278 :デフォルトの名無しさん:2009/03/04(水) 12:53:35
最近、名刺は研究職だけど実態はドカタって人が増えてる気がする。

279 :デフォルトの名無しさん:2009/03/04(水) 13:27:42
定時と同じかそれより早く帰れて、年間休日150日ぐらいあって福利厚生がよくて(ry

280 :デフォルトの名無しさん:2009/03/04(水) 13:40:57
今なら仕事なくて定時帰宅多いんじゃね?

281 :デフォルトの名無しさん:2009/03/04(水) 14:28:41
そうでもない

282 :デフォルトの名無しさん:2009/03/04(水) 14:43:45
名ばかり研究職とか普通

283 :デフォルトの名無しさん:2009/03/04(水) 14:51:04
隙間風がピューピュー、雨漏りしまくりのボロアパートでネズミをペットにして霞を食べていきてるっていうのが平均的な研究者の生活水準

284 :デフォルトの名無しさん:2009/03/04(水) 14:57:08
小学生かよ

285 :デフォルトの名無しさん:2009/03/04(水) 16:40:27
http://codepad.org/IjH5NT71
二引数のブール関数の引数とその戻り値の組み合わせを演算の定義とみなして
ある演算規則のもと、<=>と同じ結果を返すものでかつ<=>と同じ定義でないもの以外を探索するプログラムです

Haskellらしく書けてますか?
あと、もっとシンプルに書きたいんですがなんかいい方針とかありますかね?

286 :285:2009/03/04(水) 18:39:57
上げてからMaybeの意味がないと気付いた…orz

287 :デフォルトの名無しさん:2009/03/04(水) 19:45:02
土方土方言ってる人って何なのww?

288 :デフォルトの名無しさん:2009/03/04(水) 20:00:50
蒸し返すお前から名乗れw

289 :デフォルトの名無しさん:2009/03/04(水) 21:07:33
土方の話題を蒸し返して申し訳ないですが、現状の土方プログラマ業界に
Haskellが浸透したらかなり業界の風景が変わるんじゃないかな。

そもそもHaskell使っただけで、今までの命令型言語で発生してた途轍もない
ゴミコードを書き散らすことがかなり抑制されるわけですよね。副作用を利用
した手続きの羅列が禁じられてるわけだから。

逆に言えば、そうやって手続きをズラズラ書き連ねることでしかコーディングできない
人々は、Haskellで書くことになった途端思考停止になって何も書けないんじゃないか。
そして、元々命令型でも綺麗にコーディングできる人たちは生き残る。

そういう淘汰がすぐにでも起きてほしいと思ってる人は多いと思う。プログラミング
を仕事にするのが敬遠されるのは、結局はゴミコード製造機のお守りをさせられて、
賃金が能力に比例しないからでしょ。Haskellが普及したら変わると思うんだけどなぁ。


290 :デフォルトの名無しさん:2009/03/04(水) 21:22:10
ゴミコードならすぐ上に上げられてるじゃないか

291 :デフォルトの名無しさん:2009/03/04(水) 21:23:53
>>289
で、例えば現存するHaskellのGUIライブラリについてどう思う?

292 :デフォルトの名無しさん:2009/03/04(水) 21:36:12
>>290
ひでえw

293 :デフォルトの名無しさん:2009/03/04(水) 21:50:02
>>289
ゴミコードを書く奴はどんな言語を使ってもゴミコード書くんです。

294 :デフォルトの名無しさん:2009/03/04(水) 22:35:52
>>290
じゃあ、どこがどうゴミなのか解説してあげて。 その一行なら誹謗中傷に等しいじゃないか
尋ねてきてる人に何言ってんだ。と思ったよ。

295 :デフォルトの名無しさん:2009/03/04(水) 22:47:48
>>285
せっかくリストモナド使うなら、patternsはこう書ける。

patterns n = if n > 0
  then do
   ps <- patterns (n-1)
   ft <- [False, True]
   return (ps ++ [ft])
  else [[]]

296 :デフォルトの名無しさん:2009/03/05(木) 01:23:02
Haskellでも「副作用を利用した手続きの羅列」と同等な構造のコードは書けるし、書けないと困る

297 :デフォルトの名無しさん:2009/03/05(木) 07:40:34
土方にHaskell書かせたら、引数が10個以上ある関数が山のように作られるだけ。

298 :デフォルトの名無しさん:2009/03/05(木) 09:00:12
>>285
http://codepad.org/xbkr4jcX
特にどうということはないけど、
・isAssociative あたりの定義がおかしかった
・関数の場合しか考えてなさそうなので、
relation じゃなくて table にした
・一般化のバランスがおかしいと思った
(トップレベルにある fromListPair, db, search や DB型 とか)

299 :デフォルトの名無しさん:2009/03/05(木) 10:31:55
>>298
allTable = [zip domain zs | zs <- patterns (length damain)]
のほうがいいのと、>>285の意図は
p t = all (\q -> q (tab2op t) == q iff) ps where iff = (==)
っぽい

300 :285:2009/03/05(木) 17:56:11
ありがとうございます!!
なんと行数が半分になるなんて…
sequenceやこの形でのパターンマッチは知りませんでした
最低でもPreludeだけは一通り触っておく必要性を感じました

301 :デフォルトの名無しさん:2009/03/07(土) 00:03:14
http://donsbot.wordpress.com/2009/03/04/playing-with-ghcs-parallel-runtime/
こんなん出たんやね。ぱられるらんたいむだよ!ぱられるだよ!

302 :デフォルトの名無しさん:2009/03/07(土) 02:00:19
もうイヤ

303 :デフォルトの名無しさん:2009/03/08(日) 12:46:40
例えば g の関数を適用してから f の関数を適用するような関数を作るには単純に関数合成を行なえば良いわけですが、

> fg = f . g

g が2個以上の引数を受けとる関数の場合は引数を明示的に書く必要があります。

> fg x y = f (g x y)

ポイントフリーにすることも出来ますが、とたんにゴチャゴチャした書き方になってしまいます。
(Haskellには2個以上の引数を受取る関数など無い! という話もありますが、説明の便宜上のことなので 御容赦下さい。)

そこで、右側での適用を終えてから左側の関数へ適用するような演算子を定義できないものかと考えました。

> fg = f .$ g

こうすると g が2引数でも3引数でも対応できるような演算子 .$ があれば便利ではないかと。
で、以下のふたつの定義を考えてみたのですが、うまくオーバーロードさせるためのクラス定義がどうにも思い付きません。

> (.$) :: (a -> b) -> a -> b
> f .$ g = f g
>
> (.$) :: (a -> b) -> (c -> d) -> (c -> b)
> f .$ g = \x -> f .$ g x

「ふつうのHaskellプログラミング」を読み返してみるとクラス定義の説明がえらく簡単で、あんまりわからなかったんですが、
この本で説明されているHaskellの機能だけで実現できるものでしょうか?

304 :デフォルトの名無しさん:2009/03/08(日) 16:29:53
>>303
Haskell 98 の範疇ではできないと思う。
下のような感じになるんだろうけど、
fundep が足りないのか、flexible や undecidable が悪いのか、
((sum :: [Int] -> Int) .$ take) 5 ([1..10] :: [Int])
のように型をはっきりさせないと no instance って怒られる。

{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
             FlexibleInstances, UndecidableInstances #-}

class FApp a b f g | a b f -> g where
    (.$) :: (a -> b) -> f -> g

instance FApp a b a b where
    f .$ x = f x

instance FApp a b f g => FApp a b (c -> f) (c -> g) where
    (f .$ g) x = f .$ (g x)

305 :デフォルトの名無しさん:2009/03/08(日) 16:32:37
>>303
class (Functor f) => Applicative f where
pure :: a -> f a
(<*>) :: f (a -> b) -> f a -> f b
-- Defined in Control.Applicative
ということ?

或いは、

ap :: (Monad m) => m (a -> b) -> m a -> m b
-- Defined in Control.Monad
のこと?

306 :デフォルトの名無しさん:2009/03/08(日) 19:21:55
>>303
関数の型が与えられても引数の数は決まらないから無理だと思う
例えばconstは定数関数を作る一引数の関数として使うことが多いけど、型だけ見たら二引数関数に見える
idは型を見れば一引数関数だけど、Just `id` 4みたいな使い方も可能

妥協して純粋に型の「見た目」だけで引数の数を決定するなら、GHC拡張を使って実現できた

{-# LANGUAGE IncoherentInstances, OverlappingInstances, TypeFamilies, FlexibleInstances,
  MultiParamTypeClasses, UndecidableInstances, ScopedTypeVariables #-}
module Curried where
  class Curry f args result where
    curryP :: (args -> result) -> f
  class Uncurry f args result where
    uncurryP :: f -> (args -> result)
  instance (Curry rf as result, f ~ (a -> rf)) => Curry f (a, as) result where
    curryP c x = curryP (\as -> c (x, as))
  instance (Uncurry b as result, args ~ (a, as)) => Uncurry (a -> b) args result where
    uncurryP f (a, as) = uncurryP (f a) as

module Main where
  import Curried
  instance (f ~ result) => Curry f () result where
    curryP c = c ()
  instance (args ~ (), result ~ f) => Uncurry f args result where
    uncurryP f () = f
  ($.) :: forall f g a b c. (Uncurry f a b, Curry g a c) => (b -> c) -> f -> g
  f $. g = curryP (\x -> f (uncurryP g (x :: a)))
  -- テスト
  main = print $ ((+1) $. const) 100 200

モジュールを分けないとコンパイル通らないあたり怪しげな匂いがプンプンするが

307 :303:2009/03/08(日) 20:38:55
>>304
私が漠然と想像してた形に近いです。
型を書かないといけないのは、
sum とかはオーバーロードされてるからですかねぇ。

クラス定義のところのその型変数の書き方の意味がよくわかってないので、
まずはそこを学ばないといけないようです。

>>305
どちらも違うと思います。

今回、このような演算子があればよいなぁと思ったのは
Gauche にある compose っぽいのをイメージしてたのです。
.$ という演算子も Gauche で compose の別名として定義されてるので
そのままもってきました。
合成と適用をうまいことやってくれる演算子としてピッタリな気がしたので。

>>306
結構な大作をありがとうございます。
今の私ではそう簡単に理解できなさそうですが。
色々なオプションがあるんですねぇ。

> 関数の型が与えられても引数の数は決まらないから無理だと思う
> 例えばconstは定数関数を作る一引数の関数として使うことが多いけど、型だけ見たら二引数関数に見える
> idは型を見れば一引数関数だけど、Just `id` 4みたいな使い方も可能

Haskell で単純に引数の数を利用することは出来ないとは思っているので、
f .$ g で f を g に適用可能な場合には適用して、
そうでない場合には g をもうひとつ何かに適用してから、
という風な場合分けで考えてました。

308 :デフォルトの名無しさん:2009/03/11(水) 18:28:45
関数コンストラクタ (->)って何か読み方あるんでしょうか?

309 :デフォルトの名無しさん:2009/03/11(水) 21:20:34
♂の尖ってる部分

310 :デフォルトの名無しさん:2009/03/12(木) 01:58:55
右って読んでる

311 :デフォルトの名無しさん:2009/03/12(木) 11:12:18
やじるし

312 :デフォルトの名無しさん:2009/03/12(木) 12:23:14
あろー

313 :デフォルトの名無しさん:2009/03/13(金) 12:09:52
real world haskellがjolt awardとったみたいよ。

http://www.joltawards.com/winners.html

314 :デフォルトの名無しさん:2009/03/13(金) 12:20:34
おめでとう >>313 きみはこれから明い道が開いているよ

315 :デフォルトの名無しさん:2009/03/14(土) 16:55:10
リストのn番目の内容を取り出すのはどうすれば良いですか
ls[n] じゃダメですよね?

316 :デフォルトの名無しさん:2009/03/14(土) 16:57:54
ダメに決まってるだろ!!

317 :デフォルトの名無しさん:2009/03/14(土) 17:58:54
自分で調べろよ!!

318 :デフォルトの名無しさん:2009/03/14(土) 18:45:52
!!

319 :デフォルトの名無しさん:2009/03/14(土) 18:52:43
お前ら優しいな!!

320 :デフォルトの名無しさん:2009/03/15(日) 14:02:30
>316
ダメなのは判るのですが、それをHaskellでどう書けば良いのか判らないのです…。

>317
何でググれば良いでしょうか?
Preludeは一通り見たのですが、takeくらいしか見当たりません。
かと言ってリストをArrayに全部移すのも違うだろうし…。

321 :デフォルトの名無しさん:2009/03/15(日) 14:06:36
ググってわからなければふグれ
http://haskell.org/hoogle/?q=(!!)

322 :デフォルトの名無しさん:2009/03/15(日) 14:27:37
>321
!!
英字の関数名ばかり見てました…orz

>316-319
何気に答えられていたことに気付きませんでした…すみません

323 :デフォルトの名無しさん:2009/03/15(日) 16:24:46
Hoogleで関数の名前が知りたい時は型で検索するといいよ
http://www.haskell.org/hoogle/?hoogle=%5Ba%5D+-%3E+Int+-%3E+a

324 :デフォルトの名無しさん:2009/03/16(月) 00:15:29
ふグるとな・・・

325 :デフォルトの名無しさん:2009/03/16(月) 17:18:07
ふぐりますか?ふぐりませんか?

326 :デフォルトの名無しさん:2009/03/16(月) 17:29:01
エロサイトでも調べとんのかと思うぞ^^;<ふぐる

327 :デフォルトの名無しさん:2009/03/16(月) 22:38:21
HaskellでSetの中身を指定した書式で表示したいときとかってどうするのでしょうか?

OCamlでは例えば(int, int)のTupleのSetをダンプしたいときはSet.iterを使って、

module TupleSet = Set.Make (...(省略)
let dump = TupleSet.iter (fun (a, b) -> Printf.printf "%d/%d\n" a b)

というようにできるのですが、HaskellのSetにはiterのような関数はありません。

私が思いついたのは、

import Data.Set (elems)
import Text.Printf (printf)

dump set = mapM_ (\(a, b) -> printf "%d/%d\n" a b) $ elems set

または

dump set = mapM_ (\(a, b) -> putStrLn $ show a ++ "/" ++ show b) $ elems set

というようなコードですが、もっとHaskellっぽいスマートなやり方があるような気がします。

328 :デフォルトの名無しさん:2009/03/16(月) 23:26:04
要素を列挙するときに一旦リストを介するのは十分Haskellっぽいやり方だと思う

見た目を気にするなら
mapM_ (\(a, b) -> ...) $ elems set
より
forM_ (elems set) $ \(a, b) -> ...
の方がスマートかもしれん

あるいは、
dump set = putStr $ unlines $ map format $ elems set
  where
    format (a, b) = ...
みたいに、一番外側までしかIOを絡ませない方がHaskellっぽいかも

329 :デフォルトの名無しさん:2009/03/17(火) 01:06:19
>> 328
レスありがとうございました。

確かにIOが途中で登場するより、最後に出てきたほうがスマートですね。

教えていただいたforM_からFoldableというクラスがあることを知り、そこからconcatMapが使えそうな気がしてきました。
リストモナドの(>>=)がconcatMapであることを利用して、今のところ

dump set = putStr $ elems set >>= format
where format (a, b) = ...

辺りまでたどり着きました。

330 :デフォルトの名無しさん:2009/03/17(火) 08:14:07
難読化の好きそうな人だな

331 :デフォルトの名無しさん:2009/03/17(火) 18:52:27
難読というほどのものでもないだろ

332 :デフォルトの名無しさん:2009/03/19(木) 12:22:50
Fizz-Buzz問題をHaskellで書いてみました。どうでしょうか?

hoge :: Int -> String -> (Int, String) -> (Int, String)
hoge m s nt@(n, t) = if n `mod` m == 0 then (n, s ++ t)
else nt

fizz :: (Int, String) -> (Int, String)
fizz = hoge 3 "Fizz"

buzz :: (Int, String) -> (Int, String)
buzz = hoge 5 "Buzz"

piyo :: (Int, String) -> String
piyo (n, "") = show n
piyo (_, s) = s

fizzbuzz :: Int -> String
fizzbuzz n = piyo $ fizz $ buzz (n, "")

main = putStr $ unwords $ map fizzbuzz [1..100]

333 :デフォルトの名無しさん:2009/03/19(木) 12:58:59
今日の一行 fizzbuzzでググれ

334 :デフォルトの名無しさん:2009/03/19(木) 13:03:04
Haskell関係なく、(Int, String) -> (Int, String)を作るあたりがまわりくどいな
fizzとbuzz以外のルールを将来追加する可能性を考えてそういう形にしてるの?

それから、ググったら同じ構造のコードが出て来たんだが、引用元に批判を加えて欲しいの?

335 :デフォルトの名無しさん:2009/03/19(木) 13:04:39
>>334>>332へのレス

336 :デフォルトの名無しさん:2009/03/19(木) 13:27:03
>>335
問題から素直に、fizz :: Int -> String で作ったら数字が出なくて
当てはまらない時は数字を返すようにしたら、5Buzzってなって
しょうがないのでタプルにしてStringが無いときは数字、あるときはStringにしました。
やっぱり一つの関数にして複数のifで分岐するような作りの方がいいのでしょうか?

337 :デフォルトの名無しさん:2009/03/19(木) 13:52:05
たった三つの分岐だし、俺なら一つの関数内で全部やるな
それが嫌なら、

fizz, buzz :: Int -> String -- 該当しないときは空文字列を返す
みたいなのを用意して、
case fizz n ++ buzz n of
  "" -> show n
  s -> s
とか
あるいは、空文字列が技巧的だと思うならMaybeでもいい

338 :デフォルトの名無しさん:2009/03/19(木) 14:17:22
>>332のアイデアで

module FizzBuzz where

data Fb = S [Char] | I Integer
instance Show Fb where
show (S s) = s
show (I x) = show x

hoge w n (S s) = S s
hoge w n (I x) | x `mod` n == 0 = S w
| otherwise = I x

fizzbuzz = hoge "FizzBuzz" 15
fizz = hoge "Fizz" 5
buzz = hoge "Buzz" 3

main = putStr $ show $ take 100 $ map (buzz. fizz . fizzbuzz . I) [1..]

339 :デフォルトの名無しさん:2009/03/19(木) 15:20:07
>>337
アドバイスありがどうございます。case文は勉強になりました。
再帰の練習も兼ねて書き換えてみました。

hoge :: [(Int, String)] -> (Int, String) -> (Int, String)
hoge [] ns = ns
hoge (x:xs) ns@(n, s) = if n `mod` fst x == 0 then hoge xs (n, snd x ++ s) else hoge xs ns

piyo :: [(Int, String)]
piyo = [(3, "Fizz"), (5, "Buzz")]

fizzbuzz :: Int -> String
fizzbuzz n = case hoge piyo (n, "") of
(n, "") -> show n
(_, s) -> s

main = putStr $ unwords $ map fizzbuzz [1..100]

340 :デフォルトの名無しさん:2009/03/19(木) 16:09:35
流れに乗り遅れた予感。
特に意味はないけどモナドにしてみた。

> import Control.Monad
> import Text.Show
>
> data FizzBuzz a = FizzBuzz String | Foo a
>
> instance Monad FizzBuzz where
> FizzBuzz a >>= k = FizzBuzz a
> Foo a >>= k = k a
> return = Foo
>
> instance (Show a) => Show (FizzBuzz a) where
> show (FizzBuzz a) = show a
> show (Foo a) = show a
>
> exam :: (a -> Bool) -> String -> a -> (FizzBuzz a)
> exam f s x = if (f x) then FizzBuzz s else Foo x
>
> x /? n = (x `mod` n) == 0
>
> fizzbuzz x = return x
> >>= exam (/? 15) "FizzBuzz"
> >>= exam (/? 3) "Fizz"
> >>= exam (/? 5) "Buzz"
>
> main = forM_ [1..5] (print . fizzbuzz)


341 :デフォルトの名無しさん:2009/03/19(木) 19:20:30
素直にこんなんじゃいかんの?
main = putStrLn $ unwords $ map fizzbuzz [1..100]
 where
  fizzbuzz x
   | x `mod` 15 == 0 = "FizzBuzz"
   | x `mod` 5 == 0 = "Buzz"
   | x `mod` 3 == 0 = "Fizz"
   | otherwise = show

342 :デフォルトの名無しさん:2009/03/19(木) 20:35:57
>>341
いいんだけど、それじゃ、盛り上がらんだろう

343 :デフォルトの名無しさん:2009/03/19(木) 20:50:10
>>341
一つの関数でやるって話はずっと前から出てるだろ

344 :デフォルトの名無しさん:2009/03/19(木) 20:52:39
main=mapM putStrLn[max(show n)$3%"Fizz"++5%"Buzz"|n<-[1..100],let(%)m=drop$n`mod`m*4]

345 :デフォルトの名無しさん:2009/03/19(木) 22:33:04
darcsでは,かなり賢いパターンマッチを使ったパッチ当てが行われているのでしょうか

346 :デフォルトの名無しさん:2009/03/20(金) 13:15:22
darcsはあなたの10倍程度賢いです

347 :デフォルトの名無しさん:2009/03/21(土) 17:18:15
software designの今月号でhaskell特集(intro)しているね
http://gihyo.jp/magazine/SD/archive/2009/200904

348 :デフォルトの名無しさん:2009/03/21(土) 19:18:34
>>346
ほとんど神の領域ということですね わかります

349 :デフォルトの名無しさん:2009/03/21(土) 20:18:23
そうです。神にもっとも近い言語です。
Haskellを極めれば、ほかの低俗な言語がクズに思えてきます。

350 :デフォルトの名無しさん:2009/03/21(土) 20:48:49
Haskellはカルト

351 :デフォルトの名無しさん:2009/03/21(土) 21:42:22
一部の人だけな

352 :デフォルトの名無しさん:2009/03/22(日) 04:00:10
>>349
darcsは言語じゃねーだろ、アホか。

353 :デフォルトの名無しさん:2009/03/22(日) 04:08:51
┐(´ー`)┌

354 :デフォルトの名無しさん:2009/03/22(日) 20:20:15
>>352
darcsは宗教だw

355 :デフォルトの名無しさん:2009/03/25(水) 18:46:30
遅延評価って無敵に最強なの?なんか弱点とかないの?
Haskellの宣伝を聞いているとアホな俺がなにも考えなくてもいいのかと思えてきました。

356 :デフォルトの名無しさん:2009/03/25(水) 18:48:18
遅延評価それ自体のコストが大きいこと?

357 :デフォルトの名無しさん:2009/03/25(水) 18:57:05
遅延評価自体のコスト…ですか。
それは実行時、それともコンパイル時でしょうか?
コストの種類は空間的なものですか、時間的なものですか?それとも処理系の複雑さでしょうか。
たとえば再帰でいう末尾再帰のように使い方によって差がでたりするのでしょうか。

ちょっとマンガ買うかHaskellの本の買うか迷ってまして。

358 :デフォルトの名無しさん:2009/03/25(水) 19:11:28
実行時に時間的にも空間的にもコストがある
時間的コストはせいぜい積極評価の場合の定数倍だけど、ボトルネックにひびくこともある
空間的コストは慣れないとまったく予測できない。マジヤバい

96 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)