Linux だったら，The Münster Curry Compiler から，ビルド済みのバイナリパッケージ curry-0.9.10-i686-linux-gnu.tar.gz とかをダウンロードしてきて，

$ tar xvf curry-0.9.10-i686-linux-gnu.tar.gz
$ cd curry-0.9.10-i686-linux-gnu
$ ./configure --prefix=/usr/local
$ su
# make install

とかするだけだった．なんか勝手にSICStus Prolog コンパイラ （商用） と Haskell コンパイラが必要なのかと思い込んでいた （さかい さんがあっさり試してたので気がついた） ．

ちなみに，コンパイラとインタプリタは，Zinc と同じ．cyc と cyi です．

これで Zinc では無理だった

ねんがんの ファンクショナル ロジック パーサ を ためせるぞ

Haskell のパーサコンビネータに，Prolog の全解探索能力 (findall) が加わったような感じみたいです．理論的には，どんだけ文法がコンフリクトしようが，全可能性を自動的に探索して全ての結果を返してくれるわけですから，こりゃ強力じゃないわけがないって感じですな （現実的には，枝刈りをがんばらないと使いものにはならないでしょうが）．まさしく最強のパーサライブラリでしょう．

とりあえず，Prolog とかで非常にありがちな，回文生成．

$ cat palindrome.curry
-- A simple example for the use of the functional logic parser combinators:
-- A parser for palindromes over the alphabet 'a' and 'b'

import Parser

a = terminal 'a'
b = terminal 'b'

pali = empty <|> a <|> b <|> a <*> pali <*> a <|> b <*> pali <*> b

main = findall (\[x1,x2,x3,x4,x5] -> pali [x1,x2,x3,x4,x5] =:= [])

$ cyc palindrome.curry
$ ./a.out
["aaaaa","aabaa","ababa","abbba","baaab","babab","bbabb","bbbbb"]

ここのサンプルコードに，コンパイルの際のエントリポイントとなる main 関数を付けただけですが，ちゃんと長さ 5 の全ての回文の組合せがパースされています (終端記号が 2 文字だけなので 2 の 5 乗通りの可能性がある気がするんですが，重複は自動的に削除されるんですかね ?)．

もちろん，インタプリタでも普通にイケます．まぁ，どのみちインタプリタであっても型推論とかしないといけない静的型付けの言語なので，律義にネイティブコンパイルまでしている感じです．単独実行可能なコードが生成されるわけではなく，ランタイムライブラリはインタプリタと共有されてるみたいですね．

$ cyi palindrome.curry
    _____ __ __
   / ___/ |  / _               Muenster Curry Compiler
  / /     | / | |              Version 0.9.10, Copyright (c) 1998-2006
 / /___  / /  | |
 \____/ /_/   |_|              Type :h for help

/usr/local/bin/cyc -c palindrome.curry -o palindrome.o
palindrome> findall (\[a, b, c] -> pali [a, b, c] =:= [])
["aaa","aba","bab","bbb"]
palindrome>

対話的に質問 （クエリ） を与えることができてよい感じです．

自然言語処理なんかで曖昧性のある文法をパースするときなんかは，おそらく関数型言語よりも圧倒的に強い感じがします．人工無能プログラミングなんかも楽なんじゃないですかね ?

いやー，カレーは素晴らしい ！

---

実は，GHC さえ動けば Windows でもコンパイルできるみたい．

$ which ghc                    
/cygdrive/c/ghc/ghc-6.6/bin/ghc
$ tar zxvf curry-0.9.10.tar.gz
$ cd curry-0.9.10
$ ./configure
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for gcc... gcc
checking for C compiler default output file name... /usr/bin/sed: invalid option -- o
Usage: /usr/bin/sed [OPTION]... {script-only-if-no-other-script} [input-file]...

  -n, --quiet, --silent
                 suppress automatic printing of pattern space
  -e script, --expression=script
                 add the script to the commands to be executed
  -f script-file, --file=script-file
                 add the contents of script-file to the commands to be executed
  -c  --nocr     turn off \r$ translation; must be first switch on command line
      --help     display this help and exit
  -V, --version  output version information and exit

If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret.  All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.

E-mail bug reports to: [e-mail] .
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
b.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

ありゃ…

$ which sed
/cygdrive/c/msys/1.0/bin/sed

う〜ん，MSYS の sed が駄目なのか ?

---

カレーと言いながらも，使うのは Zinc という．

まずは，こんにちは世界愛好家として．ザ・ワールド ！！ こんにちはこんにちは ！！

$ cat hello.curry
main = interact $ const "Hello, World!\n"
$ cyc hello.curry
$ ./a.out
Hello, World!

