星の贈り物

Generic Type の深い話

[topic:C++、D、Python]

Python オプショナルな静的型に generic type を入れるの止めちゃったかー。まあ、分かる話ではある。generic type というのはかなりの曲者ので、暗黙のインスタンス化を許さないと書きにくいような関数もあるのに、許すと戻り型や 別名 ( エイリアス ) をどうするという話になってきて、C++ ではこれに決着がついてないがためにコンパイル時のエラーメッセージが分かりにくくなったり、現在は遠回りを強いられていたりする。また、C++ で行われたような悪しき複雑化をさけるように generic type を定義しつつ強力なものにしていくという試みは、generic type 自体をマクロで実装してやって静的型に見えるけど実は動的なんだという CLOS や型推論ベースで実装した関数型言語くらいでしかまだ成功していなかったりする。この辺の鬱陶しいのを捨てようとしたのが D 言語であり、max 関数が簡単に書けないという犠牲のもと暗黙のインスタンス化を捨て去ったのだが、強力な Template Metaprogramming への道を狭めマクロも持たないこの言語が生き残っていけるかどうかは見ものであるといえるだろう。関数型言語も全面的に成功したかというと、オブジェクトの扱いは OCaml のようにまだ完成してなかったり、存在量化型でいいのかオブジェクト指向を組み込まなければならないのか決着がついてなかったりもする。

そんなわけで気持ちはわかるけど、こんな中途半端な形で静的型を入れるんならやっぱり Python は選択肢から除外。私的には。

Haskell で XML 処理

[topic:Haskell、XML]

やっぱり HaXml を使うのがいいという結論に。Haskell XML Toolbox は色々と出来るように見えて XSLT 的にドキュメントを変換する方の関数ばかり備えていて使いにくいというか大ナタを振り回しているような印象がある。namespace や不正な XML/HTML への対応、RELAX NG への対応予定など魅力的な要素もあるけど……という感じ。HaXml の XSLT の代替ともいえる文書変換ツールとしての役割に刺激を受け、HXML のツリーを辿っていくものから発展させたけっかだろう。XSLT も使用可能にしようとしていることから分かるように、作者が文書間の変換にしか興味がないようでそっちの API ばかり充実させて HaXml にはあるような低レベルのもう少し広い用途に使える API がないので現状では XML の応用とかフォーマットとしての利用などをしづらい。一方、HaXml は Windows Native な GHCi 上で動作を一々確認できなくなるのが問題だったりする……いや、コンパイルして調べていくっていう方法もあるけど、なんかそれは面倒というかなかなか気が進まなかったので遠回りしたんだけど。

……ていうことを理解するのにずいぶん時間がかかった。論文と Haddock による記述だけできちんと文章化されきれてないせいだ。ドキュメントの自動生成は良いけど、そればかり当てにしてしまってきちんとした文章化を怠ることもあるという良い例。これが Haskell コミュニティに蔓延しているから困るんだけど……。

Haskell で XML 処理 (2)

[topic:Haskell、XML]

以前使いにくいと言っていた Haskell XML Toolbox だけど、HAIFA の以前のバージョンのソースを見てどうにか XML から情報を取り出す方法が分かったので使ってみることにしました。

loadLicense :: FilePath -> IO [(License, String)]
loadLicense = run' . loadLicense'

loadLicense' file = do
    string <- io $ readFile file
    x <- (setSystemParams
        .>>
        checkWellformedDoc         -- parse the document
        .>>
        liftF canonicalizeAllNodes -- Remove Header and bits we aren't interested in
        .>>
        liftF propagateNamespaces  -- Propogate namespace URIs down the tree
        .>>
        liftF (removeDocWhiteSpace)
        ) (head $ rootTag []  [mkXText string] emptyRoot) -- Create a top level tag with XML data
    xmlVal <- liftF (multi (hasLocalPart "License")) (head x)
    let ln = mapM (\x -> map tagToLicense (getChildren x)) xmlVal
    return $ concat ln


tagToLicense :: XmlTree -> (License, String)
tagToLicense xml = (stringToLicense $ xmlTreesToString $ getAttrLP "license" xml, xmlTreesToString $ getChildren xml)

getAttrLP :: String -> XmlFilter
getAttrLP x = getAttrl .> hasLocalPart x .> getChildren

run' というのは、要するに、XmlState state の所属する Control.Monad.MonadStateIO.StateIO から IO へ値を移す monad transfer で、io はその逆です。mapM (\x -> map tagToLicense (getChildren x)) xmlVal の部分は xmlVal から素直に getChildren で値を取り出すと XMLTree ではなく XMLTrees となってしまってしまうので、そこをうまく解釈してもらうためのトリックです。

