Link:

---

webサーバを作ってみようページの以下リンクが切れております。

http://ascii.asciimw.jp/books/support/4-7561-1663-9/supplement/0001/shttpd

Link:

---

>p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、
>ここでcheck_nameという同一のパラメタが複数回登場しています。
>つまり、チェックボックスを複数選択すると、この状況が発生します。
>p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。
>
>
テスト掲示板だけでなく、前の入力フォームにも対応できるよう書かれていたのですね。
サーブレットコンテナを作っているのだから、こういう場合も想定しなければならないのに、
どうも頭が固かったみたいです。

お答えいただき、ありがとうございました。
また何かありましたら、よろしくお願いいたします。

Link:

---

>リスト3-17の21行目でif(paramterMap.containsKey(keyValue[0]))が
>trueになるケースはどんな場合でしょうか？本文P119の中頃に、『同一のパラメタが
>複数存在し得る』とあるのですが、このパラメタとはtittle, handle, messageのことですよね。
>１回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。

p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、
ここでcheck_nameという同一のパラメタが複数回登場しています。
つまり、チェックボックスを複数選択すると、この状況が発生します。
p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。

Link:

---

ご回答いただき、ありがとうございます。

>(試していませんが)param.split("=", -1) とすればよいかと思います。
>
試してみたところ、これでうまくいきました。

投稿内容の取得については、教えていただいた流れを追っていき、やっとわかりました。

stringToMapメソッドについて、まだ理解できていない点があるのですが、
リスト3-17の21行目でif(paramterMap.containsKey(keyValue[0]))が
trueになるケースはどんな場合でしょうか？本文P119の中頃に、『同一のパラメタが
複数存在し得る』とあるのですが、このパラメタとはtittle, handle, messageのことですよね。
１回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。

教えていただければ幸いです。

Link:

---

はじめまして。

>Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名
>・メッセージの内のどこかが
>未入力のままで送信を押すと、リスト3-17のServletServiceの28行目で
>java.lang.ArrayIndexOutOfBoundsExceptionが発生します。
>keyValue[0]に対するkeyValue[1]がない、ということだと思うんですが、
>これはどこかコードを写し間違えているでしょうか？

このケースでは、ServletServiceの20行目の param.split("=") のところで、
split()メソッドの仕様上、「a=」という文字列をparam.split("=")のように
split()すると、
・戻り値の配列の要素数は2で、[0]には「a」が、[1]には空文字が入る
のではなく、
・戻り値の配列の要素数は1で、[0]にだけ「a」が入る
という仕様になっているためですね。
https://docs.oracle.com/javase/jp/6/api/java/lang/String.html#split(java.lang.String)

(試していませんが)param.split("=", -1) とすればよいかと思います。

Henacatはあくまでサンプル実装なので、こういうエラーケース的なものの
対処が甘いのはご容赦ください、と言いたいところですが、これはちょっと
実用上問題がありすぎるので、後ほど正誤表に上げさせていただきます。
ご指摘ありがとうございました。

>あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も
>保持しているという認識で合っているでしょうか？
>しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は
>保持できませんよね？

parameterMapは毎回メソッドが呼ばれるたびにnewしていて、
1回のリクエストごとに使い捨てです。
リスト3-17 ServletService.javaの76行目で、

info.servlet.service(req, resp);

としてサーブレットのservice()メソッドを呼んでいますが、
この呼び出しが、リスト3-26のHttpServlet.javaの13行目のservice()メソッドを
呼び出すことになり、この中で、メソッドがPOSTの場合は(サブクラスの)doPost()
メソッドを呼んでいますから(19行目)、これはつまりリスト3-6のPostBBS.javaの
doPost()メソッドを呼び出しています。
ここで、新たにMessageクラスのインスタンスをnewして、staticフィールドの
messageListにメッセージをつないでいます。

Link:

---

Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名・メッセージの内のどこかが
未入力のままで送信を押すと、リスト3-17のServletServiceの28行目でjava.lang.ArrayIndexOutOfBoundsExceptionが発生します。
keyValue[0]に対するkeyValue[1]がない、ということだと思うんですが、これはどこかコードを写し間違えているでしょうか？

あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も保持しているという認識で
合っているでしょうか？しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は保持できませんよね？

基本的なところかもしれませんが、どなたかわかる方、教えていただけますでしょうか。

Link:

---

>某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、
>長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発
>プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為
>の策が、そのまま生き残ったもの、と聞き及んでいます。