参考 : 諸君　私はHaskellが好きだ
2006-01-24 [Haskell] 単純なスクリプト用ラッパー

(via ネタばらし)

カレーは，スクリプト言語としても非常に便利だということが判明．打倒 SED ！ AWK ！！

社会不適合者なので，意地でも Haskell は使いません ！ （ちなみに，かなり今酔ってます）

でも，Persec は使いたいよね．という複雑な思春期の心境．
Persec の無い Haskell なんて，カフェインの入ってないコーヒーみたいなもんだ （言い過ぎ）

とか思ったら．カレーには，Functional Logic Perser という最強っぽい謎のパーサライブラリが付いてるらしい．

ふつーのパーサコンビネータ （高階関数で柔軟に無限先読み再帰下降パーサを組み立てるようなライブラリを，通はこういう風に言うらしい．あと，オイラは未だにモナドってなんのことだかさっぱりわかってないんだけど,shelarcy 先生の連載をイイカゲンに読んでいる限り，なにやら高階関数使って情報隠蔽したり，関数合成でフロー制御したりといった，一連の手法にいっこいっこ名前を付けて整理したのが，例えば I/O モナドとか，State モナドみたいなやつに相当するらしい．I/O パタンとか，State パタンとかいうと，まんまデザインパタンみたいね．これも mao 先生の受け売りだけど，一番オイラ的にはしっくりきた説明だと思う．全然デザパタとか知らないけど．下手に 〜型プログラミングとか，〜的な感じで〜 みたいな俺俺説明よりは，名前が付いているのは便利だと思う．モナドとか圏論とか言うとモノモノしすぎるから，「これは Haskell における高階関数を使った State パタンねー」 みたいに言えば良いのではなかろうか．あとは，結城浩氏に本書いてもらえば完璧） みたいなのはもちろん．

例えば，いかにも Prolog っぽいけど，任意の長さの回文を自動生成したりとかも，こんな感じでできるらしい．

Examples for functional logic parsers : palindrome.curry

---------------------------------------------------------------------------
-- A simple example for the use of the functional logic parser combinators:
--
-- A parser for palindromes over the alphabet 'a' and 'b'

import Parser

a = terminal 'a'
b = terminal 'b'

pali = empty <|> a <|> b <|> a<*>pali<*>a <|> b<*>pali<*>b

{-
Examples:

Check correctness of a sentence:

pali "abaaba" =:= []


Generate palindromes:

pali [x,y,z] =:= []


Generate list of all palindromes of length 5:
-}

pali5 = findall (\[x1,x2,x3,x4,x5] -> pali [x1,x2,x3,x4,x5] =:= [])

論理型言語の自動探索機構と findall という高階述語がポイントね．一階述語論理に基礎を置く Prolog だと言語の枠を越えた黒魔術だけど，curry だと合法なのかな ? curry とかの基礎理論がよくわかってないけど．内部的には副作用使ってるはず (Prolog とかだと，assert (節を追加) とか asserta （節を一番前に追加） retract （節を除去） とかを内部的には使っていたはず) だけど，関数論理型言語では，世界 (環境) 渡しスタイルというか，なんというか，複数の計算の場 （ET 言語でいうところの，ワールド機構） を操って結果を収集する 多重世界プログラミングみたいなことを，モナドの枠組でちゃんと表現できるのかもしれない （よくわからん）

しっかし，上記のコードは，Zinc だとコンパイルできなかった… ライブラリが無いっぽい．残念．

curry はもうちょいライブラリとドキュメントがあれば非常に素晴らしいような気がするのに．おしい．
mercury は，いつになったら GCC に公式採用されるのだろうか．関数論理型言語の未来は灰色．

あー，頭痛ぇー．ちょいと飲みすぎたな．焼酎だから，二日酔いはしないと思うけど．

---

curry を apt-cache してみたら．

# apt-cache search curry
zinc-compiler - Compiler of Zinc, a functional logic programming language
gmp-ecm - Factor integers using the Elliptic Curve Method
libsub-exporter-perl - A sophisticated exporter for custom-built routines

どうやら，zinc-compiler というのは，型クラスを備えた，アドバンスドなカレー言語コンパイラの拡張版みたいです．

ZINC PROJECT

About the Zinc Project

Zinc is a research project around Curry, a functional logic programming language, at the University of Oviedo (Spain).

Zinc は，カレーにまつわる，スペインの Oviedo 大学における関数論理型言語の研究プロジェクトです．