このあたりで、随分とお約束があるなと思われるかもしれませんが、こうした手間を要するのはデータを取り出すときだけではありません。保存時にもお約束があります。

saveLicense :: [(License, String)] -> String -> IO ()
saveLicense licenses file = do
    h <- openFile file WriteMode
    let x = head $ serializeLicense licenses emptyRoot
    hPutStr h "<?xml version=\"1.0\"?>\n\n" -- Adhoc and nasty, but hey it works.
    run' $ hPutXmlDoc h $ head $ indentDoc x
    hClose h
    where serializeLicense licenses = rootTag [] [stag "License" $ map serializeRights licenses]
          serializeRights (license, place) = mkXTag "Rights" (sattr "license" (licenseToString license)) (txt place)

tag を生成する関数はすべて XMLFilter で XMLTree を要求するので、emptyRoot という空の XMLTree を与えなければなりません。(XML 文書でないところに注意)　また、文書からデータを取り出すときもそうでしたが、空の rootTag が必要になります。あと、データを取り出すときなども「XMLTrees なので head を取り出してね」というお約束があるのも鬱陶しい。

……とまあ、内部構造が分かっていないと使いにくい(おそらく)世界一難しい XML API なんですが、readline パッケージを呼び出さないので 6.2.2 以降の Windows 版 GHCi 上で動かしながら試せる (openFile が引っかかったりするけど)のと不正な XML 文書のエラー報告と将来の RELAX NG サポートを当てにして採用してみました。Linux で開発している作者が何も考えずに http アクセスに posix と curl を使うという選択肢を用意しているので、Windows で使うためにこうしてあるけど。

module Text.XML.HXT.Parser.ProtocolHandlerHttpNativeOrCurl
    ( getHttpContentsNativeOrWithCurl
    )

where

(.. snip ..)

{-
import Text.XML.HXT.Parser.ProtocolHandlerHttpCurl
    ( getHttpContentsWithCurl
    )
-}

(.. snip ..)


getHttpContentsNativeOrWithCurl		:: URI -> XmlStateFilter a
getHttpContentsNativeOrWithCurl uri n
    = do
      curl <- getSysParamInt a_use_curl 0
{-     (if curl /= 0
	then getHttpContentsWithCurl
    else
-}
    -- getHttpContentsWithHttp ) uri n
      getHttpContentsWithHttp uri n

同様に Makefile や package.conf も今のままだと使えないので、そのうちパッチを書かないと……。

FunctionalForms の未成熟なところ

[topic:Haskell、GUI]

wxHaskell の GUI を関数的に書くためのライブラリとして FunctionalForms とか wxFruit が考案されているわけですが、少々欠点があります。後者は(現段階では) Custom Contorl などを作ったときにそれに対応するようライブラリのコードを書き換えないといけないというモジュラリティの低さが問題になるのに対し、前者は

(entry' []) *| ((checkBox' []) *- (checkBox' [])) ...

のような形が延々と続く組み合わせを自動的に生成するような関数の存在が考慮されていないことが問題になります。

(String, (Bool, (Bool, ...)))

みたいに要求する型がネストしていくので性質が悪し、run_in_dialog のコードを dialog 以外でも使えるように書き直すように GUI を生成する部分を書き直してしまえばいいんでしょうけど少々めんどくさい。まあ、本来 row' とか colum' なで区切っていくように wxHaskell はできているのでそっちの方で対処できないこともないけど、なんのために *| や *- といった Utility 関数があるのかという意義を問われるところ。

WebObjects

[topic:プログラミング]

WebObjects の入門書を読み終わった。WebObjects って結局 Java であることがマーケティングの都合に過ぎないんだね、ってことがようく分かった。Objective-C を使っていた時代には明確であったであろうコードが、Java を利用することによって副作用を多用する不明瞭なものになっている……。だけどフレームワークとしてよくできているのは確かで、ページ中に動的な要素をバインドさせたり、逆にインプットとかをコードにバインドさせたり(値を入れ込むところを指定するだけ)、といった部分が理にかなったやりかたでとてもうまくできている。流石は(方便だったとはいえ)コーディングなしの開発を目指しただけはある……もっともそれには IDE も深く関わっているし、他のフレームワークや PHP などを知らないので比べられないところもあるだろうけど。

なるほどねー。CGIKit とかでなぜ真似するのかよく分かった。でも Java だと無駄なコーディング量が多くてもったいない。