これは…… NullPointerExceptionは避けられるかもしれませんが、
アプリの要件として絶対に値を入れなければいけないところを空文字に
してしまったら、バグの発覚が遅れるだけですよね。
(この手のことは、拙著「センス・オブ・プログラミング!」で
「バグのあるプログラムには生きる価値はない」として書かせていただきました)
要件として、デフォルト空文字列でよいところは、コンストラクタ等で
空文字列で初期化するのは正しいと思いますが。

>「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には
>妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い
>ます（デバッグ鍛錬）。

早合点なら、それでよいのですけれど。実際にメモリをバカ食いしている以上、
どこかに何かの原因があるのかとは思いますが。

>「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、
>貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って
>いるのか増えているのかが、気になるところでございます、Hi。

JavaのGenericsはあれはあれで落とし穴が多いのですが、本1冊書くのは
それはそれは大変なので、当面おとなしくしていたいと思います。Hi。

Link:

---

前橋様

お返事有難うございます。まさかお返事を頂けると思っておりませんでしたので、
ホントに嬉しい限りです。実にショボイ当方の職場のドキュメンタリーは二の次、
先ずは、熱心な貴殿の１ファンの応援メールと受けって頂ければ幸いです。

某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、
長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発
プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為
の策が、そのまま生き残ったもの、と聞き及んでいます。

つまり嫌なのは Javaの言語使用なのではなく、このアホダラ F/W で育ったプログ
ラマーの資質の低下です。

穿った見方と思いますが、アセンブラや C言語で鍛えられたプログラマーは、設計、
仕様、要件をやらしても、モレや矛盾といったバグを仕込むことが少ないと思いま
す。

「ユーザーをバカにするシステムは、良いシステム」という、妙な格言紛いよろし
く、「プログラマーをバカにするプログラミング言語は、良い言語」では困りモノ
です。考えなくて良くなる分、その代わりに、高品質、短納期、斬新なアイデアを
O/P して欲しいものです。

「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には
妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い
ます（デバッグ鍛錬）。

「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、
貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って
いるのか増えているのかが、気になるところでございます、Hi。

Link:

---

はじめまして。すっかり閑古鳥な掲示板ですが、投稿ありがとうございます。

>貴殿の「Java謎＋落とし穴」は私の愛読書で、もう、10年以上も手許に置き、
>休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好き
>です。もう少し余裕ができたら、「 プログラミング言語を作る」を読み込
>んでみたいと思ってます（プログラミング工学の楽しい部分なのですが、
>私にはチとハードルが高い）。

ありがとうございます。「Java謎＋落とし穴」は、さすがに今となっては
内容が古いのですが、Tiger以前の本としては良く書けた本であったと
自分でも自賛しております。

>このクラスのコンバート元である、いわゆるC言語の関数では、いわゆる
>構造体のリストで、その構造体のサイズは80バイト、100万件でも 80MB、
>これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。

100倍以上となると単に言語の違いとするには差が大きすぎますし、
Cだと1回のmalloc()で済むものがJavaだといくつものオブジェクトに
なってしまうというのもありがちですが(たとえばCなら構造体に
intの配列を埋め込んでいたところ、JavaだとArrayList<Integer>を
使ったりすると、あっさり100倍くらいにはなりそうな気がします)、
『某社標準の「フレームワーク」』が問題なのでしょうか。
ものを見ていないので何も言えませんけれども。

>これに対する、若者の回答が問題なのだ。
>　　若者「Null Pointer Exceptionが怖くて、それはできません。」

NullPointerExceptionはバグがあるから起きるので、それ自体を避けたからといって
問題の解決にはなりませんよね(『某社標準の「フレームワーク」』を使うと、
どうNullPointerExceptionを避けられるのかはわかりませんが)。

>「メモリ馬鹿ばか食い」はともかく、「プログラマーの資質（≒誇り）」
>まで低下させる、嫌な言語だ、Java は。

とはいえ、それをJavaという言語のせいにするのもちょっと(Javaに対して)酷なような気が……

Link:

---

貴殿の「Java謎＋落とし穴」は私の愛読書で、もう、10年以上も手許に置き、
休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好き
です。もう少し余裕ができたら、「 プログラミング言語を作る」を読み込
んでみたいと思ってます（プログラミング工学の楽しい部分なのですが、
私にはチとハードルが高い）。

