Comments on: Erlang のパターンガード http://www.jmuk.org/diary/index.php/2007/05/16/1/ Thu, 22 Sep 2011 05:09:13 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: 向井 http://www.jmuk.org/diary/index.php/2007/05/16/1/comment-page-1/#comment-33 向井 Wed, 16 May 2007 15:01:29 +0000 #comment-33 なるほど。古い言語だからだろうな、とは思っていたのですが、並列論理言語の影響というのは考えていませんでした。確かに。 なるほど。古い言語だからだろうな、とは思っていたのですが、並列論理言語の影響というのは考えていませんでした。確かに。

]]> By: あろは http://www.jmuk.org/diary/index.php/2007/05/16/1/comment-page-1/#comment-32 あろは Wed, 16 May 2007 11:35:20 +0000 #comment-32 >> なんで、パターンガードにそんな制約を加えているんだろう これは Erlang に限らず，flat GHC を初めとした，「フラットな」committed-choice 型言語と呼ばれる族の一般的な特徴だと思います．Erlang はけっこう古い言語なので，案外そこらへんの言語の仕様の影響を受けているのでは無いかと． GHC のような並列論理型言語の場合，データフローに方向性が無いため，ガード部に任意のユーザ定義ルールを許すと，けっこう理論的な解析が面倒になり，全体的な並列度もかなり犠牲になると思います． 確かに微妙と言えば微妙過ぎる仕様ですが，当時は，並列計算というプログラミングパラダイム自体が黎明期だったので，何よりも単純性が重要視されたという経緯があったのではないか． >> なんで、パターンガードにそんな制約を加えているんだろう

これは Erlang に限らず，flat GHC を初めとした，「フラットな」committed-choice 型言語と呼ばれる族の一般的な特徴だと思います．Erlang はけっこう古い言語なので，案外そこらへんの言語の仕様の影響を受けているのでは無いかと．

GHC のような並列論理型言語の場合，データフローに方向性が無いため，ガード部に任意のユーザ定義ルールを許すと，けっこう理論的な解析が面倒になり，全体的な並列度もかなり犠牲になると思います．

確かに微妙と言えば微妙過ぎる仕様ですが，当時は，並列計算というプログラミングパラダイム自体が黎明期だったので，何よりも単純性が重要視されたという経緯があったのではないか．

]]>