Zinc コンパイラの他にも，Java で書かれたポータブルなインタプリタ Currin や，(スペイン語ですが…) 関数論理型言語と型クラスについて，Haskell による Curry コンパイラの構成法について，そして Zinc コンパイラの開発者ガイドとユーザマニュアルなどについてのドキュメンテーションプロジェクト PFC-es というサブプロジェクトを含みます．

It is composed of several subprojects:

* Zinc Compiler
* PFC Doc-es
* Currin

Zinc Compiler

Zinc コンパイラの中心的な目的は，型クラスのような，カレー言語の拡張機能を加えた実験的なコンパイラを開発することです．

The main purpose of the Zinc Compiler is to develop an experimental Curry compiler which features some extensions to the language, such as type classes.

Zinc コンパイラは，Wolfgang Lux による良くテストされた Münster Curry Compiler (MCC) に基づいています．もしカレーコンパイラを探しているならば，オリジナルの MCC か PAKCS を使ってください．

The foundation of the Zinc Compiler is the well-tested Münster Curry Compiler (MCC) by Wolfgang Lux. If you are searching for a Curry compiler, use the original MCC or PAKCS.

しっかしなぁ，curry のコンパイルには Haskell コンパイラの GHC が，PAKCS のソースからのコンパイルとインストールには，商用の Prolog コンパイラ SICStus-Prolog と GHC が両方要るらしい ！！ なんてゴージャスな処理系だ．大富豪プログラミング．

とりあえず，Zinc をインストールしてみよう… と思ったら．

# apt-get install zinc-compiler
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています... 完了
インストールすることができないパッケージがありました。おそらく、あり得
ない状況を要求したか、(不安定版ディストリビューションを使用しているの
であれば) 必要なパッケージがまだ作成されていなかったり Incoming から移
動されていないことが考えられます。

単純な操作を行っただけなので、このパッケージは単にインストールできない
可能性が高いです。そのため、このパッケージへのバグレポートを送ってくだ
さい。
以下の情報がこの問題を解決するために役立つかもしれません:

以下のパッケージには満たせない依存関係があります:
zinc-compiler: 依存: libgmp3 しかし、インストールされようとしていません
E: 壊れたパッケージ

libgmp3 も指定してやれば OK なんだけど，何故か ghc がアンインストールされるというよくわからない結果に．

apt-get install zinc-compiler libgmp3
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています... 完了
提案パッケージ:
zinc-compiler-doc-es
以下のパッケージは「削除」されます:
ghc6 haskell-utils libgmp3-dev libgmp3c2 libgmpxx4
以下のパッケージが新たにインストールされます:
libgmp3 zinc-compiler
アップグレード: 0 個、新規インストール: 2 個、削除: 5 個、保留: 0 個。
1965kB のアーカイブを取得する必要があります。
展開後に 103MB のディスク容量が解放されます。
続行しますか [Y/n]?

新しい方の gmp が，まるごと古い方に置換されるのか ? うーん．

とりあえず，どーんとインストールしてみた．さようなら Haskell．こんにちは Zinc．

しっかし，Zinc のインタプリタとコンパイラが，cyi と cyc ってのはわかりにくすぎるような．

$ cyi

ZZZZZ  IIIII  N   N   CCCC    Zinc interactive version 1.0.2
   Z     I    NN  N  C          (Copyright (c) 2003-2004, Diego Berrueta)
  Z      I    N N N  C
 Z       I    N  NN  C        Derived from Muenster Curry Compiler
ZZZZZ  IIIII  N   N   CCCC      (Copyright (c) 2002-2003, Wolfgang Lux)

Type :h for help, :q to exit

$ man cyc
cyc(1)                    BSD General Commands Manual                   cyc(1)

NAME
     cyc - A native code compiler for Zinc.

SYNOPSIS
     cyc [option ...] file ...

DESCRIPTION
     cyc is a native code compiler for the multi-paradigm declarative language
     Zinc, which is an extended version of Curry featuring type classes.  Nor-
     mally, it performs compilation, assembly, and linking. The ``overall
     options'' allow stopping this process at an intermediate stage. For exam-
     ple, the -c option says not to run the linker. The output then consists
     of object files output by the assembler.

(cyc は，カレーに型クラスの機能を加えた，拡張版の宣言的マルチパラダイム言語 Zinc のネイティブコンパイラです．通常は，コンパイル，アセンブル，リンクまで行われますが，上書きオプションにより途中のステージで処理を止めることもできます．例えば，-c オプションはリンクを行わないように指示します．オブジェクトファイルによって構成されるアウトプットはアセンブラによるものです)

とりあえず，curry のプログラムは，完全に互換性があるらしい．