私は、Lattice C からの「C言語使い」です。K&Rにも随分お世話になりま
した。現在、愛知県某社の某基幹システムのリニューアルで、これまで
C言語で実装されていた UNIXサーバーの巨大システムを、Javaにコンバー
トする仕事をしております。

仕事と言いましても、もはや定年までカウントダウンの身、第一線から引
き、「相談役」みたいな立場で食い繋がせて頂いております。

Javaプログラマとしての経験は浅いことを申し添えておきます。

昨日、若者から以下の様な相談をされました。

　　大量データ検証で、あるクラスのアウトプットが、List<データ型>
　　(ArrayList) で、100万件、消費メモリサイズが 10GB で、これでは
　　同時並行稼働すると、後続プロセスの JVMが起動することができなく
　　なる恐れがあります。

該当のサーバーは、今や当たり前の仮想モノで、JVM専用のヒープサイズ
として約30GB割り当てられているのですが、これでは、多分2平行でも、
OutOfMemory となってしまうでしょう。何せ、解析ツールによると、
処理中に GC発生しまくりで、いわばメモリ確保とGCの追っかけっこ、
GCが追い付かない時の最大使用メモリが 20GBに達する、とのこと。

このクラスのコンバート元である、いわゆるC言語の関数では、いわゆる
構造体のリストで、その構造体のサイズは80バイト、100万件でも 80MB、
これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。

このアウトプットの 10GB と 80MB の差という視点に絞ってサクッと考え
ると、Java 側の <データ型> が、bean よりもさらに保安性、利便性？で
ガチガチに固められた、某社標準の「フレームワーク」準拠のスーパーク
ラスをスーパークラスに、このシステムオリジナルの利便性をプラスした
もので、純粋なデータ部分のオーバーヘッドが酷いものと思われる。

これに対し、私は一言、「<データ型>を、せめて bean にしなさい。」と
伝えた。

これに対する、若者の回答が問題なのだ。

　　若者「Null Pointer Exceptionが怖くて、それはできません。」

　　私「…。」

「メモリ馬鹿ばか食い」はともかく、「プログラマーの資質（≒誇り）」
まで低下させる、嫌な言語だ、Java は。

　「プログラマーの資質（≒誇り）」も、C言語と Java とは違う所に
ある様なんですね。

Link:

---

ふぉげちゅうーてゃ？
ｆｏｒｇｅｔ　ｙｏｕ！が語源かも。

Link:

---

>P.280図8-4で、start_x,y,end_x,y,center_x,yと書いているのに、
>P.281図8-5や、P.282図8-6で、start..x,y,end..x,y,center..x,yと、書き変えて？いる。

ご指摘ありがとうございます。遅ればせながら確認しました。
確かに、アンダースコアであるべきところが「..」になっています。
執筆当時のオリジナル原稿を確認しましたがアンダースコアになっていたので
(そりゃ間違えるにしてもこんな間違え方はしないでしょうし)、
書籍用に作図された方にうまく意図が通じなかった&私の確認不足、ということかと
思います。
後日、正誤表に載せさせていただきます。ありがとうございました。

Link:

---

理解度はどうあれ、世間でいうGWが終わったので私も読了です。今後しばらくはこの書籍についてはコメント（というか愚痴）はしません。お付き合いいただき、ありがとうございました。
とりあえず、ほとんどどうでもいいことですが、正誤表に上がっていないので１つ。
P.280図8-4で、start_x,y,end_x,y,center_x,yと書いているのに、
P.281図8-5や、P.282図8-6で、start..x,y,end..x,y,center..x,yと、書き変えて？いる。

それでは。

Link:

---

自己解決しました。 

client_send.txtの最後の空行がエディタAtomによって勝手に削除されていたことが原因でした。 
お騒がせしました。

Link:

---

はじめまして。

現在「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」を勉強中です。

p.54ページのTcpClient.javaを使って存在しないファイルをリクエストするという部分で
404が返ってこず、408のタイムアウトが返ってきてしまいます。

存在するファイルをリクエストしても408が返ってきてしまいます。

これより前は全てうまくいっていたのですが、このタイムアウトはどのような原因が考えられるのでしょうか。

サーバはDocker上でApacheを使用しています。ブラウザだと想定どおりの動きです。

自分で解決することができず、投稿させて頂きました。
よろしくお願いいたします。

Link:

---

回答ありがとうございます。（1か月ぐらいした後に消そうと思っていて、正直回答を期待していなかったので少し驚きました。）

