[過去ﾛｸﾞ]
関数型言語ML (SML, OCaml, etc.), Part 6 (1002ﾚｽ)
関数型言語ML (SML, OCaml, etc.), Part 6 http://mevius.5ch.net/test/read.cgi/tech/1245017721/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
305: デフォルトの名無しさん [] 2010/06/04(金) 20:44:13 これも、一種のスタイル問題だが、 列挙型を定義するときに、 datatype X = X1 | X2 | X3 | ... とするか type X = int val X1 = 1 val X2 = 2 ... とするかで悩んでしまう。最初は、vector (ランダムアクセス)を使わない 見込みだったのだが、必要になったときのことを心配してしまう。 http://mevius.5ch.net/test/read.cgi/tech/1245017721/305
356: デフォルトの名無しさん [] 2010/11/11(木) 21:19:26 >>305 解決策(SML/NJの場合の)が見つかった。 data label = A | B | C Unsafe.cast A: int; Unsafe.cast B: int; Unsafe.cast C: int; とすると、それぞれ0,1,2になる。 http://mevius.5ch.net/test/read.cgi/tech/1245017721/356
357: デフォルトの名無しさん [sage] 2010/11/11(木) 21:49:53 >>356 MLは初心者だけど、>>305は(コードの問題ではなく)設計の問題だと思う。 代数構造として、直積(組型やレコード型)と列(リスト型や配列型)は全く別の概念。 コンパイルの前に要素の数が決定できるなら直積を使うべきだし、 実行してみないと決定できないのなら列を使う。あるいは動的なシンボルで ランダムアクセスしたいならハッシュ型を、更に順序性が必要ならB木型を。 これらすべてはプログラムの設計工程で決定しておくべきもの。 設計工程での不具合をコーディング工程で取り返そうとするのは、よくある過ち。 >>356の解決策というのは、いわゆる「泥縄」的手法。いずれ破綻する。 いくらMLが美しい言語でも、設計が汚ければコードはグチャグチャになるよ。 逆に、設計が適切であれば手続き型言語であっても美しいコードは書ける。 http://mevius.5ch.net/test/read.cgi/tech/1245017721/357
363: デフォルトの名無しさん [sage] 2010/11/11(木) 22:39:12 >>357 根拠は、>>305が使った「スタイル」と言う言葉。 >>361 ＞単にmapの効率的な表現でしかないだろ……。 その通り。より正確には「写像の効率的な実装(コード化)」だね。 >>357で書いたのは、実装(コード化)で解決しようとせずに設計に立ち返りなさい、という話。 http://mevius.5ch.net/test/read.cgi/tech/1245017721/363
368: 365 [sage] 2010/11/11(木) 23:14:44 落ちたつもりだったけど、自分のカキコにアンカ間違いがあったから、そこだけ訂正。 >>366 スマン。>>363の >>>357 >根拠は、>>305が使った「スタイル」と言う言葉。 という部分の>>357というアンカは間違いだった。>>360宛のレスとして読み直してくれ。 http://mevius.5ch.net/test/read.cgi/tech/1245017721/368
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.042s