というわけで，ここに大量にある curry のサンプルプログラムの中から，やはり伝統の quicksort を．

かなりハマッたのは，curry では goal = ... という部分を，main = ... に直さないと，

$ cyc quicksort.curry
/tmp/cc0attba.o: In function `main':
cyc2520.c:(.text+0x30): undefined reference to `curry_run'
collect2: ld returned 1 exit status

とか出て，コンパイルが通らないこと．コンパイル自体は，gcc とほとんど同じ要領で．-S とか -o とか普通に使えます．

$ cat quicksort.curry
-- quicksort using higher-order functions:

qsort :: [Int] -> [Int]
qsort []     = []
qsort (x:l)  = qsort (filter (=x) l)

main = qsort [2,3,1,0]

$ cyc quicksort.curry
$ ./a.out
[0,1,2,3]

$ cyi quicksort.curry

ZZZZZ  IIIII  N   N   CCCC    Zinc interactive version 1.0.2
   Z     I    NN  N  C          (Copyright (c) 2003-2004, Diego Berrueta)
  Z      I    N N N  C
 Z       I    N  NN  C        Derived from Muenster Curry Compiler
ZZZZZ  IIIII  N   N   CCCC      (Copyright (c) 2002-2003, Wolfgang Lux)

Type :h for help, :q to exit

/usr/bin/cyc -c quicksort.curry -o quicksort.o
main> qsort [3,5,2,9,7,1,8,6,4]
[1,2,3,4,5,6,7,8,9]

何気に，普通にネイティブコンパイラ．Debian APT で入る，唯一の関数論理型言語の処理系は大当たりのような．ベネ ！！ （良し）

あと，コンパイルする代わりに，インタプリタに通すと，そのまま対話モードになるってのも素晴らしい．時代はカレーです．なんせ，ハスケルのプログラムもほとんどがそのまま通るらしいし (笑) Haskell ++ ，みたいなノリで ．みんなもっとカレー (Zinc) を使うべきだと思います．真のマルチパラダイム言語万歳 ！！

ハスケルの一族 (関数型) とカレーなる一族 (論理型) は，もともと一つの王家 （関数論理型言語ククレゲーデルとハスケルカレー) だったのだ．地上に降りたとき，二つに分かれたがね．君の一族はそんなことも忘れてしまったのかね !?

---

メシ食った後，眠過ぎてやる気が起きなかったので The Mercury Project Comparing Mercury and Haskell をテキトーに翻訳．

Comparing Mercury with Haskell

Mercury は関数型言語と多くの共通点を持っている．ML や Haskell のような言語に慣れ親しんでいる関数畑のプログラマは，それらの言語と比べて， Mercury はどうなのか ? とたびたび尋ねてくる．

Mercury has a lot in common with functional languages. Functional programmers who are familiar with languages such as ML and Haskell often ask how Mercury compares with those languages.

このウェブページには，Mercury と Haskell 98 の間の型システムの比較を載せている．Haskell 98 と比較した結果，Mercury の型システムは ML のそれよりも，Haskell のに近い (Haskell 98 は，Haskell のよく知られた亜種の一つであり，おそらく最も良く文書化されている)．もちろん，Hugs と ghc では，Haskell 98 に対して多くの拡張が加えられているので，その意味では言えば，これは 「フェアな」比較とは言えないだろうが．

This web page contains a comparison between the type systems of Mercury and Haskell 98. The reason for comparing with Haskell 98 is that Mercury's type system is more similar to that of Haskell than that of ML, and Haskell 98 is probably the best documented / most well-known variant of Haskell. Of course Hugs and ghc have a lot of extensions of Haskell 98, so in some sense this is not a "fair" comparison.

本文章では，型システムの違いをリストするだけではなく，型システムと密接な関係があるモジュールシステムにおける違いについても述べる．

As well as listing the differences in type systems, we also describe some of the differences in module systems, since there are some close interactions between the type systems and the module systems.

その他にも，Mercuy と Haskell 98 の間には

• 構文


• 通常の記述における意味論の与え方 (述語論理 vs λ計算)


• 操作的意味論 (遅延評価，すなわち評価の順番)


• 例外の取り扱い


• I/O (入出力) の取り扱い


• 標準ライブラリ


• そしてもちろん，論理プログラミングのサポート

などを含む，多くの違いがある

There are many other areas in which Mercury and Haskell 98 differ, including

* syntax,
* the way in which the semantics is normally described (predicate calculus versus lambda calculus),
* operational semantics (laziness / order of evaluation),
* exception handling,
* treatment of I/O,
* standard libraries,
* and of course support for logic programming,