>>p.153のダイナミックスコープの説明でnextから辿る場合、
>>仮に自身と呼び出し元に同じ変数名を定義し、自身内で変数を参照する場合、
>>先に呼び出し元の変数が検知されてしまうので、ダイナミックスコープの動きと
>>違うのでは？
>
>最新のLocalEnvironmentを起点にnextをたどって変数を検索すると、
>先に検知されるのは呼び出し元ではなく自身の方なのでは……?
>一応ver.0.2のeval.cのalloc_local_environmentを確認しましたが、
>新LocalEnvironmentのnextに、その時点でのトップのLocalEnvironmentを
>連結していますし。
>
>635: ret->next = inter->top_environment;
>636: inter->top_environment = ret;
>
>

うーん、コード読んでないのがバレました。（だって人が書いた長いコードをインタビューなしで読むのはしんどいもの。。。）で、nextの音の響きから、左から右、上から下、低層から高層（深層）の方向と想定してました。
だから、「最新のLocalEnvironmentのみから検索しますが、nextをたどって、呼び出し経路すべてのLocalEnvironmentから検索するようにすると、」の記述を、
「「最新のLocalEnvironmentのみから検索しますが、【トップレベルでの（グローバル変数に格納された）LocalEnviromnent型の変数を参照の後】nextをたどって、呼び出し経路すべてのLocalEnvironmentから検索するようにすると、」
と補って読んでいました。
なので、nextの本来の使い道はガベージ判定で、ダイナミックスコープ判定の用途でも使えることを言っているのかな？と類推していました。

ま、この部分の私の理解は大体間違っていましたね。

とりあえず、私の理解不足を棚上げしておいて、別の意味に捉えかねないnextの名前が悪い、っと愚痴っときます。（えぇ暴論ですとも。）

Link:

---

>win_sjisのtest.crbだと、改行にCR(0x0d),LF(0x0a)が入れられていて、
>今使っている処理系（Microsoft Windows Subsystem for Linux上のubuntu）
>では、0x0dを無視してくれず、改行コード\n(=0x0a)に到達する前に不正な文字で
>引っかかっている、

なるほど、crowbar.lでは「\n」だけを改行扱いにしていますから、
UNIX環境下では0x0dは不正な文字として扱われますね。
もともと、Windows(かつてはDOS)にてCでテキストファイルを扱う際、
改行を\r\nとして扱わなければならないのでは既存のUNIXベースの
ソースが軒並み壊滅するので、Windows/DOS環境下では、fopen()とか
fgetc()とかの標準入出力ライブラリのレベルで、\r\nを\nに変換するという
対策を取っています(バイナリファイルを扱いたいときにはfopen()に
"r"の代わりに"rb"を渡す)。「Microsoft Windows Subsystem for Linux上のubuntu」
ではこの動きにならないのは、WindowsではなくLinuxであるためでしょう。

>今の時代趣味でやる分にはsjisもeucも地雷じゃないかなあ？

まあそのあたりは、2009年の本ですので(その当時でもちと古かったのかも
しれませんが)。

>電卓の場合yyparse()で無限ループしているのに、crowbarではyyparse()以降の
>処理に進んでいることは誰も疑問に思わないのかな、

電卓では入力が終わりませんからね。

>p.121 2個目のelse if文の中の処理、
>　left_val.u.double_value=left_val.u.int_value;
>  eval_binary_double(...)


>の部分で、left_val.typeは変えずに(INTのまま)格納する共用体にはdouble値を入れている。
>その後left_valはそのまま使わず、left_val.u.double_valueのみ使っているので
>問題にはならいけど、読んでて不安になる。なぜdouble（専用のというか普通）の
>型のローカル変数を使わないのかな？

ちょっと当時の意図は思い出せませんが、左辺をdoubleに型変換した
感じを出したかったのかもしれません。確かに今見ると、ちょっと意図の
よくわからないコードになっているとは思います。

>p.141の網掛けの以下の記述
>　a={1,2,3};
>  a={2,3,4};
>のあとの図で、aから出ている矢印が{4,5,6}を指している。
>{4,5,6}というのはどこから出てて来た？というか{2,3,4}はどこいった？
>とか、

p.146ですね。誤植のようです。正誤表に載せておきます。
ご指摘ありがとうございました。

