次の命令はプロファイル関連の命令のようだ。 .pb .pd .pe .pl .pld .pn .pt

[id:lethevert:20070919:p1] そのためには、ABCコードをラベル毎に分解して、各ラベルをグラフのノードに見立ててconnectivityを計算して、ループにできるところはループに変換して、適切なサイズのメソッドに切り出す。 というところを悩んでいる。単にstrong componentを探せばよいのかというと、そういうわけでもないんだ。

aで始まるラベルがあることに気づいた。前にCleanJをやったときには気づかなかったな。 .aという命令に対応している様子。 何に使うのだろう？

CleanJ v2の課題は、Javaのネイティブスタックを使うコードに変更するというところ。関数呼び出しも、普通のJavaのメソッドと同じ形で呼び出す。 そのためには、ABCコードをラベル毎に分解して、各ラベルをグラフのノードに見立ててconnectivityを計算して、ループにできるところはループに変換して、適切なサイズのメソッドに切り出す。その上で、スタック上の値をローカル変数に割り当てる。

Heapを作ったのだけれど、よく考えると、あんな単純なヒープではちょっと使いどころが微妙で、decrease keyとかできる必要がある。それをするには対象のキーがヒープの中のどこにあるのかが定数オーダーで発見できなければいけないけれど、そういう構造にはなっていないな。 どういう風に組んでおくのが汎用的に使い易いのだろう？

Heapモジュールも作った https://cleanoptenv.svn.sourceforge.net/svnroot/cleanoptenv/trunk/AltEnv/Data/破壊的なやつばかりでなくて、関数的なやつも作った方がいいかもしれないけれど。 赤黒木とか二項ヒープとか。 フィボナッチヒープは、論文を斜めよみしたけれど、関数的に作る方法がすぐには分からなかった。

Hashtableモジュールが完成した https://cleanoptenv.svn.sourceforge.net/svnroot/cleanoptenv/trunk/AltEnv/Data/

なんていうか、Cleanで破壊的操作を書くのがうまくなったなと思う。

シンボルテーブルとプライオリティキューを作ってから、CleanJをやることにした。 - とりあえず、すでにHashtableは作ってあるのだけれど、前から作りなおそうと思っていたので、ここから始める。 https://cleanoptenv.svn.sourceforge.net/svnroot/cleanoptenv/trunk/OptEnv/OptHashtable.dcl https://cleanoptenv.svn.sourceforge.net/svnroot/c…

そういえば、Cleanには、なぜか算術右シフトはあるのに、論理右シフトがないのだった。 - 調べてみると、論理右シフトがない言語っていうのも少なくないのだね。

S shared 共有 S strict 正格 U unboxed 非ボックス化 U unique 一意 それぞれ、２重の意味がある。

AltEnvが、それっぽい感じになったので、このあとどうしようかと思っているところなのだけれど AltEnvのライブラリを充実させる Cleanのコンパイラやランタイムのソースに潜ってみる CleanJをもうちょっとまともなものにする というような選択肢があるが。 AltEnvをやるのは、まあ、今の路線をそのまま続けるということなのだけれど、ちょっと飽きてきたところが。やるとすれば、LoggingとかDirectoryとかOptEnvとかRegular Expressionと…

PartialReaderモジュールを作った。 これは、http://cleanoptenv.sourceforge.jp/wiki/view/tips/lazyIO/で書いた入力ファイルを一部しか読まないというアイデアを、モジュールにまとめたものだ。 これ以前に、入力ストリームを、readBufferという型クラスで表現したので、ファイル入力だけでなく、さまざまな入力に対してこのモジュールが適用可能になる。 https://cleanoptenv.svn.sourcefor…

[id:lethevert:20070904:p2]の件だけれど、パターンマッチでマクロを定数として扱えることに気づいた。 :: PassFail f p = Pass !p | Fail !f :: Void = Void PassV :== Pass Void f b = if b PassV (Fail "Fail") g PassV = True g (Fail _) = False なので、返値がない場合は、これを使えばよい。

IO系のモジュールを追加した。まだ試行錯誤中。

値を返すかエラーを返す場合には、PassFailという型を定義しているけれど、値を返さないかエラーを返す場合はどうしようか？ SQLモジュールでは、Maybeを使って表現していたけれど、はっきりそれと分かる型を用意しておく方がよいように思う。 :: PassFail f p = Pass !p | Fail !f

[id:lethevert:20070829:p3]の話はようは参照型との組み合わせのことを考えた話で、*Ref *StdErr と *Ref *File とは型に互換性がないから、途中で参照の中身を変更することはできないけれど、ロギングライブラリを作るには出力先を標準エラーからファイルへ動的に変更できる必要があるので、違う型で同じクラスに属するものを別の同一の型に変換するような仕組みが必要ということを考えている。 bounded existential typeはそれにぴっ…

