##Charity ってなんか偽善的な名前ですね
#構文はすごくかわいいと思うけど
#Windows no
#Windows の GHCI で UTF8 を putStr すると文字化けするのはしょうがないか。
#UTF8 を表示する人はどうしてるの？
#Linux の UTF8 のコンソールかなんかでやってるですか？
#utf8-string つかってます
##それで import qualified System.IO.UTF8 as U とかやってる
#WindowsのコンソールにUTF8表示すると化けません？
#それは最近 Windows を触ってないから知らないです。。。
#でも最近の ghci (ていうか haskeline) は UTF8 通さないような
#それでも ghc-6.12 なら,
#なんとかなるらしいですね
#utf8-string を Windows GHC に入れたですが UTF8文字列を putStr しても読めなくて悲しい。出力をファイルに向けてそれを notepad で読むしかないか。
#notepadってUTF8読めるの？
#読める（はず）。「名前を付けて保存」の文字コードに UTF8 が選べるです。
#「開く」に文字コードがあった
#「開く」にも
#あ、みんな Emacs から使ってるのか。
#もしくは leksah
#leksah知りませんでした。試してみます。
#MacOSX版のインストーラがあるのを reddit/haskell で知ったので、さっそくインストールしたけど、すぐに死ぬ : Leksah (MacOSX 版)
#ghc が /opt/Gentoo/usr/bin などという変態な場所にあるからかなあ... (PATH には入れているのだが、アプリケーションが参照できないかも)
##だが日本人には重要なトリックだな (GHC 6.12.x が安定するまで)
#この手はいろいろBad Knowhow がありそう。failとかerrorへの文字列に日本語を渡したいとか。
#error $ Codec.Binary.UTF8.String.encodeString "ダメ"
#とかせにゃいかんのがうざいっす。
#Windows の ghci って、MS-DOS コマンドプロンプトの上で動いているんだっけ
#それとも MingW だったかな
#MinGW だ
#-viaC で、gcc にわたすときに、Windows 特有の codepage を指定する -fexec-charset=CP932 というのがあるらしいのだが
#0
#うう
#-fviaC のまちがい
#さらにまちがいで -fvia-C
#ghc から直接 gcc への option を渡すやりかたがわからないので
#ghc -> C source -> gcc という方法なら、メモ帳じゃなくてもできる可能性が
#ghc -fvia-C -ddump-flatC で C のソースコードでてこないかなー
#手元で Hello, world でもやってみる
#だめだ、dump した .o は、組み込みの ghc のパーツと一緒にリンクする必要がある
#-optc というのが ghc にあるではないか
#これつかお
#ghc -fviaC -optc -fexec-charset=CP932 Hello.hs
#これ、通った
#でも、あいにく今は MacOSX だから、MinGW で表示がうまくいくかわかんない
#またまちがえてる、-fvia-C です...
#cc1.exe: no iconv implementation, cannot convert from UTF-8 to CP932
#ざんねんー
#理由がわかったうえに、ghc の IO が UTF-8 に対応しないかぎり、どうしようもない
#MinGW のバージョンがあがったときに、iconv まわりが変わっちゃったんだって。僕がみた web ページの情報は古かったようだ
#で、iconv を変えちゃうパッチもあるんだけど、肝心の ghc が UTF-8 を正しく吐かないから、それだけでは駄目だという
#CharityはサイトのURLがちょっと変わってしまったみたいです。
##ぜんぜん更新されてないですが。
#Hugs> putStrLn "はろー"
はろー
#hugs だと平気だよという話を聞いてやってみたら本当だった
#Hugs> length "あうあう"
12
Hugs> head "あうあう"
'\227'
#この辺り微妙だけど
#GHC 6.12 に期待せざるを得ない (ていうか head に挑戦してみようかな)
#Charity みつけたんだすげえ
#download のページみたら SunOS とか書いてあって、ううこれは動くのか
##論文一覧みたけど、かろうじてローカルな会議に一報か
#まるでどこかを彷彿とさせるような
#11 Aug 2000 : We have been fixing a number of bugs in the Charity interpreter, the sources will be frequently updated with these fixes.
#あたりでとまってる
#うーむ、a number of bugs とはおおきくでたな
#<strong>CHARITY HAS NOT BEEN OFFICIALLY RELEASED. </strong>
#はいはい
#Windows 版の tar.gz も置いてあるけど、とりあえずソース見ないとなんとも
#hugs の i18n は試す価値があるなあ
#が、いたるところ char * だったりするんだろうなあ...
#むむ、hugs98-Sep2006 では Unicode フラグたってたら wchar.h だ
#関係ないけど、Unicode フラグつけない場合は、ASCII コードが連続していることを仮定している、それは C-FAQ でやっちゃだめってかいてる。が、今のシステムはだいたい連続してんのかな
#char.c のなかの /* number of characters in the block */ の計算式がひどい
#これでは、先ほどのように、正しい長さがでないのも納得
#で、切り出しもその長さを利用しているから変なところで切れる
#これさえ直せばいいのなら、4 日間 hack のネタのひとつにはなるかなー
#ああ、しかし右から左へ書く文字のことを考えると、現状の構造体をすべて直さないと(そして、それは char.c のほぼすべてを書き直さなければならないことを意味する
#くけー
#ghc よくやった、えらい(iconvつかっただけらしいが
#残念ながら Windows に対しては（今のところ？） locale encoding <-> Unicode が提供されていないので、HEAD（Current）ではこんな感じになってしまいます。
#C:\home>C:\home\ghc-6.11.20090803\ghc-6.11.20090702\bin\ghci.exe
GHCi, version 6.11.20090702: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :m System.IO
Prelude System.IO> putStrLn "はろー"
o刷
Prelude System.IO> :t utf8
utf8 :: TextEncoding
Prelude System.IO> :t hSetEncoding
hSetEncoding :: Handle -> TextEncoding -> IO ()
Prelude System.IO> hSetEncoding stdout utf8
Prelude System.IO> hPutStrLn stdout "はろー"
縺ｯ繧阪・
Prelude System.IO> hPrint stdout "はろー"
"\12399\12429\12540"
#テキストに出力すれば結果を確認できますが、それは今の GHC で utf8-string を使ってもできますよね。
#Prelude System.IO> h <- openFile "dummy.txt" WriteMode
Prelude System.IO> hSetEncoding h utf8
Prelude System.IO> hPutStrLn h "はろー"
Prelude System.IO> hPrint h "はろー"
Prelude System.IO> hClose h
#はろー
"\12399\12429\12540"
#hSetEncoding stdout utf8 ってできますか?
#あっ、hSetEncoding は HEAD（Current）の新 API です。
#hSetEncoding は stdout とかに使えますか or 意味がありますか?
##あ、最初の例で使ってるのに今気づきました。。。
#Prelude System.IO> :t hSetEncoding
hSetEncoding :: Handle -> TextEncoding -> IO ()
#この部分をみれば、ハンドルを返す関数である stdin、stdout、stderr に渡せるのが分かると思います。
#そうです。最初の例で使っています。
#上の dummy.txt を Shift_JIS で開いてみれば分かるのですが、プロンプトに出力されている結果は UTF-8 の文字列を Shift_JIS でデコードさせようとして文字化けさせてしまった結果と同じです。
#縺ｯ繧阪・
"\12399\12429\12540"
#なるほど
#そしたら、hSetEncoding stdout shiftJis(あるかどうかわからんけど) とかやると Windows のコマンドプロンプトではうまくいくってことですか?
#現在のところ shiftjis は提供されていないのですが、shiftjis が提供されればそれでうまくいくはずです。
##あ、mkTextEncoding っていうのがあるんですね
#それはあくまで GHC または IConv の方で実装済みの文字コードを使用するためのものです。
#Windows は iconv を使っていないので、もう少し深いところにある関数を使って実装する必要があったと思います。
##うわ、本当だ
##Windows 用に自前で UTF* を実装しているので、実装の参考にするならそちらも見た方が良いと思います。
#Hugsは(昔使ってたときから退化してなければ)ちゃんとUnicode対応にしてビルドすれば、IOもlengthの文字数とかも正しく動作しますよ。
#外部エンコーディングにlocaleのエンコーディングを使う場合には、Unicode⇔localeの変換にwchar_t系の関数を使ってるので、wchar_tがUnicodeな環境でないと正しく動作しないですが。
##char.c のなかの /* number of characters in the block */ というのは struct CharBlock の blk_length だと思うけど、これはUnicodeのテーブルから自動生成された値が(unitable.c)で定義されているだけで、特に変な計算式とかは使ってはいなかったような……
#あと、右から左へ書く文字については、Haskell処理系は特にUnicodeのレンダラーを持ってるわけではないので、特
#特殊な処理はせずに、単にそのまま入出力すればいいだけではないかと思います。
#それと、Charityは、昔試したときは、普通のx86なLinuxマシンでも、特に苦労せずにビルドできたような気がします。
#./configure --enable-char-encoding=utf8 でコンパイルしてみたらいい感じになりました > hugs
#Hugs> length "へろー"
3
Hugs> head "へろー"
'\12408'
#は = \12399, へ = \12408 (Unicode コンソーシアム標準) なので、shelarcy さんの例、nwn さんの例、それぞれいいみたい
#だけど、'\xxxxx' って表示じゃなくて、その文字を表示してくれないのかなー
#Hugs 98 の unitable.c までは見てませんでした、ありがとうさかいさん
#あと Charity や、萩野先生の Categorical Programming Language おもしろいんだけど
#Zero が 1 -> X {- initial -} ってのは、知っているひとしか知らなくてわけがわかんないと思う
#そのための準備のマテリアルがひつようだとおもって、うんうんうなっています
#どこかの lecture notes でも参考にすればいいのかなあ、google 先生に聞いてみよう
#まずは Peter Dybjer 先生だっと思ったけど、あまりに専門的すぎる気がする
#Anton Setzer 先生のところも見よう
#Dependent Types 連合は、わかっててあたりまえ、みたいなかんじでだめだ
#Wikipedia から Initial Algebra 経由で VARMO VENE 氏の Ph.D thesis (2000) にたどりついたが、これは簡潔
#もうちと用語に説明が必要だが、気に入ったものが見つかってよかった
#R.Bird & O.de-Moor は Initial Algebra の定義をうにゃむにゃしているので、それはよくないと前から思ってたんだよな
haskell-ja > Archives > 2009/08/04