>p.145のビットフィールド。別にCのプロフェッショナルを目指す本ではないので、
>ビットフィールドなんて説明が必要な機能なんて使わずにしれっとCRB_Boolean
>使ったり、そのままズバリintを使えばいいじゃない。

これにはたぶん段階のようなものがあって、
(1)unsigned long flagsみたいは変数にフラグを押し込んで、
　自力でビット演算
(2)ビットフィールド
(3)しれっとなんでもCRB_Boolean
当時、実用に供されているCのコードだと、(1)が多かったと思います(ひょっとすると
今でも)。それに比べれば進歩(?)だと思っておいてください。
(本にも「まあ、富豪的プログラミングの感覚からすれば、1ビットのフラグでも、
CRB_Boolean型ひとつ割り当てるべきなのかもしれませんけど。」と書いていますが)

>p.153のダイナミックスコープの説明でnextから辿る場合、
>仮に自身と呼び出し元に同じ変数名を定義し、自身内で変数を参照する場合、
>先に呼び出し元の変数が検知されてしまうので、ダイナミックスコープの動きと
>違うのでは？

最新のLocalEnvironmentを起点にnextをたどって変数を検索すると、
先に検知されるのは呼び出し元ではなく自身の方なのでは……?
一応ver.0.2のeval.cのalloc_local_environmentを確認しましたが、
新LocalEnvironmentのnextに、その時点でのトップのLocalEnvironmentを
連結していますし。

635: ret->next = inter->top_environment;
636: inter->top_environment = ret;


>p.178
>mbstate_をmemset()等でゼロクリアというmbstate_ってどこから出てきた？

文脈からすると「mbstate_t」の誤りのようです。正誤表に載せておきます。


>って感じです。あと、5章UNICODEについては、組み文字以外にデータ内に入っている
>（文字送り方向や字形の変更など）制御コードをどう扱っているのかも書いてあれば
>ななあとも思いました。この辺って、例えば１文字のはずなのにデータは
>100byteとか作れそうで、セキュリティホールになりやすい感じがするので、
>なぜ問題にならないかを聞きたかったかも。

この本のプログラムでは、「mbrtowc()を信頼する」というスタンスですかね……

Link:

---

ゴールデンウィークで読み終えられるかなと思っていたけど全然そうじゃなかった。
やっと、5章まで読み終わった。で、いろいろ愚痴りたい。（今回は投稿にパスワードをつけたので消す準備はバッチリです。）

まずは、環境依存の問題
今週末は一人で0x0d問題にぶち当たり全然読み進められなかった。
test.crbを食わせても以下のメッセージしか出ない。
5:(0x0d)@ 
win_sjisのtest.crbだと、改行にCR(0x0d),LF(0x0a)が入れられていて、
今使っている処理系（Microsoft Windows Subsystem for Linux上のubuntu）
では、0x0dを無視してくれず、改行コード\n(=0x0a)に到達する前に不正な文字で引っかかっている、がubuntuのターミナルは、SJISを解釈してくれず文字化けを起こす。結局が悪いのかがわからない。
今の時代趣味でやる分にはsjisもeucも地雷じゃないかなあ？

で、読む気力がそがれたので、重箱の隅を突っ込みながら（またしても）表面をなぞる程度の読み込みになっちゃった。ちゃんと読めるのはいつのことになるんだか。。。

で、突っ込みはこんな感じ。
電卓の場合yyparse()で無限ループしているのに、crowbarではyyparse()以降の処理に進んでいることは誰も疑問に思わないのかな、
とか

p.121 2個目のelse if文の中の処理、
　left_val.u.double_value=left_val.u.int_value;
  eval_binary_double(...)
の部分で、left_val.typeは変えずに(INTのまま)格納する共用体にはdouble値を入れている。
その後left_valはそのまま使わず、left_val.u.double_valueのみ使っているので問題にはならいけど、読んでて不安になる。なぜdouble（専用のというか普通）の型のローカル変数を使わないのかな？
とか、

p.141の網掛けの以下の記述
　a={1,2,3};
  a={2,3,4};
のあとの図で、aから出ている矢印が{4,5,6}を指している。
{4,5,6}というのはどこから出てて来た？というか{2,3,4}はどこいった？
とか、

p.145のビットフィールド。別にCのプロフェッショナルを目指す本ではないので、ビットフィールドなんて説明が必要な機能なんて使わずにしれっとCRB_Boolean使ったり、そのままズバリintを使えばいいじゃない。
とか、