しかし，全ての差異について，いっこいっこ比較することは行っていない．

but we don't yet have point-by-point description of all of those differences.

Mercury と Haskell 98 の型システムは，それぞれが以下のような特徴を持っているという点で近い．

The type systems of Mercury and Haskell 98 are similar in that they both have the following features:

• フィールド名をサポートする，区別された共用体 (d.u.) 型


* discriminated union (d.u.) types, with support for named fields


• 型の同義名


* type synonyms


• 高階関数型 (と，λ式)


* higher-order function types (and lambda expressions)


• タプル型


* tuple types


• パラメトリックポリモーフィズム (パラメタ付き多相)




• 多相 d.u. 型


• 多相型の同義名


• 多相関数


• 多相再帰



* parametric polymorphism:
o polymorphic d.u. types
o polymorphic type synonyms
o polymorphic functions
o polymorphic recursion


• 型クラス


* type classes


• 関数従属


※ 筆者注 : k.inaba 先生の資料によると型クラスを含む高度な型システムにおける型推論の際，曖昧性を減らすためにプログラマが推論の方向を明示的に指定できたりすることらしい．Haskell 98 には含まれていないっぽいけど… ?

* functional dependencies


• 型推論


* type inference


• 似たような基本型を備えている


* a similar set of basic types

そして以下のような点で違いがある．

They differ in the following ways:

• (明らかに) 異なった構文


しかし，特に



• Haskell 98 では，関数や変数 (小文字で始まる)と，構築子 (大文字で始まる) が，字句的に区別されている．一方 Mercury では，関数/構築子 (小文字で始まる) と，変数 (大文字で始まる) が区別されている．


* Different syntax (obviously).
But in particular:
o Haskell 98 lexically distinguishes constructors (uppercase initial letter) from functions/variables (lowercase initial letter) whereas Mercury distinguishes variables (uppercase initial letter) from functions/constructors (lowercase initial letter).


• Haskell 98 は，ネストした関数定義が可能であるが，Mercury ではできない．Mercury では，高階型変数とλ式による初期化が使えるものの，変数は常に単相型であり，λ式による関数定義では再帰的定義が使えない．


o Haskell 98 permits nested function definitions, Mercury doesn't. In Mercury you can use variables with higher-order type and initialize them with lambda expressions, of course, but variables are always monorphically typed and functions defined using lambda expressions can't be recursive.



• Haskell 98 は，変数は明示的に多相形であることを宣言しなければ，単相型になるという意味での，あまり知られていない単相性制限を持っている．Mercury の変数は常に単相型であるが，しかしそれは変数と関数の間の字句的な区別のためであるため，Haskell の単相性制限とは混同すべきではない．


* Haskell 98 has the infamous monomorphism restriction which means that variables are monomorphic unless you give an explicit polymorphic type declaration for them. In Mercury variables are always monomorphic, but because of the lexical distinction between variables and functions, that doesn't seem to lead to the same confusion that the Haskell monomorphism restriction causes.


• Mercury は，モジュールからエクスポートされる全ての関数の型を宣言する必要がある．Haskell 98 は，少なくとも理論上は (現実的には，現在の Haskell の実装は，相互に再帰的なモジュール (あるいは，より悪い場合) における効率性のために明示的な型宣言を要求する) 必要無い．


* Mercury requires type declarations for all functions exported from a module, Haskell 98 doesn't, at least in theory (in practice, current Haskell implementations effectively require explicit type declarations [or worse] in the case of mutually recursive modules).



• 多相再帰のために，Haskell 98 は明示的な型宣言を要求する．一方 Mercury は，型推論処理の停止性を満足させるために，ユーザが調節可能な繰り返しの回数制限を使うことにより，型推論による多相再帰を許している．


* For polymorphic recursion, Haskell 98 requires an explicit type declaration, whereas Mercury allows polymorphic recursion with type inference, using a user-tunable iteration limit to ensure termination of the type inference process.


• Haskell 98 は，メソッドのデフォルト実装定義のために型クラスを許しているが，Mercury は違う．


* Haskell 98 allows type classes to define default implementations for methods, whereas Mercury doesn't.


• Haskell 98 は型クラスのインスタンスが未定義のメソッドを残すことを許しており，もしそのようなメソッドが呼び出された場合には実行時エラーとなる．一方，Mercury は未定義のメソッドはコンパイル時にエラーとして扱い，ユーザが，もしそのような挙動が望みならば，メソッド呼び出しがエラーとなるよう明示的に定義するように要求する．


