#pushやpopの引数はどうやってつくるの？>nobsun
#たとえば(意味ないけど) id = pop . (push 1)って関数は作れそうだけど
#id s = pop (push 1 s)って
#あー
#同じことか
#じゃあpoint freeで書く書かないに関わらずこれらの関数ってどうやって使うの？
#Stack aなデータを作れないと実際役に立たないように思える
#あーemptyがあるから作れるってことですね？？
#つまりコンストラクタを使って例えばすでにスタックに要素があるようなものは作らせたくないけど
#emptyを介して空のスタックだけは作れるからと。
#この場合値構築子が提供されてないからパターンマッチも使えないので実装に手を突っこむ事はできない>安全というお話だったのかな
#ここでちょっと話がずれるけど
#例えば上記のようなStackを考えた場合でいいんだけど(隠蔽云々は関係なしで)
#このスタックにa型の値を入出力で与えてpop/pushするように修正したいと考えたとします
#この前のicfpの様にVMは作った。
#そこの入出力ポートに外部から値を与えたいみたいなの。
#その場合まずまっさきに考えるのは何でしょう？
#とりあえず newStack :: IO (Stack a) とかを考える？
#例えば命令型言語では「入出力の口を付加する」という「追加」がアドホックにできる感じがあると思うんですよね
#ちょろっと横っ腹に穴あけてーみたいな。
#もしStack aをIO (Stack a)と考えるのがそう的外れじゃないとしたら
#これはStack aをIO修飾によってStack aの亜種を考えている=>オブジェクト指向の「継承」にむしろ近い感じを抱くのですが
#考え方ずれてます？
#スタックの最初の状態は empty
#です。
#でもemptyの実装は隠れている
#それでもスタックは作れますよね。
#データ構成子がなくても、構成できればいいし、分解できればよい。構成するにはempty、又はpush、分解するにはpop
#VMでもおなじ。構成関数と分解関数があればよいだけで、IOとは関係ない。
#「入出力の口を付加する」というのはどういうことを指してるの？たとえばCだったらどういうこと？
#> 例えば上記のようなStackを考えた場合でいいんだけど(隠蔽云々は関係なしで)
#隠蔽の話とは関係ないですよ
#命令型の言語だったらgetcharしてそれをVMのIPortにそのまま代入してしまうんじゃないかな？
#それ以外に思いつかないけど
#あーそのままではなくて数値にしたりはするけど。
#とりあえずVMと無関係にgetcharしてVMのIPortの特定番地に代入するようなのを
#最初に実装したVMと全く無関係に追加してしまうじゃないですか
#それを「入出力の口を付加する」と言いました
#隠蔽の話は
#あーemptyがあるから作れるってことですね？？
#
つまりコンストラクタを使って例えばすでにスタックに要素があるようなものは作らせたくないけど
#
emptyを介して空のスタックだけは作れるからと。
#ってことで了解してます。コピペが~~
#混乱させたくはないのだけれど、割り込むと
#いえ、どーぞ
#入力 port が増えたら、その分のコードを書かなきゃいけないのは言語とは関係ないです
#はい。もちろん
#付加するというのが誤解を生んだかな
#で、(1) IO モナドで頑張る (2) 自分で抽象化したモナドをつくる
#(Arrow のほうがスマートなんだけど、それはそれとして)
#(2) のほうが、健やかなコードになる
#liftIO という関数を使う
#あ、ちょっと
#待ってください。
#まだ、その詳細には行ってないのでストップです。
#はい、待ちます
#追加しないといけないのはOKです。
#で、命令型言語に馴染んでたとすると
#getcharしてVMのメンバのIPortに代入操作をすればよさげ
#という風に「考え」るかなーと思います。
#それは、私のことばでは、(1) IO モナドで頑張る、にあたりますね
#getChar :: IO Char
#ここはVMは孤立してて何か外から直接手を突っ込んでいるイメージです
#s/ここは/ここで/
#そう
#そういうものを作りたいときは、VM の「層」をイメージすることになる
#で関数型言語ではまずどう考えるんだろうかなーと思ったのがここでの質問だったわけですが
#「層」？？
#そこのところ！が知りたい
#[IO low-level rayer][abstract rayer]
#何を「イメージ」するか
#なんでしょそれは>[IO low-level rayer][abstract rayer]
#たとえば、今回の ICFP の問題だと、[0] : VM の状態を監視する IO
#[1,2,3] 各 ports (1 = Δx, 2 = Δy, 3= Instruction)
#のように、インタラクションがそれぞれいろいろあるわけです
#[1,2,3] は write only で、あと、Score とかを読み込むポートは read only
#一番下のレイヤであるところの [0] IO レイヤでは、ステップ実行や、ブレークポイントで止まる、ゴールに達成したことを知らせる、などの役割を行う
#これらの [0] で行う操作は、Input/Output ports とは独立に行いたい
#独立といっても完全に独立なわけじゃなくて、疎な結合であってほしい
#これが、[IO low-level rayer][abstract rayer] といいたかったわけですが
#長文KY
#0,1,2,3はそれぞれ「層」ですか？
#そうです(おやじ
#その層はVMに対してどう位置付けられますでしょう
#VMとは全く無関係
#とか
#VMを改造することになる
#とか
#VM の改造、でしょうね
#ふむ。
#VM のステートを読んだり、書いたりするわけだから
#僕も今回の ICFP コンテストで、VM をいったん書き終えたあと、その問題に気がついて二度目の実装をした(これでもう3日で出来上がらないことが確定したわけだけど)
#で、その改造をすると考えた時に
#型としてはどういうものになりそうってのは直感的に考えてたりしませんか？
#型は意識しませんでしたが、どのようなモナドをどのように層に積み上げるかを、躊躇しました
#モナド交換子で
#ぬぅ、そこのところがまるでついていけてないです
#Whitespace とか、超簡単な言語仕様の VM をつくってみるのも手です
#僕は 3 回書きました
#1 回目は、IO モナドしか使わない普通の手続き型っぽい書き方でしたが
#少なくともVMのデータ構成子の定義を書き変えることになるかなーと考えるわけではないわけですよね？とりあえず。
#型があっているのにバグが出るというのに悩まされ続け
#VM の Instruction の構文木は、いじりません
#さよなら絶望放送の生ライブのチケットを取れなかったという苦い思い出が：Whitespace すら書けない
#(これはどうでもいい
#考え方としては
#main の型が IO () である以上、モナドを積み上げる上で、最も低いレベル (アクセス権をプログラマが定義しないかぎり、上位層のデータに触れない) は IO です
#IO の上に積み上げます
#すみません。上というと
#モナド構築子で、二つのモナドを合成するのですが
#片方がもう片方の上に乗ります
#IO [a]ならIOが上で[]が下でよいですか？
#ええと、それを積み上げと呼んでいないです、僕は
#do って多段で書けるんですけど
#はい
#do { do { ... }} みたいな
#この外の括弧のほうが上で、中の括弧のほうが下と呼んでました
##に、StateT s m a っていうのがあるんですけど
#この m はモナドで、
#StateT s IO a っていうステートモナドは僕の言葉で言う、IO の上に積まれたモナドです
#あーなんか良く分らずに使ったことあります！
#IOモナドの中でステートとか使えるやつですよね
#このモナドの中では、自分自身が持っている情報 s (OOP でいうところの instance) も使えるし
#IO もつかえる
#いっぽう、IO からは、プログラマが意図的になんとかしてやらないと、StateT s IO a の s には触れない
#[IO][StateT s IO a]
#という二段の層をなす、ふたつのモナドを作ったことになります
#StateT s IO a もモナドなので
#さらに、このうえにいくらでも StateT で重ねられる
#これは、ちょうど、OOP でいうところの抽象クラスの設計に対応するでしょう
#うーん
#ReaderT とか WriterT も同様にあるので
#アクセス制限もできる
#もしかしてオブジェクト指向で考えるのと考えること自体は大差ないってことですか？
#program counter を勝手に増やすんじゃねえ、read のみ！とか
#そうですよ
#このあたりで関数型言語と命令型言語で考え方が変わるかと思ってたんですが
#OOP も手続き型言語も Haskell も根っこはおなじですよ
#ただ、言葉遣いが違ったり、へんなイディオムがあったりするだけ
#まだちゃんとイメージできてないですが
#その積み重ねた層ってVMを隠すように積み上げられます？
#それともVMは何にも関係しない？
#例えば命令型言語だと
#IPortに代入することと
#OPortから読むことは
#まったく別のところから突っこんだり取りだしたり
#そのせいでどっちが先か分らなくなるとかあるわけですが
#VM の内部状態を隠すことはできます、Input/Output は、port からのみ得られる、みたいな
#できる。ってことは上で話してた層は別にそうではない？
#いや、その層を使うわけです
#ReaderT は、読み込み port のためにあって
#WriterT は書き込み port のためにある
#ってことを層を積んでＶＭをラップしていくイメージだと思っていいんでしょうか？
#s/ってことを/ってことは
#一番下の IO は、動作に割り込みかける、です
#そうですね、僕の考えでは、VM はモナドの層がつみあがったもの、です
#そういうふうに作らない方法もあるのですが
#ぼくはこの作り方がすきです
#なぜかというと、型が read only や write only を保障してくれるから
#IO だけで層を積み上げない VM は、内部状態を誰でも読めて誰でも書けるので、バグの元
#ICFPC 2009 は VM の Instruction が簡単だったので、うっかり設計せずにかりかりと 3. a.m から書き始めてしまって大失敗だった
#その層自体は元のVMを変えているわけではない？
#質問の仕方が変かな
#VMって型ですよね
#この型の定義を変えているわけではないですよね
#VM をつくるのに、分割統治で各層を作るのではいかが、という提案にすぎません
#もし可能ならその思想で組まれたwhitespaceのコード見せていただけませんか？
#昔whitespaceのHaskellでの実装を見てそのままschemeに写経したことあるんですが
#家にかえらないと、その PC 眠ってるので起こせない
#それはあんまりそういう構造じゃなかったのであまりピンとこなかったです。
#そうだね
#あーそうですか、残念。
#ぼくも、その実装は見た
##ただし、工学の常で、トレードオフはあるんですよ
#一度設計した層状の VM をつくったあとで、仕様が変わったりすると、いろいろとめんどくさいことになる
#だるまおとし、やられたらたまらん
#あと、スピードは若干低下しますね、これはもうプロファイラとって、ボトルネックを最適化するしかない
#Arrow でつくると、疎結合の疎の具合がさらにゆるゆるになるので、多少の仕様変更にもすぐに対応できるかわりに
#さらにスピードが低下する
#仕様変更に対する強さ <-> スピード という両軸で見ると
#Arrow <<< State/Reader/Writer monad << ST monad
##ST は黒魔術なので、はっきりいっておすすめできない (が、スピードのために必要になるかもしれないので老婆心で)
#層状につくった whitespace VM は、公開されてる whitespace よりずっと遅いです
#ありがとうございます。
#パフォーマンスはあまり問題ではなくて、どんな風に考えるのかの方に関心があるので十分です
#パフォーマンスを追求した時にどうデザインするかは、まだ私の視野には入ってないです
#なので今回sakaiさんのコードを見た瞬間挫折した。。。
#僕が層状のモナドっていってたのは、英語では Monads as containers というみたいです
#コンテナとしてのモナド、か
#そっちのほうがより正確に意味を成しているな
#何重にもコンテナで包みまくってる
##コンテナというとall about monadでもそのアナロジーが使われてた
#結局 all about monad を読もう！ということになるのだけれど
#あれ、日本語が変だ、とおもう。。。（ごめん nobsun
#うーん、私には日本語訳の存在はありがたい
#原文はそもそもそれが自分の読みたいと思えるものかどうか瞬間的に判断できない
#瞬間というのはざっと見てキーワードが引っかかるかというレベルですが
#アカウント付き Wiki に書いてあったら、気になったところ、提案できるんだけどな
#そのうち、うちのドメインに、アカウント付き Wiki 置くことにしよう (madscientist.jp じゃないところで)
#うは、席を外しているあいだにー。前のほう読んできますね。
#す、すみません
#訳が悪いところは、理解できていないところです。というわかりやすい訳です。orz
#今北産業：いけがみが、モナド変換子を使う VM の作り方をじまんした
#伊東がクレクレした
#以上前回までのあらすじ
#へい。読んできやした。
#感想をどうぞ
#つかご意見をどうぞ
#いま、自分の書いたVM.hsを整理しようとしてたんだけど
#ふむ
#今回のICFPのVMに関してはかなり単純にできる。
#つまり、抽象化したなんでもござれのVMでないほうが簡単
#僕の意見では、1. ステップ実行 (Time frame) 2. スコア変化イベントの取得 3. 問題4 デブリ回収プロジェクトの、デブリ衝突イベント ...
#など、イベントドリブンな reactive system ga
#ごめん。ちょっとまって
#nobsunのVMは最初写経してデバッグしたので知ってるのですが
#あそこで、IOPortに手で入出力できたらうれしいかもって私が言いましたよね？
#ふむ。
#その時nobsunの頭の中で何を考えました？
#まずざくっと直感的にこうなりそうっていうイメージってあったんじゃないかと思うんですが
#それはどういうもの？
#私の頭のなかではVMの実行ha
#最初、Codeシーケンスと
#データの取得
#ああちがうな
#最初は、VMは入出力など考えていなくて
#そうですよね
#今のVMに命令したら新しいVMになる
#inst :: VM -> VM
#instはincPCを始めとしてiAdd/iSubなどなど
#この時点ではiOutputとかiInputなんかもiAddやiSubとなんら差はなかった
#。。。んじゃないかなーと思ってるんですが
#わたしも一回目の VM の実装では Add と Input/Output を同じにあつかってました
#そこでしまったときがついた（おそし
#おそいんですか？？
#そこで別に遅いわけじゃなくて、あとから何とでもなるって言ってほしい
#外の世界と会話するんだから Input/Output は特別に扱うべきだった
#この Chaton で、「ぎゃーす」とか叫んだ記憶がある
#それは型が違うと思ったってことだと理解しても良いかな？
#どっかにIOがからむはず。。。と
#型はプログラムの設計図だから、型が違うことになるのかな
#と、誘導してしまってますが、その辺りがどういう感覚なのかなーというのが関心がある
#C とかで書いていたら、きっとポインタを使えば、構造体メンバに好きなようにアクセスできたので
#汚くなる代わりに、ソースの変更は少なくなったと思う
#そうそうそれそれ。
#いずれ破綻するかもしれないけど、そういうゴテゴテの改修を塗り固めることはできる
#という感じの変更がアドホックにできちゃう
#Haskell も unsafeXXX をつかうとできるんだけど、絶対にお勧めしない
#ほかにも haskell-src-ext package とか、GHC as a library とかいう、黒魔術があって、アドホックにやりたければできるけど、知らんよという
#ていうか、Haskell の場合黒魔術を使うと、唱えるのに失敗してメガンテになるので、結局、正しい方法をいったほうがいい
#一度メガンテをやると、よくわかるのでおすすめする
#（おすすめしない）
#結論から言うと、問題に柔軟に対応できる Ocaml や Scheme がすばらしい、とかそういうオチなんじゃないのかなー
#今回なんて、仕様書が 6 回も変わりましたからね
#もうなきそうだった
#うーん、そうなのかなー
#3 日じゃなくて、一週間とかだったら9回裏逆転ホームラン
#命令型言語って上で書いたように、汚ない修正が可能ですね
#とりあえず全体設計は無視して一部だけごちゃごちゃっと回避するパッチを当てたり
#型で見たらムチャクチャすんなーって感じのパッチを当てることができる
#(void *)
#それを仕様変更に強いとは思いたくないなぁ
#あーすみません。型で見たらどうこうってのは命令型言語だからじゃないのかもしれないな
#ちょっと私の意見もかたよってるか
#「関係の圏」というのを理解すると、もうすこし、視点が変わってくる、と Miranda の偉い人が言っているので、それを勉強中
#それを言うなら強い型付けの言語と型の無い言語とかの比較になるのか
#仕様の変更は、ちょうど圏から違う圏への移動になるので、偶然、自然変換だったら、変更が少なくてすむ（日本語で言え
#うぅ、その議論にはついていけないですorz
#わたしもよくわかってない
#こんにちは。
#お、きた
#おつかれ
#がんばりましたねー
#ありがとー
#今ソースの整理中してます。整理出来たら再チャレンジしよう。
#すばらし
#今回の仕様変更といえば、結局、設計に影響がありそうなのは、月が現れた！って話だけかな。
#問題 4 だっけ
#そうそう。
#あ、100xで燃料無駄遣いした方が良いってのも、まあそうか。
#一位 pepsiso の、二人組みのひとりのいなばさんのログがためになった : http://www.kmonos.net/wlog/ #お、更新されてる。
#kinabaさんは相変わらずすごいなぁ。
#こんだけ遠回りしてるのに、一位ってどんだけー
#VM をインタプリタで組まないとか...
#D -> C -> Java と三種類の言語で VM つくってるし...
#まんなかは C++ (as better C) かな
#あと、いろいろツールもマメにつくっている様子
#重要ですよね > ツール
#私はSDLで超手抜きビュアーを書くだけしか出来なかったけど
#私は日曜日にふて寝してしまう根性なしをなんとかしなければ
#どうしたのかと気になってたけど、ご無事で何よりでした。
#来客で退席してました
#また前を読んできます。
#実際かなりのところでやばかったです
#去年の ICFPC は無理をして帯状疱疹、今年は、日曜頭痛で寝込むですんだ
#まだ MP がたりない
#おおう。
#帯状疱疹ってうちのオヤジが出て、そのまま放置プレイで直したけど
#あとから死に直結するものだと分って。。。
#そもそも医者に行かずに直すものじゃないとか
#病院ギライのオヤジです
#皮膚科に行くと痕がのこらないようにしてくれる塗り薬を出しますが
#８０００円くらいです（薬代
#別の人もそうだったっていうから間違いない
#え、おれ保険証もってるんですけど、ってうっかり言っちゃったよ
#むしかえしですが、instruction :: VM -> VM
#ひょっとして保険適用外?
#はい>nobsun
#たぶん
#で、nobsun のはなしにもどろう
#として
#あ、でも混合診療にはならないのかな…… 余談でした。
#はい。
#いたんだけど、迂闊なことに、instructionシーケンスをVMの中にいれていたおかげで
#みとうしがわるくなってしまいました。
#たしかに、instruction :: VM -> VM なら、instructionシーケンスはVMの中には入れないほうがよさそう。
#ジャンプがないので、instructionシーケンスを
#リストにしておけば、
#foldl exec vm0
#じゃなかった
#foldl' id vm0 iseqs
#いっぱつで表現できたはず。
#で、そこでだ
#はい。
#私が「手でInputPortにデータを書き込めるようにしてほしーなー」と言った
#ああそれは、その外側のループのはなしだよね
#とすると、まず最初に考えるのはどういうことになります？
#そう
#あ、そうなの？
#素直に^^;ループを書きます
#VMには無関係になるんだ？
#ループって？
#あー上のfoldl'はone stepだっけか
#そう。
#おk
#外側ってのはOKです
#コントローラとのIO
#で、one stepごとに入出力したいとなるとVMには手を加える必要はない？
#?
#そうそう
#必要ない。
#ジャンプとかないから、そこはきれいに分けられる
#あの場合コントローラってロジックが見えてからの話かなと思うので
#まずはどういう感触か手で操作してみようかなーと思う。
#これはあくまで個人的な戦略なので異論あるだろうけど
#上位ゲットしたひとたちは、最初はみんな手で操作したみたいだよ
#今どういう型を考えてます？
#そうなんだー > 上位ゲットしたひとたち
#TMVarとかで包むだけかなぁ。
#shinh 氏と kinaba 氏のブログを見た感想
#それも、VM全体ではなくて、Portだけ
###TMVarってのを使うってのは良く知らなかったので、
#そこでついていけなくなったのですが、
#これは実装の一選択？
#最初は、別スレッドにしてやるのがいいのかと思ったけど、
#ああでもそうすると全体がIOになっちゃうね。
#あー、つまり一選択肢ですね
#今回の問題は単にコントローラからVMを駆動してやるってので十分だった気がする。
#その実装を選択する前に、こんな風な型になるかなってのは無い？
#この場合は1timeフレーム内では本当に外とIOする必要がないので簡単。
#もちろん、全体がIOになってはしまうんだけど。
#最終的にはそうなるはず>sakai
#ただどういうロジックでコントロールするかを試行錯誤するフェーズとして
#ああそれはたぶん。IOになるだけだからそんなに構造的に大きな変化だとは思わないかなぁ
#手で操作ってのとロジックで自動操縦ってのをスイッチ一発で切りかえられえばっておもった
#私の実装は、コントローラの記述はIOにはしなかったよ。
#kinaba 氏はサーバクライアントにしたようだ
#（日記参照
#newtype Automata i o = Automata (i -> (o, Automata i o)) という Arrow を作って書くようにした。
#ちょっと待ってー！
#という Arrow を作って、それで書くようにした。
#私の実装は誰にも見せてないけど、Input は空いてる socket, アウトプットは JSON 書き出しにした
#ついていけてない
#ん?
#私は別スレッドにしただけ
#上でnobsunとsakaiさんが全体がIOになるとかならないとか
#データのやりとりはSTM
#はい
#言ってるけど、「おおざっぱでいいので」型で言うとどうなります？
#全然同じイメージが共有できないわたし
#VM -> VM が VM -> IO VM
#かなしい...
#それが全体がIO？
#うん。
#あれなんか変？ > ikegami
#いや、VM -> IO VM というのは、レイヤーがなくてさびしいなと思っただけです
#IOがかなしいのでは?
#あ、レイヤーね。なるほど。
#IO もかなしいけど！
#w
#がぁーん
#sakai さんのように Arrow とかでやりたいじゃん、せっかく Haskell つかってるんだから
#つまり命令は今のVMを元に"入出力をともなうVM"を返す
#と読んでOK?
#まあ、Arrowは今回の問題にはオーバーすぎたとは思うけどね。
#OK
#でも、Input port や Output port の追加が急になされたときなどは、Arrow にしておけば、すぐ対応できたと思う
#絵で描ける、すごい
#あくまでも今回のシンプルな場合だけを見ているけどね。
#お、動かしてる?
#あ、それでOK。シンプルな例でないと特別な技術的話題に行ってしまふ
#あーいや、一般に Arrow つこたコードは絵に描けてたのしいなと
#いまいるところには ghc すらないです
#確かに > 絵に描けて
#あれ、でも命令ってどの命令だ>IOが付く。。。
#Input と Output
#iInputとかiOutputがVMの中の話だから違うよね
#VM の内部状態を IO モナドのなかで return value; するってことを話していたのではなかったのか
#ああ。あの今回の場合にかぎれば、VM->IO VMを考えることは絶対ないと思う
#portの追加とかは、モナドで書いていても、VMとコントローラ間のやりとりに使う抽象データ型を拡張すれば済むだけだから、Arrowでなくてもあまり問題はないのではないかと思います。
#そのInput/OutputってVMが外から指示を受ける入力バッファとか外に結果を伝えるための出力バッファだから
#ぬぬぬ？？？絶対ないってのは？
#instructionのところでという限定つき。
#nobsunのVMにちゃんと目を通してないから、話についていけないのであった。
#だいたいわかった
#iAddのレベルのはなし。
#ようするに nobsun の VM は Instruction interpreterだったんだ
#手で制御してみたい
#VM -> VM というのは、そういう意味で
#というかInstructionシーケンスは,VM->VMの関数の配列だった
#というのは標準入力から制御する値を入力して
#これをInputポートに書いたVMにしたいわけですよね
#VM->IO VM は確かにないですね。
#これは命令列とは別ですね
#さっきの話の外のループだから
#VM -> IO (何か欲しいもの) だよね
#あるいは VM -> IO () で、副作用で VM の値を変化させる (IORef)
#となると、どんどんかなしくなる、という
#かなしいというのはimperativeになるって意味ですかね？
#1タイムフレームのなかではVM->[Instruction]->VM
#型による安全性が、貧弱になってしまう
#ちなみに、私のはまさにそんな感じで IOVM -> Command -> IO SensorData みたいな型。
#その外で
#TMVar In -> TMVar Out -> VM -> [Operation] -> IO ()
#てな感じ。
#VMが消えましたな
#それがVMを駆動する関数?
#そう
#run関数？
#細かいこというと OUT は Maybe Out のほうがいいような
#で、別スレッドで動いてるコントローラとTMVarで通信すると。なるほど。
#そそ
#あれ? どうして? > OUT は Maybe Out のほうがいいような
#むしろ IN を Maybe In かな
#そのココロは手で入力しないかもしれない？
#出力が Nothing なときもあるんじゃなかったっけ、もういろいろ忘れちゃった
#自動操縦に任せるかもしれないからMaybe!でOK?
#Maybe In にするのはcontrollerがNothingを入力したときにループを終了するようにする
#空の時は空のIntMapを渡してやればいいだけなので
#今回はタイムアウトを使ったけど。
#ああそうか。
#あのタイムアウトは入力か
#空のIntMapで判定すればいいか。
#反省会重要だなあ
#あー、タイムアウトの話をきいたとき、一体何に使ってるのかと思ったんだけど、そのために使ってたのね。
#そう > timeout
#しかし、空の IntMap を Nothing の意味でつかうというのは、なにかバグがあったときの追求にこまりそう
#明示的に Nothing を使うほうが好き
#ループ終了用だったら、Maybeの方がいいかと。本当に空のデータとの区別がつかないのね。
#それはある。
#つかないので。
#timeoutは？(ｗ
#タイムアウトはcontroller側が終了することを判定しようとした。
#あーでもそれは正しくないかい
#儂もMaybeの方がすき。
#だってシミュレータがスコアを返してきたらもうおしまいってコントローラが判断することになるわけだし
#timeoutだと正しく終了したか、コントローラが手間取っているだけなのかがわからない
#わたしもMaybeのが分りよいけどnilっぽくて空も許せる
#うん、その意味ではtimeoutは実装としては無かったかな、と？
#実際良くわからんところでDoneって自信を持って停止してたし
#いや多分併用。timeoutは例外用
#まあ、コントローラからVM側に終了を通知するなんて面倒なこと考えなくても、コントローラがVMスレッドをkillすればいいじゃん。大げさだなぁw
#まぁでもVM側がコントローラを起動していたので。
#あ、そうだったのか。
#sakaiさんのIO VM -> Command -> IO SensorDataのCommandは
#インストラクションではなく制御するコマンドですよね？
#そうです。VMが読むためのinportの値。
#nobsunと同じく IntMap Double
#どうもIOってののニュアンスがまだ十分に把握できない
#それでふつう
#VM -> Command -> IO SensorDataと書いたとするとダイブ印象違いますか？
#最初のVMにIOが無かったとするとどう思います？
#あ、ごめん。IOVMでひとつの型です。
#その命名はどうかと
#あ、そうなんだすみません
#IOVMは、IOモナドの中で破壊的に変更できる、VMのデータ。
#VMState とかじゃだめだろうか
#それを破壊的に操作するので、返り値の型にIOがついてる。
#なるほど
#うう
#ところで、こんかい使った darcs レポジトリまだ生きてますか
#破壊的に操作する と IOが付いている
#VMState というのは?
#いや、"IOVM" のかわりに "VMState" はどうかなーという
#の間の流れが理解できないYo~~(ToT)
#生きてますよ。> darcs repository
#まだ生きてるけど、いま整理している私のコードははいってないです。
#VMStateみたいな名前でもよかったですね。
#じゃあ、そこに、わたしのしにかけた VM と、あと、昔書いた monadic Whitespace interpreter をおきます
#現時点でtagをうちますかね。
#おお、whitespace見させてもらいます
#あ、ちなみに IOVM は VM IOUArray IORef の synonym です (^^
#ICFP の VM は IO 含めて 5 段の state モナドなんで、lift $ lift $ ... とか平気でつかっていて、絶望しないでください
#＜わたしの
#それは絶望しますって JK
#IO < Error < Writer < State < Reader
#それは命令型言語で言うところの3重ループみたいなものですか(ｗ
#僕に Haskell を教えてくれた Johan 曰く、「俺、最高で七段組んだな」って言ってました
#ああタグをうちそこねた。
#unrecord でもどせますよ
#(マスターをもどしすぎると、過去が消えますが
#ん？打ててるよ
#tagged 20090701
#そろそろ帰って "Types are calling conventions" よもうかな
#17:15 定時
#破壊的に操作する と IOが付いている、ってのはIORefとかを使っているとわかるかと。 > cut-sea
#いや、それ最終コードをカバーしていない多分 > tag
#お疲れsama-
#お疲れ様ー
#では
#ありがとうございました
#また質問します、いろいろ。
#もどったらたぶん chaton にくるとおもう
#トイレとか別にして
#まあいいか。tag
#ではでは
#ははぁ>IORef
#ああ、でもIOVM -> Command -> IO SensorDataは分りやすそう
#儂も移動します。
#おつかれ
#では私もまた。
#お疲れ様です。
#はいどーもおつかれー
#帰宅です
#はや
#icfp09 に、書きかけ VM と Whitespace 実装(遅い)をおきました
#darcs pull すると手に入ります
#ひとつつまらないミス (putStrLn . show) ---> should be 'print' があったので修正
#なんだなんだ？？！
#いきなり挫けそう
#run する方法書いてないから、わからなくて当然です
#(step 実行や breakpoint などを夢見ていたので、main :: IO () などはまだ書いていない)
#VirtualMachine.hsかな、とりあえず
#Objective-C (2.0 じゃないほう) をやってたので、関数名が長くなる傾向にあります
#Haskell のひとは短い名前が好きみたいだが
#Program が Map.Map Integer Instructionってなってるな
#IntMap のほうが断然はやいんですが、Whitespace にはプログラム長に制限がないので(仕様書には)
#Int を越えるプログラムを Whitespace で書くやつなんて世界中どこにもいないだろうが
#:i Data.Map.Mapしてみた
#ここにも!が。。。
#いまどきでいうところの key-value ですよ
#sakaiさんのコード見てなかったらすでにパニクりそう
#これは二段組のモナド構成で、IO < StateT VirtualMachineState
#(ちなみに、よくない設計でした)
#もっと多段に組むべきだった
#w
#run/evalとが核ですね
#はい、そうです
#あれ？スタック操作の命令って仕様で決まってましたっけ？>whitespace
#おーあったあった
#[Space] という prefix がスタック操作
##これが
##だったらもっとカッチョイーのに
#よめないー
#しかし、それはかっちょいい
#ではわたしも帰ります
#なんか色々ムツかしそう>WhiteSpace
#おつかれさま
#.xとか.yははじめてみるな
#Scheme でかいたほうがいいよ
#(とかいう
#あとtemplate/...ってのをインポートしてるっぽかったけど
#なんかファイル必要だったりするのかしらん？
#importではないか
#あー
#プラグマで
#これはですね
#そーゆーの発見
#はい
#*.x と *.y はそれぞれ alex, happy の入力で
#そいつから自動生成されるのです
#なんとなくそうかなーとは
#あー生成されるんだ
#あとWhitespaceParser.hsの中のhappyActOffsetsとか
#見なかったことにして「オレの関心はVM,VM...」と唱えながら裸足で逃げました
#.x, .y とおなじ basename を持つ .hs は俺様でも読めません
#機械生成されてるのでわけわからん
#うん。今の話を聞いて自動生成だな、と。
#Lexer と Parser は .x, .y をみたほうがいいでしょう
#ちゃんとppしてくれるんだと感心。でも当然ですね、レイアウトルールがある言語なんだから
#なんか皆のコード見るとプラグマいっぱいで
#そこで挫折してしまいます
#Haskell98 じゃなくて、GHC 拡張使うんだな
#たしかに、Haskell98 縛りはもはや苦痛である
#ええぇっ、それはちょっと...
#WhiteSpaceは自動生成コードだけですね。プラグマあるの。
#ほぼ素で書かれてる
#そうかも
#では移動
#はい、ではまた
#haskell-src-ext 1.0 おめでとう
#haskell-src-exts だた
#ghcのupdateするかな
#cut-sea@birds:~/devel/ghc$ make install-docs
===--- updating makefiles phase 0
make -r --no-print-directory -f ghc.mk phase=0 just-makefiles
===--- updating makefiles phase 1
make -r --no-print-directory -f ghc.mk phase=1 just-makefiles
===--- updating makefiles phase 2
make -r --no-print-directory -f ghc.mk phase=2 just-makefiles
===--- updating makefiles phase 3
make -r --no-print-directory -f ghc.mk phase=3 just-makefiles
===--- finished updating makefiles
make -r --no-print-directory -f ghc.mk install-docs
make[1]: *** ターゲット `install-docs' を make するルールがありません. 中止.
#む
#ICFP 乙です。なんかすごくたのしそーで俺もやれば良かったなと思いました
#自転車置場(mappend にいい感じの別名を考えてあげようのコーナー): http://doodle.com/4yrfd7qaw5man3rm #ICFPC 2009感想エントリとかリンク集
###ICFP に行ければ、聞くことができるのか、超残念
haskell-ja > Archives > 2009/07/01