p.153のダイナミックスコープの説明でnextから辿る場合、
仮に自身と呼び出し元に同じ変数名を定義し、自身内で変数を参照する場合、先に呼び出し元の変数が検知されてしまうので、ダイナミックスコープの動きと違うのでは？
とか、

p.178
mbstate_をmemset()等でゼロクリアというmbstate_ってどこから出てきた？

って感じです。あと、5章UNICODEについては、組み文字以外にデータ内に入っている（文字送り方向や字形の変更など）
制御コードをどう扱っているのかも書いてあればななあとも思いました。この辺って、例えば１文字のはずなのにデータは100byteとか作れそうで、セキュリティホールになりやすい感じがするので、なぜ問題にならないかを聞きたかったかも。

Link:

---

なるほど、わかりました。回答ありがとうございました。
P.39は、正規表現の話だけかと思って（読み返した時に何度も何度も）読み飛ばしていました。この箇所の記述にlexの動きについて書かれていたのですね。失礼しました。
私が誤解していたのは、最初に現れたトークン定義にマッチした場合に、以降のトークン定義を無視するんだろうなぁと思っていたことです。
なので、P.39に記述について+と++のトークンについては、lexの記述では当然に最初に++の定義があってその後に+の定義があるものと思い込んでいました。実際には+と++はマッチする長さが違うのだからlexの記述では、どちらを先に定義しても動きは変わらないのですね。

Link:

---

>疑問に思ったのは「123.456」を「123」を整数型トークン、「.」を例外トークン、
>「456」の整数型トークンと判断する方法や、「1」,「2」「3」「.」「4」「5」「6」を
>全て例外トークンとして扱うこともできそうな気がするのですが、そうならない
>理由がわからないためです。

これは、lexがなぜ「123.456」を実数トークンとして解釈するのかがわからない、
ということでしょうか?
lexは、「最長一致」でトークンを切り出します。つまり「123」や「1」よりも
「123.456」のほうが長いので、「123.456」は実数トークンとして解釈されます。
それについては本の中ではp.39の一番下の段落で説明しています。

>また、整数トークンと実数トークン、"if"トークンと[ \t]トークンの関係から
>推測すると、例えば"for while other if"みたいな命令語もトークンとして
>定義できそうですが、その場合に.lファイルでの定義行（ルール順番）によっては
>動きが変わるものなのでしょうか？

同じところに書いてある通り、lexはまず「最長一致」でトークンを切り出そうとし、
長さが同じなら、より前の規則、つまり.lファイルでの定義行が上のほうである
規則を優先します。

>整数型の場合「....|"0"」と0をダブルクォーテーションで括っていますが、
>電卓のケースでP.36では、「(....|0|([0-9]....)」と0をダブルクォーテーションで
>括っていません。この違いが上の判断条件に影響しているのでしょうか？

これはどちらでも同じですね。なぜ片方だけダブルクォートで囲んだのかは、
すみませんがさすがに思い出せません……

Link:

---

たびたびお邪魔します。
3章途中まで読み進めたのですが、わからないところがあったので教えてください。
P.102のcrowbar.lのソースで、59行目で整数型「([1-9][0-9]*)|"0"」、65行目で実数型「0-9]+\.[0-9]+」、78行目で例外「.」のトークンを切り分けているように見えます。
入力が、「123.456」だった場合、なぜ実数型のトークンと判断されるのでしょうか？
疑問に思ったのは「123.456」を「123」を整数型トークン、「.」を例外トークン、「456」の整数型トークンと判断する方法や、「1」,「2」「3」「.」「4」「5」「6」を全て例外トークンとして扱うこともできそうな気がするのですが、そうならない理由がわからないためです。
（済みません。書籍に記述があるのに私が読み飛ばしてしまっているだけかもしれません。）
また、整数トークンと実数トークン、"if"トークンと[ \t]トークンの関係から推測すると、例えば"for while other if"みたいな命令語もトークンとして定義できそうですが、その場合に.lファイルでの定義行（ルール順番）によっては動きが変わるものなのでしょうか？


