関数型言語ML (SML, OCaml, etc.), Part 6

test

OCamlのマニュアルにocamlbrowserがまだあるのはバグっすな

ocamldoc/trunk/manual/cmds/Makefile line#2
remove "browser.tex "

ocaml標準のlexでは日本語が扱えないのでulexに差し替えたらparserが死んだでござる。
ダメだこりゃ

>>868
ttps://github.com/darioteixeira/ccss/blob/master/src/ccss.ml#L25
menhirとulexを一緒に使う方法。

ocaml 4.01.0で
# Obj.size @@ Obj.repr 1
がバグるんだけど、理由わかる？

仕様です。
ソースはおろかドキュメントすら読まずにObjを使うとはアホの極みです。

Chapter "Interfacing C with OCaml", Section 2..3

OCamlのすごさはもっと知られるべき #オブジェクト指向 や #関数型 は「敗者の道具」である http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/092200062/?ST=develop&P=3

>>872
これタイトルで損してる記事だろ

みかかデータ、マンセー記事っぽかったけど

関数型とかマルチパラ代務とかドカタには無理。オブジェクトだって散々語られてようやく、いや未だ、か

一部の突出した集団以外は、ほかにどうしようもない人が沈殿する職業になってるイメージ

do構文の使用禁止の規約って全部>>=で書くってことなのだろうか。理由も含めて気になる。

>>872
前半で散々オブジェクト指向をこきおろしておきながら、
中盤でOCamlを推すという意味不明な文章の論理の展開がある
ML族を推すのなら Caml か SML にしないと一貫性が無いし、
Caml にオブジェクト指向を後付けした "O"Caml 開発時の判断は
今となっては流行に踊らされた大きな失敗であったと断罪すべき

おまけに「個人的にOCamlがすごいと思う」とあるから何かと読んでみたら、
単なるパラメタ型多相の話でしかないことに笑ってしまった
「とがった」とか「すごい」とか、小学生の感想文とレベルは変わらない
こんなポエム記事で給料をもらえるのだから、日経ITproの記者とは楽な職業だね

>>873
タイトル以前の問題で、記事に中身が無くて話にならん

>>876
ソースコード解析ツールなら言語処理系と似た構造になるから、
(一般的には副作用を模倣するために使われる)do記法を使う必要性は無いと思われ

ちょっとぐぐってみたらこういうページがあった。
http://www.haskell.org/haskellwiki/Do_notation_considered_harmful

たしかにタイトルで損したみたいだな

ああいう煽り記事読んでドキドキするのは思春期の子供だけ
もっと大人向けの真面目に面白い記事は無いのか？

　もし完全無欠のプログラマが存在するのであれば、そうした方法論に頼らなくても、
完全に意図通りに動作するプログラムを頭から書き下していけばいいのです。
オブジェクト指向プログラミングや関数型プログラミングは、不完全な人間のために用意されたもの、
いわば「敗者の道具」といえます。

　もちろん、これは極端すぎる表現です。例えば、人は空を飛べないので飛行機に乗ります。
このことをもって「飛行機は敗者の道具である」と言う人はいません。
そうした意味では、オブジェクト指向プログラミングや関数型プログラミングを敗者の道具と呼ぶのは、
単なる言葉遊びにすぎません。人間が全知全能でないのは当たり前ですから。



完全に朝日脳だな

産経信者も一緒に死ねカス

今回朝日がしでかしたことを誰かまとめてくれ

スレ違いカスはお引き取り下さい

>>883
どいたかこ死亡

土井たか子がリアルに退いた過去になったのか

土井がどいた過去

おんたけさんが噴火して
おたけさんが逝った

対話環境を再起動せずに、リコンパイルしたライブラリをロードし直す方法ってありますか？
#load でもう一度ロードすると、シグニチャが異なると怒られてしまいます

OCamlで型クラスを実現する方法ある？
あとカインドも

モジュールで型クラス的なものを作ることができる。便利とは言いがたいが

Haskell より OCaml の方が部分部分で好みなんだけど、
OCaml は最近何か進展とか発展とか無いのかな。

4.0出たばっかじゃなかったっけ

岡村はソース醜いのがなあ

>>894
たとえば？

上から読んでいけば何しているのか分かるOCamlのソースは読みやすい部類
batteriesとかcoreといった大きいライブラリでも、モジュールと同名のファイル見ればいいだけなので、
どこに何があるのか探しやすい

基本的に手続き脳なので、haskellはどこから読めばいいのか分からない
悪名高いimport文のおかげでもっと読めない

OCamlなんとなくソースの見た目のバランスが悪いっていうのはなんかわかるわ。

>>897
まさにそんなとこ。ぱっと見よくない

ソースが読みにくい言語は致命的に生産＆保守効率が悪い。

>>898
？
SMLならいいの？

レコード型ある言語、多相レコードある言語、フィールドがファーストクラスにできる言語
おしえて。
ぜんぶもってるのがいい。

>>901
SML# という Standard ML の処理系は「ぜんぶもってる」よ
　　# fun get_x {X = x, ...} = x;
　　val get_x = fn : ['a#{X: 'b}, 'b. 'a -> 'b]
　　# val point_2d = {X=1.0, Y=2.0};
　　val point_2d = {X = 1, Y = 2} : {X: real, Y: real}
　　# val point_3d = {X=10.0, Y=20.0, Z=15.0};
　　val point_3d = {X = 10, Y = 20, Z = 15} : {X: real, Y: real, Z: real}
　　# get_x point_2d;
　　val it = 1 : real
　　# get_x point_3d;
　　val it = 10 : real

