関数型プログラミング言語Haskell Part24
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2013/10/25(金) 21:54:29.92前スレ: 関数型プログラミング言語Haskell Part23
http://toro.2ch.net/test/read.cgi/tech/1376111807/
haskell.org
http://www.haskell.org/
日本語サイト
http://www.sampou.org/cgi-bin/haskell.cgi
http://www.shido.info/hs/
過去ログ (10〜)
Part21 ttp://toro.2ch.net/test/read.cgi/tech/1358702176/
Part20 ttp://toro.2ch.net/test/read.cgi/tech/1350428908/
Part19 ttp://toro.2ch.net/test/read.cgi/tech/1340760070/
Part18 ttp://toro.2ch.net/test/read.cgi/tech/1331902463/
Part17 ttp://toro.2ch.net/test/read.cgi/tech/1325510368/
Part16 ttp://toro.2ch.net/test/read.cgi/tech/1317958045/
Part15 ttp://hibari.2ch.net/test/read.cgi/tech/1310199414/
Part14 ttp://hibari.2ch.net/test/read.cgi/tech/1299385928/
Part13 ttp://hibari.2ch.net/test/read.cgi/tech/1286706874/
Part12 ttp://hibari.2ch.net/test/read.cgi/tech/1272536128/
Part11 ttp://pc12.2ch.net/test/read.cgi/tech/1252382593/
Part10 ttp://pc12.2ch.net/test/read.cgi/tech/1231861873/
0002デフォルトの名無しさん
2013/10/25(金) 21:55:57.09,,ｲ`" ､-' `;_' ' ..::::::::::::::...
,-､ _.._ ( (,(~ヽ'~ ..:::::::::::::::::::::::
）'~ ﾚｰ' 〉 ヽ i`'} .:::::::::::::::::::::::
~つ '-ｰ､ i | i' ...:::::::::::::::::::::::
／ < / 。/ ! ......::::::::::::::::::::::::: これは>>1乙じゃなくて
/ ~^´ /},-'' ,●::::::::::::::::::::::::::::::::::::
i､ ,i' _,,...,-‐-､/ i :::::::: .:::::::::::::
..ゝ <,,-＝=､ ,,-,/ .::::::::::: 放射能がうんたら
) {~''~>`v-''`ｰﾞ`'~ ..::::::::: ........::.
{ ﾚ_ﾉ ..::::::::. ......:::::::::
ノ '' ..::::::: ...::.:...:::::::::
.::::::::: ...:......:::::::::::: .
.:::::::::::. ..... .. ..:::::::::::::::::::::::: :::.
::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::.. :: ::..
.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::: ::.
::::::::::::::::: :::::::::::::::::::::::::::::: :::::
.:: ::. :::
0003デフォルトの名無しさん
2013/10/25(金) 21:57:45.35Part23 http://toro.2ch.net/test/read.cgi/tech/1376111807/
Part22 http://toro.2ch.net/test/read.cgi/tech/1364009659/
Part21 ttp://toro.2ch.net/test/read.cgi/tech/1358702176/
Part20 ttp://toro.2ch.net/test/read.cgi/tech/1350428908/
0004デフォルトの名無しさん
2013/10/26(土) 03:58:23.29http://www.digitaltrends.com/wp-content/uploads/2013/02/gtav.jpg
C#の限界
http://www.stfuandplay.com/images/uploads/GunsIO-TOP.jpg
Haskellの限界
http://www.haskell.org/wikiupload/c/c2/Frag1.png
0005デフォルトの名無しさん
2013/10/26(土) 19:26:01.370006デフォルトの名無しさん
2013/10/26(土) 21:50:44.570007デフォルトの名無しさん
2013/10/26(土) 21:56:56.30C#←空中戦艦
Haskell←ソルジャー
C++が最弱！ありえん！なんで自転車！
0008デフォルトの名無しさん
2013/10/26(土) 22:32:02.64他の言語と同じだよ。
1. まず Hello World 含むトイプログラムを何十個と書いては実行し、
主な文法や機能を身に付ける。
2. 次にそれらのプログラムの実行がなぜ意図した結果になるのか、
中でどのような処理が行われているのか、その意味を理解する。
ただし、Haskell の場合は C や Java などと違ってここが難解なので、
具体的にコンパイラがどのようなコードを吐くかまでは理解しなくてもよい。
もっと抽象的に、プログラムを順に弱頭部正規形に簡約して評価していく様子が
頭に思い浮かべることができれば十分。
3. 何か小さなアプリをいくつか作り上げてみる（完成させるのがポイント）。
linux の echo コマンドや cat コマンドの簡易版でも良い。
完成したら、いくつか機能を付け加えてみる。
4. いくつか作ってみるうちに、ボイラープレートを何とかしたいなとか、
もっと簡単に機能を加える方法はないものかとか、
なんかプログラムが汚くてかっこ悪いなとか、いろいろ思うところが出てくる。
そうしたら、他人のコードを見たり、BBSで質問したり、
問題を解決してくれそうなライブラリを探したりすればいい。
実際はこんな綺麗にステップアップ式に学べるものではなく、
おそらく 2 3 4 を行ったり来たりすることになるが、
概ねこのような順で学ぶといいのではないか。
コストを時間と捉えるなら、私はこの順を勧める。
0009デフォルトの名無しさん
2013/10/26(土) 22:53:59.43一種のサバン症候群だから日本語は苦手
0010デフォルトの名無しさん
2013/10/26(土) 23:07:12.23これはありがたい
0011デフォルトの名無しさん
2013/10/27(日) 01:47:21.690012デフォルトの名無しさん
2013/10/27(日) 03:31:14.010013デフォルトの名無しさん
2013/10/27(日) 05:04:16.170014デフォルトの名無しさん
2013/10/27(日) 05:05:09.54こんにちは、世界 = 文字列を出力して改行する "こんにちは、世界"
0015デフォルトの名無しさん
2013/10/27(日) 07:28:10.870016デフォルトの名無しさん
2013/10/27(日) 08:23:51.44へー(、)という演算子が定義できるのか
0017デフォルトの名無しさん
2013/10/27(日) 08:39:05.13コミュ障が多いけど
0018デフォルトの名無しさん
2013/10/27(日) 11:21:51.690019デフォルトの名無しさん
2013/10/27(日) 11:55:53.910020デフォルトの名無しさん
2013/10/27(日) 12:02:52.38関数マニュアル見ただけでかけるほどマニュアルはちゃんとかけてないし、
そもそも関数自体がそんな風にできてない
とすればどういう使い方を想定して関数があるのかをサンプル見て知るしかない
0021デフォルトの名無しさん
2013/10/27(日) 13:11:39.80これのこと？
ttp://www.sampou.org/haskell/tutorial-j/index.html
結構古いけどhaskell98って今のhaskellと違う部分とか無いのかな
0022デフォルトの名無しさん
2013/10/27(日) 13:49:51.27http://www.haskell.org/haskellwiki/Haskell_2010#Changes_since_Haskell_.2798
0023デフォルトの名無しさん
2013/10/27(日) 15:22:18.34でもやっぱりそのサイトの日本語分かりづらかったから本買おうかな
Lispから本格的にHaskellに入信しようか迷う
0024デフォルトの名無しさん
2013/10/28(月) 02:49:05.040025デフォルトの名無しさん
2013/10/28(月) 10:14:58.65qtもあるけど長いこと更新されてないと思う
0026デフォルトの名無しさん
2013/10/28(月) 14:33:22.790027デフォルトの名無しさん
2013/10/29(火) 02:23:58.080028デフォルトの名無しさん
2013/10/29(火) 07:39:36.24Xサーバでも、Xqartz、Xmingで動けばいちおうクロスプラットフォームになるのか。
0029デフォルトの名無しさん
2013/10/29(火) 07:54:11.48インストーラ作ってハードル下げればクロスプラットフォームになるんじゃ
0030デフォルトの名無しさん
2013/10/29(火) 10:16:35.03いや、Haskell+GLFWだね
0031デフォルトの名無しさん
2013/10/29(火) 15:02:10.030032デフォルトの名無しさん
2013/10/29(火) 15:25:23.97そういうのも綺麗にシャレオツに書ける言語ないかな。
0034デフォルトの名無しさん
2013/10/29(火) 17:47:43.200035デフォルトの名無しさん
2013/10/29(火) 17:51:23.930036デフォルトの名無しさん
2013/10/29(火) 21:06:32.890037デフォルトの名無しさん
2013/10/30(水) 00:49:38.580038デフォルトの名無しさん
2013/10/30(水) 00:50:18.810039デフォルトの名無しさん
2013/10/30(水) 01:29:12.39純粋関数だけでどうせプログラム組めないし
0040デフォルトの名無しさん
2013/10/30(水) 02:00:26.33一番成功している関数型言語がC言語というオチ
0041デフォルトの名無しさん
2013/10/30(水) 06:50:46.69プリプロセッサで頑張る話?
0042デフォルトの名無しさん
2013/10/30(水) 07:08:58.55Haskellが第一言語の俺達とは相容れない運命なのさ…
0043デフォルトの名無しさん
2013/10/30(水) 09:04:47.620044デフォルトの名無しさん
2013/10/30(水) 09:36:55.63別にプリプロセッサだけで頑張る必要ないだろ。
純粋性を保つようにコードを書けばいいんじゃね？
0045デフォルトの名無しさん
2013/10/30(水) 12:31:19.74あいや、Cで関数型と聞いて思い当たったのがプリプロセッサを純粋関数型言語として使うという話しかなかったので
Cの #define を駆使するとプリプロセッサだけで案外ちゃんと計算ができるんだけど、代入が表現できないので純粋関数型言語の作法で書かざるを得ないというネタ(思い出してみたらネタだったけど煽る意図ではなかった)
0046デフォルトの名無しさん
2013/10/30(水) 12:31:45.13保証がない
0047デフォルトの名無しさん
2013/10/30(水) 12:39:29.520048デフォルトの名無しさん
2013/10/30(水) 12:40:37.22本当はループ欲しいんじゃないの?
0049デフォルトの名無しさん
2013/10/30(水) 13:20:22.69unsafePerformIOだって保証ないじゃん
0050デフォルトの名無しさん
2013/10/30(水) 19:04:39.77無理に穴を見つけようとしないで、もっと気楽に素直になれ
0051デフォルトの名無しさん
2013/10/30(水) 19:29:28.28心の底から要らない。あっても使わない
0052デフォルトの名無しさん
2013/10/30(水) 19:50:42.76ループはいらんかもね。
俺は再帰よりもmapとかを多用するようになった。
0053デフォルトの名無しさん
2013/10/30(水) 20:12:40.70最初から完璧な最終的なコード書けるならいいけど
実験的なコード書いてるときはどうしてもゆるい書き方が欲しくなるのだよ
0054デフォルトの名無しさん
2013/10/30(水) 20:24:55.77戻り値として text モジュールの Data.Text.Internal.Text 型のリストを返します。
このリストの要素に対して text モジュールの Data.Text.unpack 関数を適用すると
String 型の値が返ってきます。
しかし、なぜ Data.Text.Internal.Text 型の値に
Data.Text.unpack 関数が使えるのでしょうか。
Data.Text.unpack :: Text -> String の第1引数の型は
Data.Text.Text であって、Data.Text.Internal.Text ではないにも関わらず、です。
0055デフォルトの名無しさん
2013/10/30(水) 20:30:34.85コンパイラーさんがいいと言ってるんだから、細けぇことはいいんだよ！
0056デフォルトの名無しさん
2013/10/30(水) 23:20:41.330058デフォルトの名無しさん
2013/10/30(水) 23:53:13.23名前空間が違うだけで、型は同じ。
0059デフォルトの名無しさん
2013/10/30(水) 23:54:53.51List->Listなら、再起でもスタック消費しない。
それ以外は基本、末尾再帰。
0060デフォルトの名無しさん
2013/10/31(木) 00:08:02.05http://hackage.haskell.org/package/text-0.11.3.1/docs/src/Data-Text.html
0061デフォルトの名無しさん
2013/10/31(木) 17:03:37.760062デフォルトの名無しさん
2013/10/31(木) 19:51:29.640063デフォルトの名無しさん
2013/10/31(木) 20:11:50.440064デフォルトの名無しさん
2013/10/31(木) 20:37:46.69こちらで
http://toro.2ch.net/test/read.cgi/tech/1383219359/
0065デフォルトの名無しさん
2013/10/31(木) 20:42:14.31006654
2013/11/01(金) 07:51:27.23>>60
「名前空間が違うだけで、型は同じ」 そういうことなんですね。
でも、どうしてわざわざ Internal の方の名前空間を使うのでしょうか。
"Internal" というモジュールは他のライブラリでもありますが、
基本的にはより低レベルの内部的な処理のためのものだと思います。
ライブラリを利用する側の者が使うのはあまり好ましいことではないような気がしますが、
Data.Text.Internal の説明には
Modules which extend the Text system may need to use this module.
とあるように、むしろ Data.Text ではなくこちらを使うよう促していますよね。
なぜなんでしょうか？
0067デフォルトの名無しさん
2013/11/01(金) 09:24:55.23それ以上は言語とは関係ないライブラリ固有の話題だからドキュメント調べろよ
0068デフォルトの名無しさん
2013/11/01(金) 09:47:45.58＞Modules which extend the Text system
ってライブラリを拡張する場合だから、ただの利用者じゃないでしょ。
0069デフォルトの名無しさん
2013/11/01(金) 10:16:27.59その上、その後ろに、こう書いてあるしな。
You should not use this module unless you are determined to monkey
with the internals, as the functions here do just about nothing to preserve
data invariants. You have been warned!
そもそも、>>54の前提がおかしい。
>xml-conduit モジュールの Text.XML.Cursor.content や attribute などは
>戻り値として text モジュールの Data.Text.Internal.Text 型のリストを返します。
ソースを見るとこうなってる。
http://hackage.haskell.org/package/xml-conduit-1.1.0.7/docs/src/Text-XML-Cursor.html#content
import qualified Data.Text as T
content :: Cursor -> [T.Text]
007054
2013/11/01(金) 12:52:36.75ghci の :t コマンドで型情報を調べたのですが、
どうも、現在どのモジュールを読み込んでいるのかによって
:t コマンドの結果が違うようです。
ghci を立ち上げた直後に :m + Text.XML.Cursor として
モジュールを読み込んだ状態だと、次のようになりました。
Prelude Text.XML.Cursor> :t content
content :: Cursor -> [Data.Text.Internal.Text]
Data.Text モジュールも一緒に読み込むと次のようになりました。
Prelude Text.XML.Cursor Data.Text> :t content
content :: Cursor -> [Text]
:l で読み込んだ自作のモジュール内に import Data.Text (Text) という記述があっても、
:t で型を調べるときは上記のように「何を :m で読み込んでいるか」によって結果が変わるみたいです。
私は ghci 上の Prelude Text.XML.Cursor> の状態で調べていたようです。
本当の型を調べるには :t は役立たず、ソースを読まなければならないということでしょうか。
環境
ghc 7.6.3
0071デフォルトの名無しさん
2013/11/01(金) 14:11:44.510072デフォルトの名無しさん
2013/11/01(金) 14:30:43.39牛丼屋に入って調理場に向かって”並・たまご”と言うか、
カウンターで注文取りにきた人に”牛丼並盛・たまご1つ”
と言うかの違い。
基本的には出てくるものは同じだが、掟破りの注文方法がずっと通用する
保証はどこにもない。
0073デフォルトの名無しさん
2013/11/01(金) 16:53:11.20007454
2013/11/01(金) 17:57:01.12今回の件で言えば、どれのことを「掟破り」と喩えているのでしょうか。
Data.Text.Internal.Text 型を使うのが掟破りで、
Data.Text.Text 型を使うのが通常の方法という意味でしょうか。
それだと、やはり ghci の :t では掟破りかどうかを判断できないということでしょうか。
それとも、型を調べるのにソースを参照するのが掟破りで、
ghci の :t を使うのが通常の方法ということでしょうか。
それだと今回のように正しい判断ができなくなります。
0075デフォルトの名無しさん
2013/11/01(金) 18:10:20.33型を調べる正しい方法はドキュメントやソースを読むことであって、
:t を使うのは調理場の中に入って自分でご飯をよそうようなことだと思うけど。
0076デフォルトの名無しさん
2013/11/01(金) 18:27:57.28内部実装はいつ変更されても文句言えない
0077デフォルトの名無しさん
2013/11/01(金) 18:38:30.23食べログで確認したとおりに二郎で注文したのに「うちはマシマシ禁止です」って
怒られたことがある
0078デフォルトの名無しさん
2013/11/01(金) 18:39:25.32・Data.Textは、Data.Text.Internalで定義されたTextという型を再エクスポートしている
・再エクスポートしても実体は一つ。同じ型
・textパッケージの作者から見ると、TextがInternalで定義されているというのは実装の詳細で、
普通の利用者にはData.Textからインポートして欲しいと思っている
・ghciから見ると、作者の意図など知ったこっちゃないので、:tでは
Textが実際に定義されているInternalモジュールを提示する
0079デフォルトの名無しさん
2013/11/01(金) 18:53:41.07型の定義とか、関数の型とか。
ドキュメントは古かったり間違ってたりするよね。ってのは偏見かなぁ。
0080デフォルトの名無しさん
2013/11/01(金) 18:54:58.270081デフォルトの名無しさん
2013/11/01(金) 19:01:34.11もうとっくに消えたかと思った。
C言語が流行ったときのパスカルみたいな存在だよねw
0082デフォルトの名無しさん
2013/11/01(金) 19:04:07.57008354
2013/11/01(金) 19:07:11.31たとえば Text.XML.Cursor モジュールのドキュメントの content :: Cursor -> [Text] の項を見ると、
Text のリンクは Data.Text.Text ではなく、Data.Text.Internal.Text へ飛びます。
それが本当は Data.Text.Text を指していることは、今回ソースを読んだ >>69 の指摘でわかりました。
やはり型を知るにはソースを読まないといけないのが現状だと今回の件で認識しました。
それとも、もしかしてドキュメントのリンクがこのようになっているのは私だけでしょうか。
たとえば、ライブラリ（ドキュメント）のインストール順序によってはリンクがおかしくなるとか・・・
0084デフォルトの名無しさん
2013/11/01(金) 19:34:26.81>Data.Text.Internal.Text 型を使うのが掟破りで、
>Data.Text.Text 型を使うのが通常の方法という意味でしょうか。
そういうこと。Text.XML.Cursor.contentも、そうしてる。
ghciは自分の知ってる型の中から合致するものを報告するだけ。
（xml-conduit モジュールの作者の意図とは無関係）
>>83
もしかして、Data.Text.Internal.TextとData.Text.Textが違うものだと
思ってる？
本体はData.Text.Internal.Textに定義してあって、Data.Text.Textは
そのリンクだと思えば良いよ。
でも、ライブラリ作者がユーザーに使ってもらいたいのはリンク(Data.Text.Text)の方。
ghciは空気読めないから、その作者の意図に反して本体を示すことがある。
haddocで自動生成されるドキュメントも同じこと。
0085デフォルトの名無しさん
2013/11/01(金) 19:39:14.03>やはり型を知るにはソースを読まないといけないのが現状だと今回の件で認識しました。
極論を言えば、そういう場合もあるけど、今回の場合は”.Internal.”をみて、ユーザが
作者の意図を察してあげるのがプログラマ社会のルールだと思う。
0086デフォルトの名無しさん
2013/11/01(金) 19:43:32.97haddockドキュメントの中でで、英語で書いてある部分は全部無視して型情報だけ見ればいい
そこは自動生成なので古くならない
008754
2013/11/01(金) 21:15:01.08> もしかして、Data.Text.Internal.TextとData.Text.Textが違うものだと
> 思ってる？
初めはそう思っていましたが、皆さんの指摘を受けて同じものだと知りました。
>>66 の時点で同じものだと知りましたが、ghci の :t を疑わなかったので、
同じ物のうちで TextとData.Text ではなく Data.Text.Internal の方を公開している
という勘違いをずっとしていました。
その勘違いも理解できました。
> 今回の場合は”.Internal.”をみて、ユーザが
> 作者の意図を察してあげるのがプログラマ社会のルールだと思う。
それなら仕方ありません。
私もそのように従うことにします。
みなさんアドバイスありがとうございました。
0088デフォルトの名無しさん
2013/11/01(金) 22:33:25.63モダンな大規模開発向け機能が欠落しているのかね？
モジュール化設計機能を備えた言語であれば、
モジュールの外部仕様(interface)と実現方法(implement)を
分離できるから、ツール類で実装向けデータ構造と
ユーザ提供向けデータ構造を正しく認識できるから、
>>87みたいな:tコマンドやhaddockでの誤認識は起こりえない
また、抽象データ型機能を備えた言語であれば、
内部の実装向けデータ構造をユーザから完全に隠蔽できるから、
Data.Text.Internalみたいな実装向けデータ構造が
外部から見えてしまうという根本の問題が生じ得ない
Haskellは関数型言語研究の最新の成果を反映した先端言語という
ふれこみであるけれど、(結局は数学者/研究者向けの言語だから、)
ソフトウェア工学において大規模開発では必須と認められている
これらの機構が完全に無視されてているように見える
結論として、Haskellは研究や試作といった用途には適しているのかも
しれないけど、大規模開発＆保守性を要求される産業界での
実用的な開発には不適格な言語ではないのかと考える
0089デフォルトの名無しさん
2013/11/01(金) 22:42:07.77日本語が変だったので、以下の段落を書き直す
>モジュール化設計機能を備えた言語であれば、
.... 中略 ....、
>>>87みたいな:tコマンドやhaddockでの誤認識は起こりえない
モジュール化設計機能を備えた言語であれば、
モジュールの外部仕様(interface)と実現方法(implement)を
分離できるから、ツール類でも実装向けデータ構造と
ユーザ提供向けデータ構造を正しく認識できるはず
(もしできないのであれば、ツールのバグか機能不十分と見なすべき)
結果として、>>87みたいな:tコマンドやhaddockでの誤認識は起こりえない
0090デフォルトの名無しさん
2013/11/01(金) 23:14:33.520091デフォルトの名無しさん
2013/11/01(金) 23:20:37.340092デフォルトの名無しさん
2013/11/01(金) 23:30:10.81見分けられないからモジュール性に優れてないってめちゃくちゃ言ってるな
単なるghcの不具合ってだけだろ
0093デフォルトの名無しさん
2013/11/01(金) 23:36:58.05>分離できるから、ツール類で実装向けデータ構造と
>ユーザ提供向けデータ構造を正しく認識できるから、
今回の例ではデータ構造は一つだからこれは当たらない
>また、抽象データ型機能を備えた言語であれば、
>内部の実装向けデータ構造をユーザから完全に隠蔽できるから、
もちろんHaskellでもこれはできる。でもtextパッケージはあえてやってない
一部の用途ではどうしても内部実装に踏み込みたいことがある
そういう場合に、実装を完全に隠蔽していたら、せいぜいソースをコピーして
パッチを当てるしか道がない
それよりは、「特殊用途向け」に.Internalモジュールを公開して、その代わり
これは内部実装だからマイナーバージョンアップで壊れるかもしれないよ、
気軽に使うなよ、と宣言しておくのがまだマシだという思想
0094デフォルトの名無しさん
2013/11/01(金) 23:41:17.020095デフォルトの名無しさん
2013/11/01(金) 23:41:53.15モジュール化と抽象データの概念がソフトウェア工学研究の成果として
認知されたのが1970年代後半から1980年代
この頃に設計された Modula, Mesa, Ada といった言語には、これらの機能が備わっている
オブジェクト指向の概念が登場したのは、その後になる
つまり、オブジェクト指向という言葉を持ち出さずとも論証できるから、
というのが第一の理由
また静的型付け関数型言語である Standard ML(SML) は
オブジェクト指向の機構を一切持たない古い設計であるが、
完全なモジュール化と抽象データの仕組みを備えているから、
>>88,89の問題はどのSML処理系を利用していても現実に起きたことがない
つまり、SMLでも問題が生じないのだからオブジェクト指向とHaskellの問題は無関係
これが、オブジェクト指向という言葉を持ち出さない第二の理由
0096デフォルトの名無しさん
2013/11/01(金) 23:43:10.97効率を考えないなら書き換え自体は別に難しくないだろ
関わる変数を全て引数にするだけだし
0097デフォルトの名無しさん
2013/11/01(金) 23:45:35.24>ソフトウェア工学において大規模開発では必須と認められている
>これらの機構が完全に無視されてているように見える
こういう明かな間違いを平気な顔で言うのは恥ずかしいから、
今後は入門書の一冊でも読んでから批判するのが良いと思う
0098デフォルトの名無しさん
2013/11/01(金) 23:45:57.88従来の構造化プログラミングと1980年代のsmalltalkからのアドバンテージがなかった
0099デフォルトの名無しさん
2013/11/02(土) 00:01:44.35どこにghcの不具合があるのか
ghcは正しくはどうするべきだったと思う？
0100デフォルトの名無しさん
2013/11/02(土) 00:08:16.38>今回の例ではデータ構造は一つだからこれは当たらない
>>93の後段では「一般用途向け(Data.Text.Text)」と
「特殊用途向け(Data.Text.Internal.Text)」という
二種類のデータ構造を提供していると書いてあるように読めるから、
矛盾していないかな？
>それよりは、「特殊用途向け」に.Internalモジュールを公開して、その代わり
>これは内部実装だからマイナーバージョンアップで壊れるかもしれないよ、
>気軽に使うなよ、と宣言しておくのがまだマシだという思想
こういったレイヤの異なる二種類のインターフェイスを提供するという考え方(思想)は、
決して間違いではないとは思う
ただし、SMLを含むモダンな言語のモジュール化機構では、
アプリケーション側で用途に応じて必要なモジュールだけをimportできる仕組みが、
言語仕様の一部として提供されている
結局、このレス(>>93)では、まともなモジュール化機構を持たないHaskellが
(形式的な理論ではなく)コード設計技法という小手先のテクニックで
モジュール化機能を模倣している、という説明にしかならない
これは、モジュール化機構を持たないJavaScriptが、コード設計技法と規約によって
モジュール化の基本である階層的名前空間を実現している実情と、よく似ている
そして、モジュール化機能がツールで支援できない点もHaskellと同様だ
0101デフォルトの名無しさん
2013/11/02(土) 00:09:53.81例外が出たときは書いた奴が悪い
GHCは何も悪くない
■ このスレッドは過去ログ倉庫に格納されています