* Haskell 98 allows type class instances to leave some methods undefined, in which case calls to such methods will be run-time errors, whereas Mercury treats undefined methods as a compile time error and requires users to explicitly define methods to call error if that is what they want.


• Haskell 98 は構築子のクラスをサポートするが，Mercury はしない．


* Haskell 98 supports constructor classes, Mercury doesn't.


• Haskell 98 の標準ライブラリは型クラスをフル活用するが， (主に歴史的な理由により) Mercury はしない．


* Haskell 98's standard library makes extensive use of type classes, Mercury's doesn't (mainly for historical reasons).


• Mercury は多引数の型クラスを許す (ただし，インスタンス宣言の形式にいくつか制限があるので，当初思われていたほど便利ではない)．


* Mercury allows multi-parameter type classes (however, there are some restrictions on the forms of instance declarations, so this may not be quite as useful as it might first appear).


• Mercury は存在型関数と，存在量化されたデータ型をサポートしているが，Haskell 98 はしてない (Hugs, ghc，そしてその他の Haskell 実装は，存在量化されたデータ型をサポートしているものの，存在型関数はサポートしていない)．


* Mercury supports existentially typed functions, and existentially typed data types, whereas Haskell 98 doesn't (Hugs, ghc and other Haskell implementations support existentially typed data types, but not existentially typed functions).


• Mercury は 「アドホック」オーバローディング (同名のクラスメソッドや関数の複数の構築子が存在でき，コンパイラは型に基づき，それぞれがどの関数を指しているのかを決定する) をサポートするが，Haskell 98 はしない (もちろん，あなたがあまりにもアドホックオーバローディングを多用すると，型チェッカが解決できない曖昧性の原因になる．もしそのような曖昧性が生じた場合には，型推論に頼るのではなく，曖昧性を解決するために明示的に型宣言を使用する必要がある)．


* Mercury supports "ad-hoc" overloading (there can be more than one constructor, function or class method with the same name, and the compiler will determine which one each occurence of that name refers to based on the types), Haskell 98 doesn't. (Of course if you make significant use of ad-hoc overloading, this can lead to ambiguities that type checker can't resolve; if such ambiguities occur, you need to use explicit type declarations to resolve them, rather than relying on type inference.)


• Haskell 98 において，関数は常に単引数のみを取る．複数の引数は，カリー化，あるいはタプルを使って扱われる．Mercury では，関数は複数の引数を取ることができ，そのような関数は，タプルを取る関数や，関数を返す関数とは区別された型を持つ (Haskell のアプローチは，より優美なソースコードを導く．Mercury のアプローチはより単純であり，よりパフォーマンスが期待できるモデルである)．


* In Haskell 98, functions always take a single argument; multiple arguments are handled using currying or tuples. In Mercury, functions can take multiple arguments, and such functions have a type distinct from functions taking tuples or functions returning functions. (Haskell's approach leads to more elegant source code; Mercury's approach has a simpler and more predictable performance model.)