Cleanの入出力ライブラリの置き換えとして、Streamというモジュールを作ろうとしているところだけれど、２年前に http://www.geocities.jp/lethevert/clean/oop02.html#polymorphic_list で考えていたテクニックを使う所かもしれない。

StdFileのインターフェースは気持ち悪すぎる。あとで、全体的にインターフェースを作りなおす。 StdEnv以外で作業が必要な基本ライブラリは・・・ ArgEnv Directory ExtendedArith Generics - gEq, gPrint どれも、気持ち悪かったり、AltEnvのインターフェースとあわなかったりするので、いろいろ作業が必要。

Haskellな人に質問ですけど、IO Monadで参照透明を担保しているのは、モナドそのものの機能ではなくて、IO Monadから値を取り出すことができないというところにあるのですよね。 ああ、いや、参照透明なら置換しても意味が変わらないはずで、IOの回数も変わってはいけないから、トップレベルしかIO Monadを処理できないところと値を取り出せないところの２つを組み合わせて、参照透明を担保しているというべきかな？ しかし、IOの回数と停止性の問題に興味がないとすれば、値を…

大体山は越えたと思う。 後残っているのは・・・ StdOrdList StdTuple StdFile あと、StdListで後回しにした関数がいくつか

今作業中のAltEnvというのは、StdEnvの関数を再定義して、さらに不足している関数を補って、もっとスマートな標準ライブラリを整備しようという取り組みなのだ。 で、その中で、文字列表現として、３つの表現をサポートすることにしている。なぜ３つもサポートするかというと、パフォーマンス上の特性の違う３つに対して互換性のある関数を提供することで、チューニングを簡単に行うことができるようにするという意図がある。 選択した３つの表現とは、次の３つだ。 [#Char] {#Char} …

[id:lethevert:20070821:p1], [id:lethevert:20070821:p4], [id:lethevert:20070823:p4] などで悩んでいた問題の解決策が見付かった。 例として、% (slice)を挙げると、次のように書くことで、これまでの問題を全て解決することができる。実は、似たようなテクニックはすでに標準ライブラリの正格リストの操作関数の定義で使われていて、これは、それを応用したものだ。 instance % {a} instan…

現在のCleanのランタイムはスレッドセーフでないので、１つのプロセスに１つのスレッドしか実行できない（ということは前のLL魂でも言った）わけだけれど、どうやらWindowsの64bit版のランタイムでThreadSafeなものを現在作成中だそうです。

[id:lethevert:20070821:p4], [id:lethevert:20070821:p2] いろいろ考えたけれど、結局、非ボックス化配列や非ボックス化リストを他にペナルティなくうまく扱う方法は見付からないので、それらはパフォーマンスチューニング上の特殊なやつだとあきらめて、他のものと同じインターフェースで扱う関数を提供することをあきらめることにします。 その代わり、% (スライス)については、文字列と汎用を同じ演算子にすることにします。 連結も、+++ をや…

++がリスト型専用の演算になっているので、型クラスで置き換えたライブラリを作ってみている。 class (++) infixr 5 q a :: !(q a) (q a) -> q a という宣言にすると、リストの++を行うのに型コンテキストが必要になってしまった。 class (++) infixr 5 q :: !q q -> q ならば、型コンテキストなしでよいのだけれど、文字列も同じ演算を使えるようにしようとするとこれだとよくないのは前に書いたとおり。 - しかし、こ…

++が第２引数がnon-strictな連結なら、第２引数がstrictな連結は・・・ +++は文字列専用にしたので、一般の連結に使えるものは、と思ったら、一番一般的なものを見落としていた。+が同じ型を持っている。 でも、+を使うなら、これを文字列専用にして、+++を一般の連結にする方が直感的だよなーとか思って・・・

同じことが % (スライス) にも言えるわけで。 文字列専用の演算と一般のスライスを別の識別子に分けておかないと、配列のスライスが作れない。 - あるいは、要素の型を区別するように書き直すか。

いろいろな操作を型クラスで統合して、さまざまなコンテナを同じ操作で扱えるようにしてみたら、いままで単純に扱えていた操作が型コンテキストを必要とするようになって、逆に面倒になってしまったという罠。 もっとも、リスト操作でもっとも重要な length, ++ は型コンテキスト不要なので、無視できると言えなくもない。 - lengthの型クラスの宣言 class length m :: !(m a) -> int のようにすると、型コンテキストを付加しないでよいということに気づいた…

次のような指定はダメ。"multiply defined"といって怒られる。 class A q where a :: q -> {#Char} instance A {#a} where a _ = "Array" instance A {#Char} where a _ = "String" 次のような指定はOK。 class B q a where b :: (q a) -> {#Char} instance B {#} a where b _ = "Array" in…