Tudura - Happy Life Hacking!

> 多分この方法だと defile-coroutine したものの body が終了するときに、その戻り値が enqueue! されてしまって困る気がします。  
 
ああそうです。コードと説明を短くするために色々前提を端折っちゃってるのが、コーナーケースを考えた時にわかりづらい原因のような気がしてきました。今回の場合コルーチンをプロセスのようなものと考えて「コルーチン全部が終了した時の戻り値」には意味を持たせてないので、例えばコルーチンの最後は(values)で終了する、みたいに決めとく必要がありますね。 
 
もうよく覚えていないのですが、確かここの章ではどこまで継続について書くべきか議論があって、固まったのは本書の中でも最後に近かったはずです。returnはもしかすると後に続く何かの布石だったのが、その何かが削られて今の形になったのかもしれません。 
 
ここでreturnを使うべきかどうかというのは、コルーチンライブラリのAPIをどうユーザに見せるかという設計次第ですので、returnを使わないとだめ、ということはありません。考えてみたら今回のコードではbodyの後に((dequeue! *tasks*)) を挿入するのはdefine-coroutineマクロでできるので、マクロのユーザコードは気にする必要がないですね。その意味ではタスク管理は抽象化されてしまっているので、returnを省いた方が簡単になったかもしれません。 
 

> ご質問のふたつのdefine-coroutineですが、違いがあります。 
なるほどそうですね。 
return の方の call/cc の使い方は、yield の方とは違って「大域脱出の様な使い方」というところまでは考えていましたが、そこから考えれば「必ずしも大域脱出するとか限らない」という事はほぼ自明な気がしましたが、なぜかそこまで考えが及びませんでした。 
 
また、質問というよりも 8割ぐらいの確信で、「return は無意味じゃないか?」と思って書いたのですが、ちょっと自身が無かったので質問っぽくなってしまいました。要するに私が浅はかだったので書いてしまいました。そもそも、ここは質問するところでは無い気がしていたので。 
でも私にとっては自分の間違えが分かって良かったです。本の間違えを見付ける事はできませんでしたが。 
 
 
以降は折角説明してもらったのでその反応です。元の主旨とも離れていると思うので、問題があったり、忙しかったりすれば無視してもらって構いません。 
> 完全に抽象化するなら、returnにcontを渡すようにして、[snip] 
多分この方法だと defile-coroutine したものの body が終了するときに、その戻り値が enqueue! されてしまって困る気がします。 
enqueue! と書きましたが、スケジューラとしては継続の「保存」,「取り出し」の2つの動作が必要だと思うのですが、スケジューラは取り出した継続がこれから yield するのか? 終るのか? は判断できないと思うので、やっぱりそれを判断する為の情報を call/cc の部分か, defile-coroutine の body から送ってもらうなりしないとダメな気がします。 
なのでその部分でスケジューラを意識してしまうと思います。(今回の場合だと、情報をスケジューラに送る代りに call/cc のところでスケジューラ側を直接操作していると解釈しています) 
 
 
試しにメールで返信してみましたが、webのフォームに直接書かないとダメみたいですね。よく考えるとwebのフォームで認証しているのでそういう物な気もしました。 

返事がだいぶん遅くなりすみません。気づいてませんでした。誰も返事出してないですよね? 
 
ご質問のふたつのdefine-coroutineですが、違いがあります。 
returnのあるバージョンは、yieldが呼ばれずにbodyの評価が終了した後でもdequeue!が呼ばれます。returnの無いバージョンだとそうなりません。例えば次のコードで違いが出ます。 
 
