K.Maebashi's BBS

返事が遅くなりましてすみません。 >本人以外が勝手にやってるなら消した方がいいし、 >たとえ本人がやってる場合も、掲示版spamの一種なので >消した方がいいんじゃないですかね。 > >問い合わせをした方がいいかどうかは迷うところですが。 問い合わせをするのであれば、少なくとも先方がこの書き込みを 確認するまでは削除できないと考えます。 この書き込みは、住所や電話番号なども含まれていますが、 もともと公開情報ですから急いで消さなければいけないものではないでしょう。 というわけで、(しばし迷いましたが)問い合わせメールを出しました。 回答によっては削除いたします。

>なので、まさかご本人がやっているはずはないと思うんですが… >問い合わせメールでも出してみますかね。 本人以外が勝手にやってるなら消した方がいいし、 たとえ本人がやってる場合も、掲示版spamの一種なので 消した方がいいんじゃないですかね。 問い合わせをした方がいいかどうかは迷うところですが。

さて。どうしたものでしょうか。 リンク先を見ると、「山本敏晴」という人は、何冊も本を出してたり、 講演会や写真展などの活動をされている方のようです。 そういう、社会的な立場もある人が、 　「無差別宣伝掲示板書き込み」 という迷惑行為を、実名出してやるとは、ちと私には信じがたいところがあります。 # 少なくとも私にとって、[640]の投稿は、よくあるアダルトサイトなどの広告書き込み # よりも数段不快です。 なので、まさかご本人がやっているはずはないと思うんですが… 問い合わせメールでも出してみますかね。

新刊の紹介です。 カンボジアの写真絵本を出版しました。 題名 「あなたのたいせつなものはなんですか？ 　・・・カンボジアより」 小学館刊 山本敏晴写真・文 定価１５００円プラス税 「あなたのたいせつなものは、なんですか？」 カンボジアの子供達にこの質問をし、 それを絵に描いてもらってきました。 また絵に描いてもらった後に、 必ずその子の家に行き、 その子の住んでいる家の写真、 家族の写真、 その村の風景写真などを撮影させてもらいました。 こうした取材を行っている理由は、 様々な国の様々な文化を紹介し、 世界の多様性を皆様にご覧頂きたいと思っているからです。 絵を描いてもらうだけではなく、 暮らしている様子を取材しているのは、 「これこれこういう社会背景に住んでいる人が、 　こういうものを大切だと思っている・・」 というその流れを理解して頂きたく思うからです。 今回、カンボジアの子供達が描いた「たいせつなもの」は、 多岐にわたっています。 明るい絵、暗い絵、よくわからないもの・・・。 そうした彼らの考え方とその生活している背景をご覧頂き、 様々な国に、様々な考え方の人達がいることを、 まずは見て頂ければ嬉しく思います。 そして、どんなに変わった考え方をしている人達にも、 必ず一緒に暮らしている家族がいて、 大切な友達がいることを知って頂ければ幸いです。 NPO法人　宇宙船地球号 Earth the Spaceship : ETS 事務局長　山本敏晴 108-0014 東京都港区芝5-20-7-504 電話　 03-5443-8969 ファックス 　03-6400-5949 http://www.ets-org.jp

>伊藤と申します。 はじめまして。 >yacc,lex以外にbison,flexというのがあり、 >そっちのほうが新しいと聞いた記憶ありなのですが、 >例の企画では、なぜyacc,lexなんでしょうか？？ bison とflexは、GNUプロジェクトが開発したyacc/lexの互換品ですね。 ですから、「bison/flexではなくyacc/lexを使った」というわけではなく、 基本的にはどちらも同じものです。 実際、crowbarのUNIX版はLinuxに付属していたyacc/lexでmakeしていますが、 Windows版はbison/flexを使用しています(配布しているMakefileを使う場合)。 bison/flexは、(GNUのやることなので当然のように)yacc/lexの上位互換に なっていて、いろいろ機能追加がなされています。しかし、今回の要件では 特に不要なので、それなら低機能なほうに合わせたほうが使える人も増えるのでは、 と考えて、UNIX版はyacc/lexでmakeしているわけです。