整数型の場合「....|"0"」と0をダブルクォーテーションで括っていますが、電卓のケースでP.36では、「(....|0|([0-9]....)」と0をダブルクォーテーションで括っていません。この違いが上の判断条件に影響しているのでしょうか？

Link:https://dictionary.goo.ne.jp/leaf/dialect/3482/m0u/

---

「ほげ」を探すとここにたどりつきました。
「ほげ」は大分の方言で、くだらないこと、でたらめなことの意味です。
（特に臼杵地区、若い人は言わなくなった）

【応用】
ほげほっぽ　　本当にデタラメな
ほげんじょう　くだらないことばっかり

なお、「熊本弁」と書いていた「ほげる」は、穴があいてしまうこと、「ほぐ」は
穴をあけること　であり、別に熊本に限らず、九州全体の共通語です。

Link:

---

回答いただきありがとうございました。

Link:

---

>はじめまして。

はじめまして。読んでいただきありがとうございます。

>1点目：P.56で、エラーリカバリの実現として、mycalc.yファイルの書き換えとして
>lineのルールにerror CRの並びを追加しています。この通りにしてみたもののmycalcの
>動きに変わりはありませんでした。で質問ですが、この修正で意図したエラーリカバリ
>とは、本文直前の文の記述がある、「一度のコンパイルでできるだけ多くのエラーを
>見つけることではないこと」を指しているのでしょうか？つまり何らかの作用により
>yaccが出すメッセージを見やすくする対応のものでしょうか？

この修正は、その直前の記述である「ただ、電卓の場合、対話的に使うものですから、
入力ミスで即座に死んでしまうのはユーザにとって不親切でしょう」という
問題に対する対応です。

>それとも、mycalc.lにもともと実装されている、エラー出力lexical error後の
>exitを消しても、yyclearin;,yyerrok;の作用でError!Error!Error!の
>エラー表示に陥らなくなることを指して、エラーリカバリと呼んでいるのでしょうか？

よって、エラー時にexit()しなくなる、というのが目的です。

>２点目:P.74で、括弧対応の話で、私の環境ではmycalc.yの11行目、
>トークンの並びにLP,RPを追加しなくては動きませんでした。
>こちら11行目に追加することが、筆者の意図とした変更なのかよくわかっていません。

すみません、こちらはこれが私の意図した変更ですが、
p.74で「たったこれだけのことで〜」と書いておきながら他の修正が要るというのは
問題ですね。正誤表に加えておきました。
ご指摘いただき、ありがとうございました。

Link:

---

はじめまして。
「プログラミング言語を作る」の2章まで読んだのですがわからない点が２点ありましたので教えてください。
1点目：P.56で、エラーリカバリの実現として、mycalc.yファイルの書き換えとしてlineのルールにerror CRの並びを追加しています。この通りにしてみたもののmycalcの動きに変わりはありませんでした。で質問ですが、この修正で意図したエラーリカバリとは、本文直前の文の記述がある、「一度のコンパイルでできるだけ多くのエラーを見つけることではないこと」を指しているのでしょうか？つまり何らかの作用によりyaccが出すメッセージを見やすくする対応のものでしょうか？
それとも、mycalc.lにもともと実装されている、エラー出力lexical error後のexitを消しても、yyclearin;,yyerrok;の作用でError!Error!Error!のエラー表示に陥らなくなることを指して、エラーリカバリと呼んでいるのでしょうか？

つづいて、パーサ自作のプログラムは読み飛ばして（＝理解を断念して）

２点目:P.74で、括弧対応の話で、私の環境ではmycalc.yの11行目、トークンの並びにLP,RPを追加しなくては動きませんでした。こちら11行目に追加することが、筆者の意図とした変更なのかよくわかっていません。

Link:

---

>あっ、細かいツッコミに対応いただいてすみません...。
>...ついでにもう1つ。
>更新状況の2行目が「2013/3/13」になってます...。

「プログラミング言語を作る」へのリンクをコピペで流用しようとして
日付を直し忘れたようですね。修正しました。

こちらもご指摘ありがとうございました。

Link:

---

>修正しました。ご指摘ありがとうございました。

あっ、細かいツッコミに対応いただいてすみません...。
...ついでにもう1つ。
更新状況の2行目が「2013/3/13」になってます...。

Link:

---

>「はてなダイアリーをK.Maebashi's はてなブログに移行しました(20017/09/11)」
>
>西暦2万年まではてなブログは存続できるのかな...

私は昔はてなダイアリーにこんなの書いたこともあるのですが。

http://d.hatena.ne.jp/kmaebashi/20100110/p1

今回は自分でやらかしてしまったようです。

修正しました。ご指摘ありがとうございました。

Link:

---

「はてなダイアリーをK.Maebashi's はてなブログに移行しました(20017/09/11)」

西暦2万年まではてなブログは存続できるのかな...