#pseudo recordの仕組みっていうのは要はデータストレージとメタ情報を分離するって考えで(binary.ftypeもそう)、その考えに基づく限りは既存のpseudo recordの実装にこだわる必要はないと思います。もちろん利用した方が手っ取り早いなら利用すればいいんですが。あとrelationというのも抽象的なモデルの話なので、アクセス層がビットフィールドなのかポインタなのかとかってあんまり関係無いような。もちろん、具体的にバイナリデータが手元にあって、それを簡単にrelationで扱えますよって応用が実際にあるならつなげる価値は十分にあるでしょう。
#そうなんです。relationで低レベルの処理をしても構わないわけです。そういうふうにするとどうなるのだろうかと考えたという。具体的にはModuleはrelationとして扱えそうな気がします。
#具体的にこれが実用的な例というのはないので、主張としては大変弱いのは承知しています。
#思いつきで色々遊んでみるのは良いと思います。もし何か便利な応用が見つかったら、Gauche本体の方に頂きたいと思います。
#タプルとリストの違いというのは、リストは部分リストをとっても型が変化しないが、タプルは部分をとると型が変化するという点にあるかと考えています。すなわち、それこそがタプルの定義になる。これを別の観点からいうならば、タプルとはメタ情報をリストで持っていると言える。これを敷衍したような型を定義しようとしています。> データストレージとメタ情報を分離するって考え
#ビットフィールドというのは、メタ情報としてbit-fieldの引数を持っていると見なせる。その延長にftypeのようにさらなるバイナリの情報をもたせたものがあると見える。
#なので、メタ情報のappend、zipにより、型を構成していくような構想(すみませんコードで提示できなくて。)
#話を戻しておきますと、ErlangのBit Syntaxはftypeで実装しようとしていることに近く、パターンマッチに使えるということなんですね。
http://www.erlang.org/documentation/doc-5.6/doc/programming_examples/bit_syntax.html
#Erlangのあれは通信パケットを扱いたいと考えれば自然ですね。Gaucheもバイナリデータを扱うことがちょくちょくあるんで、rfc.ipやrfc.icmpみたいなコードをもっと綺麗に書きたいというのがbinary.ftypeの背景にあります。そういう応用の場合、性能が重要で、特にアロケーションを一切しないということが何より大事だったりします。
#ところでrelationはその名のとおり、将来的にはその上に関係演算を載せるために作ったものなんで、まあビットフィールドにアクセスできてもいいけどビッドフィールドで関係演算をする応用ってのがいまいち想像できなかったり。タプル取り出しちゃうとアロケーション入るし。destinationとなるストレージを別に用意しておいて、バイナリデータのgatherやpackをやるっていう用途はありますが、relationの上にうまく乗っかるかなあ?
#複数の機能に関する変更を並行してやってて、一方の機能の分だけをコミットしようとせっかくこまめにgit addしたのに、git commit -a -m 'commit log' とやって全部混ぜてしまう悲劇。
#relationでビットフィールドを扱う件、バイナリーだけの話でなくてバイナリー的なデータと従来のDB問い合わせ的なデータを統合できるのかしら？とか考えたのでありました。ファイルシステムでいうところのchmodのフラグとファイル名、ファイル名となにかのデータベース。それらをjoinする、的な。
Gauche > Archives > 2013/05/26