伊藤と申します。 yacc,lex以外にbison,flexというのがあり、 そっちのほうが新しいと聞いた記憶ありなのですが、 例の企画では、なぜyacc,lexなんでしょうか？？ 素朴な疑問です(^^

>すみません、そのように実行しても'外部シンボル_mainが未解決'というエラーが出ます。 このエラーメッセージは、その名前の関数なりグローバル変数なりの定義が 見つからないときに出ます。つまりmain関数がないということです。 main関数を書いてない(mainを書いた.cファイルをリンクしていない)か、 mainと書いたつもりでスペルを間違えたとかでしょう。

竹内です。 >はい。まったく問題ありませんので、ご自由にお使いください。 >わかりにくいところ等ありましたら、また掲示板の方にでも書き込んでください。 ありがとうございます。また書き込みさせて頂きます。 >何かと大変な状況かと思いますが、ご活躍を期待しております。 上記リンクにヨルダン日記等も書いておりますので、 お暇な時にでも見てみて下さい。

すみません、そのように実行しても'外部シンボル_mainが未解決'というエラーが出ます。

>エラー_外部シンボル'get_word'が未解決 リンクしていないからでしょう。 BorlandのCコンパイラを使っているのなら、たとえば bcc32 hoge.c とやればhoge.exeという実行形式ができますが、単語の出現頻度のプログラムは、 main.c, get_word.c, initialize.c, add_word.c, dump_word.c, finailze.cを リンクしてひとつの実行形式になります。個別に bcc32 main.c などとやっていれば当然上記のエラーが出ます。 bcc32 -owordmanage main.c get_word.c initialize.c add_word.c dump_word.c finalize.c のように書けば「wordmanage.exe」というひとつの実行形式ができるはずです。

管理人様、スペースお借りします。 C言語ポインタ完全制覇を熟読中ですが、単語の出現頻度を表示するプログラムに関してOSはXP、コンパイラはboland5.5を使っているのですが、本の記載されてる通り実行したところ、エラー_外部シンボル'get_word'が未解決(以下initialize,add_word,dump_word,finalizeも同様のエラーが出ます)というエラーができ実行できません。全く原因が分からないんですがどうかアドバイスをお願いします。

>始めまして。竹内敏彦と申します。 はじめまして。 >私は現在、国際協力機構のシニア海外ボランティアとして >中東の国ヨルダンのアル・フセイン大学(http://www.new.ahu.edu.jo/) >のコンピュータ・エンジニアリング＆IT学部にて学生の面倒を見ています。 遠いところから興味を持っていただきありがとうございます。 それにしてもヨルダンとは。うちのページも(日本語しかないくせに)ずいぶん グローバルになったものだと喜びつつも驚いております。 >とりあえず、HPからダウンロードさせて頂いたドキュメント、ソースコード等を、 >学生の学習参考資料として使わせて頂こうと思っています。 はい。まったく問題ありませんので、ご自由にお使いください。 わかりにくいところ等ありましたら、また掲示板の方にでも書き込んでください。 何かと大変な状況かと思いますが、ご活躍を期待しております。

始めまして。竹内敏彦と申します。 専門的な会話に突然割り込む様で申し訳ないのですが、 メールよりも掲示板へ、という記述がありましたので、 こちらへ投稿させて頂きました。 私は現在、国際協力機構のシニア海外ボランティアとして 中東の国ヨルダンのアル・フセイン大学(http://www.new.ahu.edu.jo/) のコンピュータ・エンジニアリング＆IT学部にて学生の面倒を見ています。 (まだ着任１ヶ月目で、言葉の問題等もあり、実際に教えるところまでは行っていません。) 学生の中に、プログラミング言語が作ってみたいという者がおり、 私自身に知識が無いので、学生に示す具定例があった方が良いと思い WEBで検索していたところ、前橋さんのページにたどり着きました。 crowbarのソースやドキュメントを参考にして、 私自身の勉強も兼ねて学生に紹介したいと思っています。 「プログラミング言語を作る」のページには、断り無く勝手に使って良い との記述がありましたが、念の為、一言お断わりしてからと思った次第です。 とりあえず、HPからダウンロードさせて頂いたドキュメント、ソースコード等を、 学生の学習参考資料として使わせて頂こうと思っています。 アラビア語しか話せない学生が多いので、私の翻訳・説明で どこまで解ってくれるか判りませんが、内容の理解が出来れば それを土台にして、新しい言語を作成出来たら良いな、とも考えております。 (理解するまで行けるかどうかも現時点では不安なのですが．．．。) 唐突にお邪魔して申し訳ありませんでした。では、失礼致します。

>条件の判断を言語の文法として導入せず、アプリケーション側で >判断してもらう場合、上に伝搬させたい例外の throw を忘れやす >そうな気もします。Java に慣れている人だと、finally 節の中 >では普通 throw を行わないので、特に危ないかも。 確かにそうですね。私自身「Java謎+落とし穴～」にそんなことを書いてました。 >欲しい機能のが OR 条件だけなら、catch の後に例外を羅列でき >るような文法にするんですかねえ… ひとまずORがあれば、そのcatch節の中で処理の振り分けはできそうなので (できるように作ればですが)、よさそうな手に思えます。 try { 　… } catch (HogeException, PiyoException: ex) { 　… } とかですかねえ…

> (1)例外の種類の区別を、言語レベルで提供するか、ライブラリ > 　レベルで提供するか、規約レベルの話にするか。 ゼロ除算や、浮動小数点関係のエラーのような例外は、言語処理系 の側で投げて欲しいので、完全にライブラリレベルだけってわけに はいきませんよね。 利用者側で例外の種類を拡張できないようにするのも不便そうだし、 結局、折衷策にせざるをえないような気がします。 > (2)例外の種類別catchを、言語レベルで提供するか、アプリケー > 　ションで判断してもらうか。 > > Javaのように、catchを例外の種類ごとに書く方法だと、OR条件 > (この例外とこの例外の時にはこうする)のようなものが書きにく > くて、なんとかならんもんかと常々思っているのですが… 条件の判断を言語の文法として導入せず、アプリケーション側で 判断してもらう場合、上に伝搬させたい例外の throw を忘れやす そうな気もします。Java に慣れている人だと、finally 節の中 では普通 throw を行わないので、特に危ないかも。 欲しい機能のが OR 条件だけなら、catch の後に例外を羅列でき るような文法にするんですかねえ…

[446] >JDK1.0ベースで記述されているためです。Javaは1.1になったときイベントの扱いが >一新され、古い流儀のプログラムでは、上記の警告が出るようになりました。 [447] >確認ですが、警告が出るだけで、コンパイルは通ってクラスファイルもできていて、 >しかるべきHTMLファイルをつければ動くわけですよね? >うちのWebページをネット上で見たときしか動かない、というわけではなく。 はい。警告が出るだけで、それ以外はすべてOKです。 大変な作業になるのかと思い、提供されるかもしれない修正版と比較しようと思っていましたが、Eclipse 3.1 の力(ちから)を借りて、問題となる部分を書き換えました。 お騒がせしました。 反省: 先ず自分でやれぇー。( 他の初心者は困っていないのだろうか。大きなお世話 ) 反省: 件名の扱いを JavaHouse で知りました。

書き忘れました。 確認ですが、警告が出るだけで、コンパイルは通ってクラスファイルもできていて、 しかるべきHTMLファイルをつければ動くわけですよね? うちのWebページをネット上で見たときしか動かない、というわけではなく。

>"注: Puzzle16Applet.java は推奨されない API を使用またはオーバーライドしています。" これが出るのは、「パズル16」はなにしろ7年も前に書いたものなので、 JDK1.0ベースで記述されているためです。Javaは1.1になったときイベントの扱いが 一新され、古い流儀のプログラムでは、上記の警告が出るようになりました。 >"警告"の出ないソースを提供していただけないでしょうか。 さすがに今更あのプログラムを直す気にはなれませんし、JDK1.0のプログラムと しては「正しい」わけですから、すみませんがこちらで修正版を提供する つもりはありません。ご了承ください。

>Java や C++ の例外の場合、例外の受け手は直接指定せず、受け手が >存在しない場合はトップレベルまで伝搬するわけですが、こういう風に >書くと、それとはだいぶ意味的に違うものになりそうです。 う。確かに私の書いたのだと、トップレベルまで伝搬しませんし、 例外の種類に関わらずcatch節に流れ込みますね。 例外の種類に関わらずcatchに流れ込むことについては、 「自分が知らない例外だったらcatch節で投げ直してよ」という方法で いけそうな気がしますが(ていうかクラス階層という概念がないcrowbarでは、 別途例外階層を定義する手段を提供しない限りそうなってしまいそうですが)、 catch節で例外を投げなおしたときには、上位がさらにtryで囲まれていれば そっちのtryのcatch節に流れ込むように思います(というかそう作らなければ 面白くない)。ただ、catch節で例外を投げなおすためには、上位のtry用の クロージャを持っていなければいけないので、何かと面倒そうではあります。 >また、例外の伝搬を >実装するために、クロージャのリストも管理することになるんじゃ >ないかな… こういうことですかね。 >でも Lisp みたいなマクロがないと、文法的に結構面倒くさそうなので、 >言語レベルで定義しちゃった方が、むしろ好ましいかもしれませんね。 ということで言語レベルで定義しようとせこせこ弄り回しているわけですが、 上に書いたように、crowbarにはクラス階層の概念がないので、どうやって catchしたものか考えているところです。 Common Lispの例外処理は、ちょっとぐぐって以下のページを見つけたのですが、 http://www.geocities.jp/m_hiroi/xyzzy_lisp/abclisp16.html やっぱり階層構造を(おそらくライブラリレベルで)実現していますね。 上に書いたような「なんでもcatchに流れ込むから、あとはアプリケーションで 投げ直してくれ」という戦略をとるにせよ、なんらかの方法で識別がつかないと そもそもアプリケーションでも区別がつきませんから、どうしようかと 考えているところです。 (1)例外の種類の区別を、言語レベルで提供するか、ライブラリレベルで提供するか、 　規約レベルの話にするか。 (2)例外の種類別catchを、言語レベルで提供するか、アプリケーションで 　判断してもらうか。 Javaのように、catchを例外の種類ごとに書く方法だと、OR条件(この例外と この例外の時にはこうする)のようなものが書きにくくて、なんとかならんもんかと 常々思っているのですが…

プログラマなページ -> 超手抜きJavaパズル -> パズル16 のソースを javac Puzzle16Applet.java した処、次のようなメッセージが出ました。 "注: Puzzle16Applet.java は推奨されない API を使用またはオーバーライドしています。" 更に、javac のメッセージを手がかりに詳細を見ると"警告"が三つありました。 "警告"の出ないソースを提供していただけないでしょうか。 ブラウザ上では作動しています。 以上

> こういうtry関数をライブラリで用意することで、アプリケーション側では > こう書けるのかなあ、と。 ははあ、なるほど。 Java や C++ の例外の場合、例外の受け手は直接指定せず、受け手が 存在しない場合はトップレベルまで伝搬するわけですが、こういう風に 書くと、それとはだいぶ意味的に違うものになりそうです。 Java や C++ の例外処理機構と意味的に同じものは、ラベル指定の break 機能と、Lisp で言う unwind-protect (Java の finally) があり、処理系 側がトップレベルで break に使うラベルを何か定義してくれれば、 一応ライブラリレベルで、実装はできるとは思います。 ただ、その場合、例外の種類を表すものはグローバル変数 (あるいは スレッドローカル変数) で保持することになり、また、例外の伝搬を 実装するために、クロージャのリストも管理することになるんじゃ ないかな… 例外の catch は、finally 節内で、例外の種類を保持する グローバル変数を参照するだけで、できそうです。 でも Lisp みたいなマクロがないと、文法的に結構面倒くさそうなので、 言語レベルで定義しちゃった方が、むしろ好ましいかもしれませんね。 > Lispはレキシカルスコープでもクロージャの受け渡しができるわけでしょうか。 > Lispのマクロは、「コードを示すリストをプログラムからいじること」という > レベルでしか理解していないです。throwに相当するシンボルをさくっと > 置き換えればよいのかな。 catch & throw は、throw する先を表すキーとしてシンボルを 使うわけですが、このキーとクロージャの対応を管理する連想 リストは、関数呼びだしのネストに従って、スタック式に管理 します。この連想リストは、言語が提供するものではなく、 ライブラリが内部的に管理する単なるデータ構造に過ぎないので、 レキシカルスコープとは関係ないわけです。

さっそくの返信、ありがとうございます :-) 「回避策」については、動的確保の Board *create_board() {} から調べ直してみます。イメージが index に固執していたようです。 java.util.LinkedList は初めて見ました。APIをちょっと読んでみましたが、分かったような分からないような。色々と実験して、プログラムに取り込もうかと思います。 掲示板の以前の内容もとても参考になります。 つくづく思います。通りすがりにリンクを保存しておいてよかったと。 さっ、きょうも日蝕を仰ぎ見つつお勉強。(Eclipse 3.1) では。 追伸: まだ、朝。早く本屋開かないかなぁー。楽しみ。

>「オブジェクト指向再入門」。なるほどー。そうですか。面白かった。ためになった。 はじめまして。面白く読んでいただけたようで何よりです。 >>※2 もし、board.cの中で「たくさんの盤面」を配列で管理しているのなら、 >>board_create()の戻り値はintかもしれません。 しかし、戻り値をintにしてしまう >>と、いざ盤面の数に制限をなくそうとして malloc()による動的確保に切り替えたと >>き困ります。 逆に、最初から「Boardへのポインタ」にしておけば、 配列で実装し >>ている場合にも困りません。&board[index]を返せばよいからです。 > >ここで、&board[index] の index には何を使うのでしょうか。 >整数(int)を使うと、引用文二行目の int と同じ制限がかかってしまうと思うのですが。 まず、board.cの中で「たくさんの盤面」を配列で管理しているのなら、 おそらく盤面の数には制限ができることでしょう(回避策は後述)。 Cの配列は基本的に固定長だからです。 ただ、その場合でも、board_create()の戻り値をBoard*にしておけば、 将来的にmalloc()による動的確保に切り替えたとき、利用者側に影響を与えなくて 済む、というのが上の注の主旨です。 &board[index]のindexは、board.cが内部的に保持しているだけであり、 アプリケーションには見せません。簡略化して書くとこんな感じです。 static Board board[BOARD_MAX]; static int board_count = 0; Board *create_board() { return &board[board_count++]; } 実際にはfree_board(Board *b)も要るので、そういう場合はポインタ比較しながら ループを回すことになるのでしょう。 昔、SunOS4か何かのfopen()が、10個くらいまではFILEの固定長配列の中から FILE*を返すようになっていたと思います。それ以上オープンするときは動的に 確保するわけです(これが上で書いた「回避策」)。 >質問: 「どのオブジェクトに仕事をさせるのか」の具体例は。 > >連続的に部分拡大をしていく画像(マンデルブロ集合)を表示する JFrame を沢山作っ >ているのですが、或る画像の JFrame にアクセスする場合、配列を使う事しか思い浮 >かびません。( JFrame[] win = new JFrame[100]; // 100: ∞は可 ??? ) 状況がよくわからないのですが、配列を使う方法でも、 「この画像のJFrameにアクセスしたい!」と思ったときには、そのインデックスが わかっていなければいけないわけですよね?] どうせインデックスを保持しなければならないのなら、代わりにJFrameの参照を 保持しても同じことではないのでしょうか。 もし、「すべてのJFrame」をどこかで保持する必要があるのであれば、 java.util.LinkedListなりを使えばよいと思います。 >答えてもらいたいから云うのではないが、「センス・オブ・プログラミング！」と >「Java謎+落とし穴 徹底解明」の目次を技術評論社サイトで見ましたが、とても良さ >そうですね。買うしかないか。また日曜プログラムが遅れる(-L-) や、どうぞよろしくお願いいたします(_o_)

>>try(closure(throw) { >> }, >> closure() { >> }); > >この例はちょっと意味が良く分かりませんでした。 説明不足ですみません。これ全体がJavaでいうところのtry catchになっており、 ライブラリ関数tryの第1引数にtry節、第2引数にcatch節のclosureを渡します。 また、catch節側にも引数が要りますね。 function try(c1, c2) { exception = null; toplevel: { throw = closure(ex) { exception = ex; break toplevel; }; c1(throw); } if (exception != null) { c2(exception); } } こういうtry関数をライブラリで用意することで、アプリケーション側では try(closure(throw) { # try節 }, closure(exception) { # catch節 }); こう書けるのかなあ、と。 >Common Lisp 等にある return/return-from の機能は、もっと >原始的な感じで、むしろ C の setjmp/longjmp に近いレベルに >なります。たとえば、break にラベル指定ができるとすると、 >(Lisp 風じゃなくて crowbar 風に書くと) こういう感じになる >と思います。 … >for (;;) { > toplevel: { > exit_to_toplevel = closure() { break toplevel; }; > command = キー入力; > do_it(command); > } >} breakの機能自体は、同じものを想定していると思っています。 >上のように書くにしても、ユーザーが明示的に closure を変数に >セーブするのではなく、closure は catch & throw マクロに >付随する連想リストの中に隠されて、ユーザの目には見えなくなります。 crowbarで上記try関数を書くとして、もしローカル変数がダイナミックスコープに なっていれば、throwのクロージャを引数で渡さなくてよさそうなんですが、 ダイナミックスコープは混乱しそうなので付ける気はないわけでして、 Lispはレキシカルスコープでもクロージャの受け渡しができるわけでしょうか。 Lispのマクロは、「コードを示すリストをプログラムからいじること」という レベルでしか理解していないです。throwに相当するシンボルをさくっと 置き換えればよいのかな。

「オブジェクト指向再入門」。なるほどー。そうですか。面白かった。ためになった。 疑問点と質問(受け付けてくれるのかな?)です。 疑問点: "オセロを例に考える" の文末。 >※2 もし、board.cの中で「たくさんの盤面」を配列で管理しているのなら、 >board_create()の戻り値はintかもしれません。 しかし、戻り値をintにしてしまう >と、いざ盤面の数に制限をなくそうとして malloc()による動的確保に切り替えたと >き困ります。 逆に、最初から「Boardへのポインタ」にしておけば、 配列で実装し >ている場合にも困りません。&board[index]を返せばよいからです。 ここで、&board[index] の index には何を使うのでしょうか。 整数(int)を使うと、引用文二行目の int と同じ制限がかかってしまうと思うのですが。 "盤面の数に制限をなくそうとして" とありますが、限りなく無限に近く拡張できる index とはどのようなものなのでしょうか。 質問: 「どのオブジェクトに仕事をさせるのか」の具体例は。 連続的に部分拡大をしていく画像(マンデルブロ集合)を表示する JFrame を沢山作っ ているのですが、或る画像の JFrame にアクセスする場合、配列を使う事しか思い浮 かびません。( JFrame[] win = new JFrame[100]; // 100: ∞は可 ??? ) 他に何か方法があれば教えて頂けないでしょうか。 以上 追伸: ( 管理者権限で削除可 ) 答えてもらいたいから云うのではないが、「センス・オブ・プログラミング！」と 「Java謎+落とし穴 徹底解明」の目次を技術評論社サイトで見ましたが、とても良さ そうですね。買うしかないか。また日曜プログラムが遅れる(-L-)

> (Java風に考えれば)こんな感じですかね。 >try(closure(throw) { > }, > closure() { > }); この例はちょっと意味が良く分かりませんでした。 Common Lisp 等にある return/return-from の機能は、もっと 原始的な感じで、むしろ C の setjmp/longjmp に近いレベルに なります。たとえば、break にラベル指定ができるとすると、 (Lisp 風じゃなくて crowbar 風に書くと) こういう感じになる と思います。 exit_to_toplevel = null; function subroutine() { ... 中略 ... if (致命的エラーが起きたら) { exit_to_toplevel(); } ... 中略 ... } function do_it(command) { ... 中略 ... subroutine(); ... 中略 ... } for (;;) { toplevel: { exit_to_toplevel = closure() { break toplevel; }; command = キー入力; do_it(command); } } あるいは、関数名を指定した return (return_from) があれば、 こんな感じです。 function subroutine(do_exit) { ... 中略 ... if (致命的エラーが起きたら) { do_exit(false); } ... 中略 ... return 1234; } function do_it(command) { do_exit = closure(result) { return_from do_it result; }; ... 中略 ... value = subroutine(do_exit); ... 中略 ... return true; } for (;;) { command = キー入力; if (!do_it(command)) { print("error happend\n"); } } もっとも、Lisp でこういうプリミティブなスタイルのプログラミング が良く行われているというわけではないですが… 上のように書くにし ても、ユーザーが明示的に closure を変数にセーブするのではなく、 closure は catch & throw マクロに付随する連想リストの中に隠されて、 ユーザの目には見えなくなります。 また、いまどきは、もっと Java 等に似たスタイルが使われているようです。 http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

>あと、素朴な疑問なんですが、現在 && や || が短絡演算になってない >のは単なる手抜きの結果とのことなんですが、これはやはり将来的には >短絡演算になると期待していていいんでしょうか？ あ、それはすぐできるのでやります。すっかり忘れてました。 >さらに妄想ですが、ラベル指定の break/return 文に関して、字面的に >ネストした内側のクロージャから、外側の関数のラベルを指定して脱出 >できると、ライブラリレベルで Lisp 風の catch & throw が書けて楽 >しいと思います。 なるほど… 勉強になります。 (Java風に考えれば)こんな感じですかね。 try(closure(throw) { }, closure() { }); throwには脱出用のclosureが入っているつもりなんですが、これはやっぱり 引数で渡すことになるんでしょうか? ただまあ例外処理については、今のところふつうの(?) try catch finallyを 付けようかと思ってますけど。

どうもです。はじめまして。 >そのときに 感じたのは PHP の オブジェクト指向は 後付で Ruby に 比べると >美しくないなと。 すみません、私はPHPはPHP4でこの掲示板を書いたぐらいで、 とりわけオブジェクト指向的なところには詳しくないです。 ただ、PHP4の、オブジェクトをデフォルトで値として扱うアプローチは、 変だなあとは思ってました。参照の代入などがどこまで使えるものなのかは 知りません。 >でも PHP も PHP 5 となり　かなり 変わってきたのではないかと 思っています。 ちょっと見てみました。 http://www.atmarkit.co.jp/flinux/special/php5/php5a.html まるっきりJavaなような。 >オブジェクト指向としてみた場合の PHP は Ruby と 比べて どうなんでしょうか。 「○○の方がよりオブジェクト指向的である」という比較に意味があるとは 私は思いません。すべてがメソッドでなくても、関数があったっていいじゃないか、 と思います。 でも、機能ごとに、それぞれがどんな形で実現しているかを比較するのは 面白そうではありますけど。

っと簡単に書きましたが、大域脱出ができるようになると、 Lisp の unwind-protect、Java の finally 節相当の機能が どうしても欲しくなり、さらにその向こうにもっと深い淵が 待ってるような気もしますね。(NaClにはunwind-protect も ありました。)

> 一応つけました。 : > 動いたものを貼っておきます。 素早い… どうもありがとうございます。 あと、素朴な疑問なんですが、現在 && や || が短絡演算になってない のは単なる手抜きの結果とのことなんですが、これはやはり将来的には 短絡演算になると期待していていいんでしょうか？ さらに妄想ですが、ラベル指定の break/return 文に関して、字面的に ネストした内側のクロージャから、外側の関数のラベルを指定して脱出 できると、ライブラリレベルで Lisp 風の catch & throw が書けて楽 しいと思います。(returnするだけのクロージャを作っておいて、必要 な時に呼び出すと大域脱出できる。実際 Common Lisp はそういう言語 規格になってます。っていうか内輪の話になりますが、昔NJSのNaClに 対して、そういうcatch & throw の実装をマクロで書いて遊んでいたの でした。)