• Haskell 98 の意味論では，それぞれの型は「ボトム」という要素を遅延評価を扱うために特別に持つ．Mercury では，宣言的/表示的意味論ではなく，操作的意味論の一部として遅延評価を扱うので，それぞれの型ごとに「ボトム」要素を余分に持つ必要は無い (最初のおおまかな概算としては，Mercury は正格評価で，遅延評価では無いといえる．しかしそれは，型システムではなく，操作的意味論における差異なのである．(ここでは，最初の概算は全てではない，というメモを除いて，我々は細部までは至らないが)．


* The semantics of Haskell 98 say that each type has "bottom" as an extra element, to handle laziness. In Mercury, laziness is treated as part of the operational semantics rather than the declarative/denotational semantics, so you don't get the extra "bottom" element in each type. (To a first approximation, Mercury is eager, not lazy. But, since that's a difference in the operational semantics, rather than in the type system, we won't go into the details here, except to note that the first approximation is not the full story.)


• Haskell 98 は，区別された共用体形と，遅延性と表現の点で異なる data と newtype を導入するために，2 つの構築子を持つ．それに対して，Mercury は :- 型，ただ一つである．Mercury は遅延構築子をサポートしないので，遅延性の区別は不要であり，Mercury における newtype の効果の表現は，自動的に全ての型について一つの構築子と一つの引数となる．


* Haskell 98 has two constructs for introducing discriminated union types, data and newtype, which differ in laziness and representation, whereas Mercury uses just one, :- type; Mercury doesn't support lazy constructors, so the laziness distinction is not applicable, and in Mercury the representation effect of newtype is automatic for any type with one constructor and one argument.


• Mercury はネストしたモジュールをサポートしているが，Haskell 98 はしていない．そのため，Mercury においては，それを含むモジュール全体 (最も外側) では無く，サブモジュールにおいてのみその定義が可視的になる抽象型を持つことができる．


* Mercury supports nested modules, Haskell 98 doesn't. So in Mercury you can have abstract types whose definition is only visible in a sub-module, rather than in the whole of the (outermost) module that contains them.


• Mercury のモジュールシステムは，インスタンスを公開 (エクスポート) あるいはローカル (プライベート) に宣言できる．一方，Haskell のインスタンス宣言は常にエクスポートされる．


* Mercury's module system allows instance declarations to be public (exported) or local (private), whereas in Haskell instance declarations are always exported.


• Mercury は述語だけではなく関数も持つ (述語型は bool を返す関数とは区別されている)．これは，存在型述語，型クラスのメソッドとしての述語，述語λ式，そして高階述語型のサポートを含む．


* Mercury has predicates as well as functions (predicate types are distinct from functions returning bool). This includes supporting existentially typed predicates, predicates as type class methods, predicate lambda expressions, and higher-order predicate types.


• Mercuyr は，オプショナルに動的型付けを提供するが，Haskell 98 はしない (Hugs/ghc はする．しかしながら，それらの実装のアプローチは，ユーザが明示的に型付けできるインスタンスを宣言しなければならない上に，それらは信頼できないコードを生み出すという問題を含むキャストを，検査せずに使用するため，少々厄介である)



• Mercury supports optional dynamic typing, Haskell 98 doesn't. (Hugs/ghc do. However, their approach of implementing this is a bit cumbersome, since the user has to explictly declare instances of Typeable, and its use of an unchecked cast would be problematic in the presence of untrusted code.)




• 同値判定，比較，自動生成されるクラス，そして RTTI の扱いが，2 つの言語において大幅に違う．Haskell 98 は組み込みの型クラス Eq, Ord, Enum, Bounded, Read, そして Show を持ち，プログラマが(すなわち，derivind Eq と型宣言のところに)記述すれば，それらを自動生成することができる．Mercury においては，同値判定は言語の構築子の一つであり，Haskell の == のようなクラスメソッドではない．Mercury はユーザ定義の同値判定を許すものの，その (言語に組み込みの) 同値の表記の意味論自体が変わるため，Mercury におけるそれは，Haskell の == のふるまいと比べて，非常に異なった影響を与える．Mercury の RTTI システムは，実行時に，任意の型の構築と破壊を許し，比較と (デ)シリアライズ (compare, read, そして write) は，これを利用して実装されている．


* The treatment of equality, comparison, automatically derived classes, and RTTI differs considerably between the two languages. Haskell 98 has built-in type classes Eq, Ord, Enum, Bounded, Read, and Show, and allows instances for these to be automatically derived, if the programmer writes e.g. deriving Eq on the type declaration. In Mercury, equality is a language construct, not a class method like == in Haskell. Mercury allows user-defined equality, but because this alters the semantic notion of equality, it has very different effects in Mercury than defining == does in Haskell. Mercury's RTTI system allows constructing and deconstructing arbitrary types at runtime, and comparison and (de)serialization (compare, read, and write) are implemented using this.


• Mercury の標準ライブラリは参照透明なインタフェースを破壊的更新可能な変数に対して提供し (ストアモジュール --- 存在型と一意型を使う)，それは 非 I/O コードにおいて使用できる． Haskell 98 は，おそらく型システムの拡張が必要になるため，提供していない (Hugs/ghc は，存在型と一意型ではなく，明示的な全称量化とモナドを使った高階関数により，そのようなインタフェースを提供できる．その他の Haskell 実装についても，おそらく同様に可能であろう)．


* Mercury's standard library provides a referentially transparent interface to mutable variables (the store module -- using existential types and unique modes), that is usable from non-I/O code; Haskell 98's doesn't, probably because it would require extensions to the Haskell 98 type system. (Hugs/ghc do provide such an interface, using higher-order functions with explicit universal quantification, and monads, rather than existential types and unique modes. Other Haskell implementations may do so too.)

Mercury のモードシステムに関連する違いが，そのほかにもいくつかある．他の言語では型システムの一部になっているようなものが，Mercury ではモードシステムによって扱われる．特に，

Some other differences are related to Mercury's mode system. Some things which in other languages are part of the type system are in Mercury handled by the mode system. In particular,


• Mercury のモードシステムは，部分型を提供する．例えば，可能な型構築子の部分集合のみを受け付ける，区別された共用体を引数にとるような関数を宣言することが，モードシステムによって容易になる．


* Mercury's mode system provides support for subtypes. For example, you can declare that a function whose argument is a discriminated union type accepts only a subset of the possible constructors for that type, and the mode system will enforce this.


• Mercury のモードシステムは，線形論理や一意型のような，一意性のサポートを提供する (しかしながら，今のところ明白な制限がある．特に，ユニークモードはトップレベルの項についてしか使用できない)．


* Mercury's mode system provides support for uniqueness, similar to linear types or unique types. (However, currently there are some significant limitations with this, in particular unique modes can only be used at the top level of a term.)

---

google : マーキュリー 約 2,210,000 件

(google に頼らなければ生きていけない，ヒヨワなインターネット世代 ！！)

マーキュリーというのは，母親は医者で日本画家である父親とは離別している IQ300の頭脳を持ち全国模試で常に順位一桁級の優等生，水野亜美が…

とかいう小ネタはどうでも良い．

(妹が「なかよし」愛読者でした管理人)

あと，Queen のボーカルでも，株式会社ミクシィの前身でもないです．

The Mercury Project Introduction

What is Mercury?

Logic programming languages have been around for more than twenty years. Despite the expected advantages of a very high level programming language based upon well developed theories of logic over conventional programming languages (such as C, C++, Pascal and Ada) they have not had significant impact on the computer industry.

Mercury is a new logic/functional programming language, which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features. Its highly optimized execution algorithm delivers efficiency far in excess of existing logic programming systems, and close to conventional programming systems. Mercury addresses the problems of large-scale program development, allowing modularity, separate compilation, and numerous optimization/time trade-offs.

(Mercuty とは何か ?

論理プログラミング言語は 20 年以上にも渡る歴史を持っている．ただし，高度に発達した論理学の理論に基づき，(C/C++/Ada/Pascal のような) 古典的な言語よりも，多くの利点を持つ超高水準のプログラミング言語であると期待されながらも，コンピュータ産業にはほとんど影響を与えることが無かった．

Mercury は，明確さと表現力を兼ね備え，先進的な静的解析とエラー検出機能を持つ，新しい関数論理型プログラミング言語です．既存の論理プログラミングシステムを超え，古典的なプログラミング言語に近い処理効率を生み出す，強力な実行アルゴリズムの最適化を行います．Mercury は，大規模プログラム開発における諸問題に対して，モジュール性，分割コンパイル，そして数々の最適化とコンパイル時間のトレードオフによって対応します)

とのこと．なかなか気合が入ってる感じです．

関連するプロジェクトとしては，以下のようなものがあるようです．

The Mercury Project Related Projects

Goedel is a logic programming language, with a strong type system, module system, and support for infinite precision numerical calculation and meta-programming facilities.

(Goedel は，モジュールシステムを備え，メタプログラミング機能と無限精度算術計算をサポートする，強く型付けされる論理型言語です)

* Goedel

Sisal is a high-performance portable parallel functional programming language.

(Sisal は，高性能でポータブルな並列関数型言語です)

* Sisal

Clean is a general purpose, higher order, pure and lazy functional programming language. It uses uniqueness types which are similar to Mercury's unique modes, and allows programmers to build distributed systems.

(Clean は，汎用高階純粋遅延関数型言語です．Mercury のユニークモードと似た，一意型を使用し，分散システムを構築することができます)

* Clean

Mercury の注目すべき点は，やっぱり GCC のフロントエンドがある，ってことですかね．いろいろ微妙な感じではあるものの．

結局のところ，企業がサポートしない言語は，GCC に組み込まれない限り，本物とは認められないと思うのですよ (GCC の品質については，ここでは議論しないけど)．オープンソースの世界のコンパイラ = GCC だもん．

まぁ，あんまり The Shakespeare Programming Language とかは使う気になれないから，GCC のフロントエンドがありゃ良い，ってわけでも無いんだけど．

あと，リフレクションとか相当の，リッチな動的言語機能を備えている言語 (最近の言語は全て) は，巨大なランタイムがリンクされてしまうことが避けられないので，GCC でコンパイルできても全然うれしくないという問題もある．

だったら，.NET とかみたいに，最初から洗練された VM の方が良いよね，GCC なんてダサいよね，ネイティブコンパイラなんて今日日流行らないよね，CLR がネイティブの Windows Vista 最強 ！！！ という話に．Linux とか GCC みたいな，オープンソースのガラクタどもなんてもう古い ！！

やっぱり，C/C++ と，その専用実行環境 x86 は死滅すべき老害という，いつもの結論に… 現在の計算機には夢が無いんだよ，夢が．こんな閉塞した世界に誰がした ！ (中二病発動)

---