Standard ML の場合、前２つは言語仕様で規定されているからすべての処理系で利用できるけど、
最後の「フィールドがファーストクラス」であることは仕様では要求されていない
たとえば SML/NJ という処理系だと、上記のコードはエラーになる
　　- fun get_x {X = x, ...} = x;
　　stdIn:1.2-1.28 Error: unresolved flex record
　　(can't tell what fields there are besides #X)

SML# が独自に拡張したレコード型に関しては、SML# プロジェクトのホームページに
日本語の解説があるから、まず最初に読んでみるのがいいと思う
・SML#の拡張機能：レコード多相性 in プログラミング言語SML#解説
　http://www.pllab.riec.tohoku.ac.jp/smlsharp/docs/2.0/ja/Ch7.xhtml

↑ありがと。
ほんとにぜんぶ！？　フィールドファーストクラスなのその言語？

あ、かいてあった、ごめん。

SML/NJってやつは、フィールドがファーストじゃないとして、
SML#ってやつはファーストなの？

ほかにも>>900 全部持ってる言語とかあればおしえて。みんな。

１．レコード型、あるいは、それに類する型を持つ
２．レコード型（or それに類する型）の構造的部分型関係を扱える
３．できれば、多相レコード型とかそれと同様なのを持つ
４．できれば、レコードのフィールド名がファーストクラス
( x = [name = 3] : [name : int] なら　nameがファーストクラス）

これカバーできる言語ない？
うえでおしえてもらったのしらべてみたけど
SML/NJってのは１，２を満たしてそう
SML#ってのが1,2,3を満たしてそう、
あと
scalaが無名オブジェクトみたいなやつで1,2,3を満たしてそう？
　　　型を一部か書かないとダメだけど
ほかにこの辺でなんかいい言語ない？
clojure? ってのが4みたして相だけどコンパイル時に型ちぇっくしてくれないよねそれ？
　　うーんなんかない？

1

じゃあ俺は2

宿題は自力でやれw

>>906
Standard ML のレコード型は構造的部分型関係を持たないよ
構造的部分型関係を持つレコード型に類する型を持つのは OCaml や Java
いわゆるオブジェクト指向におけるクラスとそれらの間の継承関係のこと

また「多相レコード型」という用語の意味が「パラメタ型多相なレコード型」
であるならば、Standard ML は多相レコード型を持つことになる
ここでパラメタ型多相は、Java だとジェネリクス(総称型)と呼ばれている

結論として、Standard ML(とその処理系 SML/NL および SML#)は１と３を満たす


次にファーストクラスについて、>>902 のコードにおける関数 get_x の定義だけど、
　「フィールドとはレコード値からフィールド値への写像(関数)である」
という関係に気付けば、その定義は以下のように簡潔になる
　　# val get_x = #X;
　　val get_x = fn : ['a#{X: 'b}, 'b. 'a -> 'b]　　(* SML/# *)
つまりフィールド #X は(val宣言で)識別子に束縛したり、他の関数へ適用したり。
ある関数の評価結果として返すことができる
こうした数値や文字列といった値と同等に扱える性質を指してファーストクラスと呼ぶ

さらに上記の例は SML# だけど、SML/NJ も型システムが単純たから型推論に失敗するだけで、
データ型を明示的に宣言すれば関数 get_x を定義できる
　　- val get_x = #X : {X: real, Y: 'a} -> real;
　　val get_x = fn : {X:real, Y:'a} -> real　　　(* SML/NJ *)
型システムの制約とファーストクラスという性質をごっちゃにすべきではない

まとめると、Standard ML(とそのすべての処理系)のフィールドはファーストクラスである

> 　　- val get_x = #X : {X: real, Y: 'a} -> real;
でもこの get_x って、>>902 の point_3d には使えないよね。

うん、使えない
それが >>910 で書いた(Standard ML言語仕様における)「型システム」の制約だね
その制約を無くした SML# が特異なだけで、SML/NJ 以外の大半の SML 処理系に同じ制約がある

>>910
>Standard ML のレコード型は構造的部分型関係を持たないよ
>構造的部分型関係を持つレコード型に類する型を持つのは OCaml や Java
>いわゆるオブジェクト指向におけるクラスとそれらの間の継承関係のこと

自己レスだけど、この段落は間違いが含まれていたので訂正する

まず：
>Standard ML のレコード型は構造的部分型関係を持たないよ
この文章は正しいけど、SML# は「構造的」部分型関係に類する型を持つ
だから >>902 の関数 get_x は point_2d とpoint_3d のどちらにも適用できる(>>911)
そして SML# だと、point_2d と point_3d のそれぞれの型について、
{X: real, Y:real} >= {X: real, Y:real, Z: real} という部分型関係を持ち、
ここで 関係 a >= b は「a の部分型が b である」ことを意味する

次に：
>構造的部分型関係を持つレコード型に類する型を持つのは OCaml や Java
>いわゆるオブジェクト指向におけるクラスとそれらの間の継承関係のこと
この文章は完全な間違いで、正しくは
「「非構造的」部分型関係を持つレコード型に類する型を持つのは OCaml や Java (...後略)」になる
たとえば(架空言語で)二次元座標上の点として 抽象クラス {} を定義し、その具象クラスとして
{X軸: real, Y軸: real} および(原点からの相対的な) {角度: real, 距離: real} を定義できる
ここで、２つの具象クラスのフィールド構成(=内部的構造)は全く異なるけれど、
{} >= {X軸: real, Y軸: real} および {} >= {角度: real, 距離: real} という部分型関係を持つ

MLで株取引してるヤツおる？

>>914
https://www.janestreet.com/