(define-coroutine (fn-x yield) 
  (print 'x1) 
  (yield) 
  (print 'x2) 
  (let lp () (yield) (lp))) ; ここでループしているのは、define-coroutineは最低限の実装で、タスクキューが空になるケースを想定していないため。 
 
(define-coroutine (fn-y yield) 
  (print 'y)) 
 
(coroutine-init! fn-y) 
(fn-x) 
 
今回のコードに関しては、return無し版でもbody ... の後に((dequeue! *tasks*)) をつければ同じ動作になると思います。 
 
一応、意図としては ((dequeue! *tasks*)) の部分はタスクスケジューラと考えられるので、それをcall/ccのやりとりの「外側にあるもの」と考えて組むと、本文例のようになります。dequeue!の部分がどう変わろうと、本文のように組まれたcall/cc部分は変えなくてよい、ということです。(ただまあ、enqueue!は呼んじゃってるので、ちょっと抽象化が徹底していないんですが) 
 
完全に抽象化するなら、returnにcontを渡すようにして、 
 
(define (routine) 
  (enqueue! *tasks* (call/cc (lambda (return) ... (return cont)) ... ) 
  ((dequeue! *tasks*))) 
 
とすると、タスク管理を完全に抽象化できるんじゃないかな。(call/ccの内部では、どのような方法でタスクが管理されているかを全く知る必要がない) 
 

19.8 コルーチン で 
  (define-syntax define-coroutine 
    (syntax-rules () 
      [(_ (routine yield) body ...) 
       (define (routine) 
         (call/cc (lambda (return) 
                    (define (yield) 
                      (call/cc (lambda (cont) 
                                 (enqueue! *tasks* cont) 
                                 (return)))) 
                    body ...)) 
         ((dequeue! *tasks*)))])) 
は   
  (define-syntax define-coroutine 
    (syntax-rules () 
      [(_ (routine yield) body ...) 
       (define (routine) 
         (define (yield) 
           (call/cc (lambda (cont) 
                      (enqueue! *tasks* cont) 
                      ((dequeue! *tasks*))))) 
         body ...)])) 
で十分で return は不要だと思いました。 
私が見た限りでは同じ様に動いているのですが何か違いがあるのでしょうか? 
後半の、exit を追加した方も同様です。 

p.461 下から10行目 
誤 : Gaucheh は SLIB 無しでも動作します。 
正 : Gauche は SLIB 無しでも動作します。

321頁 下から2行目 
誤：<generice> 
正：<generic>

239頁 下から8行目 
誤：代表的もののみ 
正：代表的なもののみ

200頁 下から5行目 
「日本語であると」のあとで改行されてしまっているので、 
これを詰める。

196頁 下から3行目 
誤：displayもprintは、 
正：displayもprintも、

193頁 18行目 
「…読み取った文字オブジェクト。初めは3を…」と体言止めに 
なってしまっています。 
 
おそらくここは「…読み取った文字オブジェクト、初めは3を…」 
と読点にするのが自然かと思います。

158頁 14行目 
誤：集合はは有理数の 
正：集合は有理数の

63頁 下から5行目 
誤：Pricipia 
正：Principia

初版 第1刷の正誤表にて、次の通り誤りを見つけました。 
 
誤： 
ページ 
xvi 
誤 
20.10 RDBMを使ったスケジュールデータベース 
正 
20.10 RDBMSを使ったスケジュールデータベース  
 
正： 
ページ 
xvi 
誤 
22.10 RDBMを使ったスケジュールデータベース 
正 
22.10 RDBMSを使ったスケジュールデータベース  

#105,#106を正誤表に反映しました。

P262 最後の行 
 
(when <条件式> <式> ...) 
 
test を評価し、結果が真なら expr を順に評価するのでした。 
 
正しくは 
<条件式> を評価し、結果が真なら <式> を順に評価するのでした。 
 
ではないでしょうか？ 

P216 16.1.2 アクセスと代入 
ベクタの各要の値・・・ 
 
正しくは 
ベクタの各要素の値・・・ 
ではないでしょうか？

>帯に第4部の行がない。 
 
正誤表には載せませんが、 
第3刷で修正お願いします>オライリーどの 

この投稿は削除されています

この投稿は削除されています

帯に第4部の行がない。

http://karetta.jp/book-cover/programming-gauche#H-10urtq8 
#99のうち以下を2刷の正誤表に反映。 
 
64  Churchの学生でだったので  Churchの学生だったので 
243  (define <inherited-list> (<list>) ())  (define-class <inherited-list> (<list>) ()) 
273  名前が衝突しないを作り出す  名前が衝突しない変数を作り出す 
287  breader/ccを使って、  breaker/ccを使って、 
309  *load-path*追加する  *load-path*に追加する 
311  以下に分割されたモジュールfoo.Aとfoo.B、foo.Cがあります(図20-1)。  図20-1のとおりに分割されたモジュールfoo.Aとfoo.B、foo.Cがあります。 
355  Gaucheには大域変数の代わりに使える  Gaucheは大域変数の代わりに使える 
417  それら得ることができます  それらを得ることができます 
463  $ make uninstall  $ sudo make uninstall 
476  /home/bizenn/...  /home/johndoe/...

http://emasaka.blog65.fc2.com/blog-entry-376.html 
 
あとでチェック予定。

#97を2刷の正誤表に反映。 
http://karetta.jp/book-cover/programming-gauche#H-10urtq8 

http://www.lingr.com/room/gauche/archives/2008/03/25#msg-31459426 
> プログラミングGauche P290のfor-each-extが、[の位置が[(syntax-rules () ってなってます 

了解

>これは意図したまま。 
> 
>call/ccは1引数の手続き 
>call/ccの引数もまた1引数の手続き 
> 
>ってことを書いてるつもり。 
 
http://karetta.jp/book-cover/programming-gauche#H-1p3ukk3 
正誤表では、 
 
> call/ccの引数は1引数をとる手続きで、その手続きの引数もまた1引数をとる手続きという仕様になっています 
 
としました。何も指示しなければ、このまま2刷になる予定。 
 

>p.285「call/ccは1引数の手続きで、その手続きもまた1引数の手続きという仕様になっています」は「…手続きで、その引数もまた1引数の…」ではないでしょうか？ 
>もしかしたら、「call/ccの引数は1引数の手続きで、その引数もまた1引数の…」とも 
>思いましたが、図19-1とあわせると前者でしょうか。 
 
これは意図したまま。 
 
call/ccは1引数の手続き 
call/ccの引数もまた1引数の手続き 
 
ってことを書いてるつもり。 

>> あと、これはTheoria氏とちょっと話したんだけど、P295のdefine-coroutineのってtreeでいいのかなぁ。threeじゃないのかなぁ。わざとかなぁ。そういうものなのかなぁ。 
 
すんません。 
ここ最近全然見れてなかったです。 
threeでやんす。

閉じます。 

>今本が手元に無いので確認できないのですが、#65はstring-takeでした？ 
> 
 
stream-takeでした。正誤表を訂正しました。 

#87までを正誤表に反映。 

今本が手元に無いので確認できないのですが、#65はstring-takeでした？ 

>>p.36, gaucheで使用できる空白にフォームフィードがあったほうがいいかも。 
>>Emacsで改ページに使われる文字なので。 
> 
>Schemeのソースコード中でフォームフィードを使うことは稀では? 
>何か実例があったら参考にさせてください。 
 
EmacsでFF(^L)でページ分割できるというのは素の機能なので、 
稀かどうかはその人が好んでつかうかどうかなんじゃないでしょうか？ 
 
一応、使っている例を探してきました。 
http://srfi.schemers.org/srfi-13/srfi-13.scm 

>p.447で列挙されている定義済み高階タグ手続きは、索引では結構（ほぼ？）trailing slash無しで載っていますが、いいのかな？ 
 
ダメです。全部/付きにする必要あり。orz 
 

>p.496, 記法のところにMIT記法や簡略記法(p.78)はなくていい？ 
>（また、上記MIT記法と簡略記法の使い分けは何に基づいている？） 
 
今回は割愛します。 

>p.36, gaucheで使用できる空白にフォームフィードがあったほうがいいかも。 
>Emacsで改ページに使われる文字なので。 
 
Schemeのソースコード中でフォームフィードを使うことは稀では? 
何か実例があったら参考にさせてください。

>皆さま 
> 
>お疲れさまです。時限が来たので、サポートサイト（http://karetta.jp/book-cover/programming-gauche）で公開されているものを、確定したエラータとして、次回増刷（2刷）版に反映したいと思います。 
 
すみません、ちょっと反映が間に合いませんでした。 
 
可能なら#82までを2刷に採用できませんか？

皆さま 
 
お疲れさまです。時限が来たので、サポートサイト（http://karetta.jp/book-cover/programming-gauche）で公開されているものを、確定したエラータとして、次回増刷（2刷）版に反映したいと思います。

p.447で列挙されている定義済み高階タグ手続きは、索引では結構（ほぼ？）trailing slash無しで載っていますが、いいのかな？ 
 

p.487 s/GNU_LIBPATHREAD_VERSION/GNU_LIBPTHREAD_VERSION/ 
 

p.495, www.cgi-testはwww.cgi.test 
p.494, tree-map-{max,min}! は tree-map-{max,min} (!なし)と 
tree-map-pop-{max,min}! (pop-つき) 
 

p.501の延滞リストも遅延リスト？ 
 

p.500, モジュールのところのsplist-atは余計？

p.495, 延滞リスト->遅延リスト？ 
p.496, 記法のところにMIT記法や簡略記法(p.78)はなくていい？ 
（また、上記MIT記法と簡略記法の使い分けは何に基づいている？）

p.491: 
qequal? -> equal? 
rander-content, rander-context, reader-content,  -> render-content 
rander-selector -> render-selector 
rmatch-* -> rxmatch-* 
 
p.431: 
render-context -> render-content 
 

p.490, Norving, Peter は Norvig, Peter 
 

p.488, http-headerはcgi-header 
 

p.487, gosh-program-nameはscheme-program-name

p.484, calendar-body, calendar-head はそれぞれ calendar-body/, calendar-head/.

p.481, s/:if-dose-not-exist/:if-does-not-exist/, s/:persistemt/:persistent/ 
 

そういえば、正誤表、<fsdbm>が<gsdbm>になってます。 
 

p.486, gosh-program-name は scheme-program-name. このページの 
下から３行目にもsmuschemeが。 
 

p.486, delete-slices-of-month は date-slices-of-month 
 

p.494, Unicodeポイントは、Unicodeコードポイント。 
 

p.493, string-? .... 183 はstring=?とマージ 
 

p.493, stread-takeはstream-take 
 

p.492, 「splist-at モジュール」は、「split-at」（sとモジュールがいらない）

p.492, smuscheme ... 465 は cmuscheme のところに merge すべき。 
 

p.492, set-char!は多分set-car! 
 

p.489, 索引でlet-valuesの位置が変。 
 

p.36, gaucheで使用できる空白にフォームフィードがあったほうがいいかも。 
Emacsで改ページに使われる文字なので。

p.33ではgosh -Vの出力に0.8.12とでている。話題はutf-8のほうなので、問題ないとは思いますが、気になるなら。 
 

^のことを、p.63や索引ではカレットと呼んでいるが、p.184ではキャレットと呼んでいる。 
 

#44ですが、索引の修正もお忘れなきよう。 
 

#4, #5は撤回です。正誤表から削除します。 
 
>具体的な修正ポイント: 
> 
>p.443 27.3.1 アプリケーション名、エントリとURL 最後の段落 
>誤: $HOME/work/schedule/schedule/schedule.kahua 
>正: $HOME/work/schedule/src/schedule.kahua 
> 
>p.446 27.3.4 でフォルトエントリの登録 第2段落 
>誤: schedule/schedule.kahua 
>正: src/schedule.kahua 
> 
>なお、Subversionリポジトリに登録済のソースは、「誤」とされ 
>ている構成になっている(執筆当時は正しかった)。これは、正誤 
>表が出た段階で構成を変更したものをコミットする予定。 
> 
 

#44, #45をサンプルコードに反映。 

>>#49までを正誤表に反映。 
> 
>http://tudura.kahua.org/view/006056#45 
> 
>#45についてはまだチェックしてませんでした。 
> 
 
これも反映。25章、27章。

>#49までを正誤表に反映。 
 
http://tudura.kahua.org/view/006056#45 
 
#45についてはまだチェックしてませんでした。 

#49までを正誤表に反映。

>増刷が決定しました。締切を今日中に変更します。 
#了解です。増刷用の赤字は、明日転記し印刷所へ送ります。 
よろしくお願いいたします。

増刷が決定しました。締切を今日中に変更します。

p.403, 上から4/5辺り、「…で囲まれた範囲内で呼び出させるcmd-change-plan手続きや…」は、もしかして、「…呼び出されるcmd-…」? 
 

p.402, 上から4/5辺り、s/make-parametre/make-parameter/ 
 

p.460, ;; No multibyte string というコメントだけが、その上の三つと違って 
ボールドでないのは何か意図があるのでしょうか？

#14が正誤表から抜けていません？

#28に関連して、round->exactあるいは(inexact->exact (round ...))は、 
その後cgiやkahuaアプリケーションの章のdays-of-monthでも使われています。

p.417,418に出てくる、rfc822-header->listですが、 
0.8.13だとrfc822-read-headersのほうがいいでしょうか？

p.457, 最後にまとめてソースを掲載しているなかで、calendar-body/の定義が 
以前にでてくるコードと違っています。

p.76, 8行め、空リストがquoteされてないです。 
 

#40も正誤表に反映。

http://d.hatena.ne.jp/jonathans/20080316#1205687238 
 
> P7（Line12）：「そのなのは無い」→「そんなのは無い」 
>  
> あと、これはTheoria氏とちょっと話したんだけど、P295のdefine-coroutineのってtreeでいいのかなぁ。threeじゃないのかなぁ。わざとかなぁ。そういうものなのかなぁ。 
 

#36～#38を正誤表に反映。

p.408、page手続きで#'"text/html; char-set=utf-8"というstring interpolationが使われていますが、単なる文字列リテラルでもいいと思います。

p.404の上から1/4辺りの、「…、ces-convert手続きに"*JP"オプションを…」の段落は、 
前ページp.403のmain手続きの説明のところに移動したほうがいいと思います（使われているのはそちらだから）。

#19にはs/\(return-value\)s/\1/という指摘も含まれています。 
 

(p.362) 22.10節のタイトルの誤「RDBM」が正「RDBMS」と正誤表にありますが、p.363-369の右上全ての「RDBM」とあるのも「RDBMS」と直しました？

#33も正誤表に反映しました。

p.82 
 
「引数の並び順番」→「並び順／並ぶ順番」 
「キーワード引数を受け取りる」→「受け取る／受け取れる」

Subversionのサンプルプログラムにも#30までを反映。

#30までを正誤表に反映。 
 
http://karetta.jp/book-cover/programming-gauche#H-1p3ukk3 

p.60 
 
引用部分の右マージンが極端に少ない 

p.386 真ん中辺り、s/http-header/cgi-header/ 

p.376 roundでなくround->exactを使う理由が0.8.12対策だとしたら、 
注釈があったほうが親切かもしれません。 

23.7でdays-of-monthを定義するのに、既出のmake-month, first-day-of-month, next-month, date->modified-julian-day を使いますが、 
他の三つは既出であることに明確に言及していますが、first-day-of-month だけはちがったので、多少違和感を感じました。 

p.379最後の例、iotaの第二引数を与えていないので、0からになってます。

p.377上から3/4辺り、「その日の曜日を曜日を得る」になってます。 

p.365でgauche.collectionをuseしておけば結果セットにmap etcが使えるという説明がありますが、p.368で実際に使っているのはgauche.sequenceでした。

p.336/22.10.9でrelation-accessorの説明をしていますが、初出は前ページ/節p.335/22.10.8でした。

p.358,359のwith-dbの定義のインデントが変です（以下二つ目、三つ目は許容範囲かも）。 
- (begin0 以下三行はguardのbodyなのに、guardと同じインデント。 
- :path ... と :rw-mode の行のインデントは、それまでと不整合(e.g., p.354) 
- emacsでインデントしていると仮定して、さらに付録Bの設定を使っているなら、 
　parameterizeの第一引数はもう一段下がっているはず。

p.342の二行目（出力例）、#<undef>がインデントされていますが、 
同じ出力の一番最後と整合性がないです。

p.285「call/ccは1引数の手続きで、その手続きもまた1引数の手続きという仕様になっています」は「…手続きで、その引数もまた1引数の…」ではないでしょうか？ 
もしかしたら、「call/ccの引数は1引数の手続きで、その引数もまた1引数の…」とも 
思いましたが、図19-1とあわせると前者でしょうか。

p.251、上から3/4辺り、「戻り値にreturn-valuesというローカル変数に束縛」は「戻り値「を」「return-value」というローカル変数に束縛」？ 

p.250上から二行目、多分ボールドになってないです。

p.236, 上から3/5辺り、(class-precedence-list <string>)の出力例のとじ括弧がない 
 

p.117真ん中辺り、drink portion'''の'''は何だろう

p.209上から3/5くらいのところ、一カ所だけ、(html:tr (map html:tr ...になってる。

p.224真ん中ちょい下、二行にわたるユーザ入力の二行目がボールドになってない（二カ所あり） 
 

12も正誤表に反映

http://practical-scheme.net/wiliki/wiliki.cgi?harunire#H-1yl2ox5 
 
- tree-walkのworkerが満たすべき条件はなんでしょう 
- tree-walkのwalkerが満たすべき条件はなんでしょう 

10までを正誤表に反映。

http://www.lingr.com/room/gauche/archives/2008/03/13#msg-29986292 
 
p.79 
 
- その唯一の引数(argsのcdr)を返す 
+ その唯一の引数(argsのcar)を返す 

http://d.hatena.ne.jp/znz/20080312/gauche#c 
 
p.121 
-  (set! p 3) 
+ (set! (car p) 3) 

7までを正誤表に反映しました。 
 
http://karetta.jp/book-cover/programming-gauche#H-1p3ukk3 

http://www.lingr.com/room/gauche/archives/2008/03/10#msg-29618613 
http://www.lingr.com/room/gauche/archives/2008/03/10#msg-29618615 
 
p.80コラム内max-numberの定義 
(lambda (a b) (> a b) a b) => (lambda (a b) (if (> a b) a b)) 
 

http://d.hatena.ne.jp/leque/20080308/1205059704 
 
p.18 l.9 
    「真値であることを明示するために #f を返すことが〜」→「#t」 
p.273 l.1 
    「aif に代表ざれる」→「代表される」 

具体的な修正ポイント: 
 
p.443 27.3.1 アプリケーション名、エントリとURL 最後の段落 
誤: $HOME/work/schedule/schedule/schedule.kahua 
正: $HOME/work/schedule/src/schedule.kahua 
 
p.446 27.3.4 でフォルトエントリの登録 第2段落 
誤: schedule/schedule.kahua 
正: src/schedule.kahua 
 
なお、Subversionリポジトリに登録済のソースは、「誤」とされ 
ている構成になっている(執筆当時は正しかった)。これは、正誤 
表が出た段階で構成を変更したものをコミットする予定。 

27章: 
 
kahua-package generate <project> で生成したアプリケーションの 
雛形の、*.kahuaが収められているディレクトリの名前が<project> 
のまま。 
 
ここの仕様はいつだったかに変更されて、<project>ではなく、単に 
src という名前のディレクトリになったのだけど、追随するのを完全 
に忘れていた。 
 
正誤表を作成する際には忘れずに載せること。第2刷の時に直せる 
のかなぁ...

あうあうあう...  
 
ところで、サポートサイト（http://karetta.jp/book-cover/programming-gauche）へのサンプルコードの設置をお願いいたします。

p.362 
 
- 22.10 RDBMを使ったスケジュールデータベース 
+ 22.10 RDBMSを使ったスケジュールデータベース 
 
p.xvi 
 
- 22.10 RDBMを使ったスケジュールデータベース 
+ 22.10 RDBMSを使ったスケジュールデータベース 
 

見本刷が出ました。みんなで校正しましょう。 
 
期限は3/31としておきます。 
 
---- 
p.89 
 
- 再起呼出し 
+ 再帰呼び出し