このスレッドの今までの内容
もじもじ |
▲ ■ ▼ |
|---|
| 【No.257】 | randy | 2004年03月31日(水) 22時36分JST-9 【修正】 |
|---|---|---|
[ LZHfA06U/y. ] |
あ〜、なんかスレたてるのは緊張する。。。 =文字は３２ビット= いいですか？ いいんですか？ じゃ、このまま突っ走るということで。(^_^; > ファイルとしてはUTF-8とかShift_JISにしてしまうのでは。 実は（って、こればっか）、SoopyではシフトJIS、EUC-JP、ISO2022-JP の３種類のファイルを区別せずに読み込めます（どのOSでも）。 これがドキュメントに書いてないのは単なる無精。 あ〜、ドキュメント更新しなくちゃ。。。 =Unicode= ウニコードはなんか嫌い。。。包摂って考え方が嫌いなのかなぁ。 異体字に関しては多少考えてることがあるんですが、 文字を表すコードの上位何ビットかを使って、文字のヴァージョン （というか異体字の種類）を表して、下位何ビットかで文字の 種類を表すってのはどうかなぁ。 つまり、 ってな風にしとけば、上位ビットをマスクすることにより 異体字を気にせず検索とか出来るんじゃないかと思うんですが。 誰か、やらないかな。 （なんか説明が変だな。わかります？） > 似て非なる我流のifがでてくるとイヤだなぁ、ってのがありまして。 この気持ちはわかります。 とはいえ、SourceForgeのほうで予告してしまったので、 やっぱりifは予約語からはずすということで。 てなわけで、Soopy0.5.0のWin版とLinux版、公開しました。 native threadを実装したんですが、あまりテストしてないので、 バグがあるかも〜。 あと、print formatとかあると便利かとおもって、文字列にforamtメソッド なぞを追加してみました。 例。 みたいな。 | |
| 【Re:1】 | 成瀬ゆい 【HOME】 | 2004年04月01日(木) 02時16分JST-9 【修正】 | |
|---|---|---|---|
[ GDqzJTJswmI ] |
> あ〜、なんかスレたてるのは緊張する。。。 わかります〜、めんどくさい以上のものがありますよね。 もっとも、この掲示板は1スレッド1ファイルなので、あまりスレッドは多くないほうが効率がよいので、それでよかったり。 > じゃ、このまま突っ走るということで。(^_^; むしろ、売りにしてもよいと思いますよ。 他でも文字は32bitであらわすべきだ、という主張は見ますしね。 > ウニコードはなんか嫌い。。。包摂って考え方が嫌いなのかなぁ。 Unicodeは便利だとは思うのですが・・・、 Unicodeに対応しさえすれば多言語化は完璧、と考える人が多いように感じるのはちょっとね。 そんな甘い話ではないのに。 包摂なんてもともと無理な話、日本語内での包摂すら難しいのに・・・。 > 異体字に関しては多少考えてることがあるんですが、 http://www.horagai.com/www/moji/int/ito.htm にでてくる枝番方式ですよね。 わたしもそれがいいのではないかと思います。 もっとも、文字編纂は個人では難しいので・・・、どうでしょうかねぇ。 TRONコードに対応してやろうという気概を持った大学にもちこんでやればいけるかもしれませんが・・・。 慶応あたりやらないですかねｗ。 > てなわけで、Soopy0.5.0のWin版とLinux版、公開しました。 はいな、Win版をためしてみますね。 print formatもいろいろ限界を攻めてみますか（ぉ | ||
| 【Re:2】 | randy | 2004年04月03日(土) 14時36分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> むしろ、売りにしてもよいと思いますよ。 売りになりますかね？ なるならもっと大々的に宣伝しようかな。。。 > にでてくる枝番方式ですよね。 やっぱり同じようなこと考えてる人はいるものですね。 だけど、そういう方式の文字コードが出てこないのはなぜだろう？ > TRONコードに対応してやろうという気概を持った大学にもちこんでやればいけるかもしれませんが・・・。 > 慶応あたりやらないですかねｗ。 うへ。 成瀬さん、慶応にツテありますか？w 文字コードを個人で作るってのは無理なんですよね。 誰か、ほんとにやらないかなぁ。 | ||
| 【Re:3】 | 成瀬ゆい 【HOME】 | 2004年04月04日(日) 00時37分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
> なるならもっと大々的に宣伝しようかな。。。 大々的には無理かとｗ 文字コード周りに興味持つ人ってあまりいませんからね。 ただ、ぱっと見て見える場所においておくとよいかな、と。 > だけど、そういう方式の文字コードが出てこないのはなぜだろう？ JISが枝番方式じゃないからかな、と。 JISに枝番派の人間を送り込めば・・・ってどうすればいいんだろ。 > 成瀬さん、慶応にツテありますか？w まず、s/対応/対抗/。 で、全くないというわけではないですけれど、文字コード編纂プロジェクトみたいな、 大掛かりなものを立ち上げらげるような人はいませんねぇ。 そうそう、formatって%s,%d,%f,%eしかできないんですね。 他のものにも対応したほうが便利・・・かな。 まだそこまで使うようなケースはありませんけれど。 | ||
| 【Re:4】 | randy | 2004年04月04日(日) 19時30分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> ただ、ぱっと見て見える場所においておくとよいかな、と。 りょうかい〜。 > JISに枝番派の人間を送り込めば・・・ってどうすればいいんだろ。 JISでわたしを雇ってくれないだろうか。。。？ そうそう、枝番方式ですが、ついでに言語コード（日本語とか 中国語とか）も、さらに上位のビットにもたせておきたいかも。 | 言語コード | 枝番 | 文字コード | てな感じで。 そうしておいて、中国の漢字と日本の漢字で形が同じ （とアルファベットの国の人が考えそうな）文字のコードを 一緒にしておいて、それが中国の文字か日本の文字かを 見分けられるようにしておけばいいような。 > 他のものにも対応したほうが便利・・・かな。 これは単に思いつかなかっただけ。 C言語のマニュアルを見る気力もないんです、今は。。。花粉症だから。(^_^; %の種類は、何があればいいでしょうか？ | ||
| 【Re:5】 | 午後の紅茶b | 2004年04月05日(月) 00時04分JST-9 【修正】 | |
|---|---|---|---|
[ rRvmEHBZLrw ] |
漢字は五万とあるからな、、本気でやるなら(誰がやるって言った)16bitぢゃやばい気がする。 | ||
| 【Re:6】 | 成瀬ゆい 【HOME】 | 2004年04月05日(月) 03時50分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
> JISでわたしを雇ってくれないだろうか。。。？ んー、どんなルートからだといけるんでしょうかね・・・？ って、新しく0から文字を集めるのではないのだから、 JISに既に入っている文字を並び替えたり、異体字を追加すればそれでよいのかも。 > そうそう、枝番方式ですが、ついでに言語コード（日本語とか > 中国語とか）も、さらに上位のビットにもたせておきたいかも。 うーん、32bitなのですから、 | 枝番 | 文字コード | 言語コード | でいい気がします。 > %の種類は、何があればいいでしょうか？ http://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=sprintf%A5%D5%A5%A9%A1%BC%A5%DE%A5%C3%A5%C8 に対応すれば十分かと。 とはいえ、実際に必要なのはもっとすくないでしょうけれど。 とりあえず、eをpにしたほうがよさそう、とかですかねぇ・・・。 | ||
| 【Re:7】 | randy | 2004年04月08日(木) 20時54分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> 16bitぢゃやばい気がする。 そうですよね。１６ビットじゃ足りないんです。 > | 枝番 | 文字コード | 言語コード | えーと、なぜ言語コードが最上位なのかというのを思い出しました。 （枝番、文字コード）の組は、漢字圏の文字のみをあらわすのなら 大丈夫だとは思いますが、そのほかの言語で（枝番、文字コード）の組では いまいち表しきれないものもあるんじゃないかと思います。 で、言語コードというか、文字全体の最上位ビットが１の場合は漢字関係、 ０のときには、漢字以外の文字としておくと、文字の最上位ビットが １のときには、（枝番、文字コード）の組をつかった漢字のたぐいを表し、 ０のときには、（枝番、文字コード）以外のルールも 導入出来るようにしたいから、ってことです。 > とりあえず、eをpにしたほうがよさそう、とかですかねぇ・・・。 あう、かぶってましたか。(>_<) これは直さないといけませんね。 しかし、結構種類があるもんですね。 ＜ 勉強不足 いずれ、徐々に足していきましょう。 | ||
| 【Re:8】 | 成瀬ゆい 【HOME】 | 2004年04月09日(金) 03時13分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
んーむ、たしかに、アラビアやインドのあたりの文字は奇怪ですからねぇ。 ハングル文字も複雑ですし。 ってか、なぜか右の方が最上位ビットだと思ってました（ぇ 枝番と文字コードの順番の方はどうなんでしょ。 | ||
| 【Re:9】 | randy | 2004年04月09日(金) 22時53分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> 枝番と文字コードの順番の方はどうなんでしょ。 ｜ 言語コード ｜ 枝番 ｜ 文字コード ｜ の順番がいいかと。 文字コード自体は今のJISを流用するとすると、 上位のほうをマスクするだけで、ビットシフトとか必要なしで、 JIS互換の文字コードが取り出せて幸せかと思います。 | ||
| 【Re:10】 | 成瀬ゆい 【HOME】 | 2004年04月10日(土) 01時58分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
あぁ、やっぱりJIS互換性の都合ですか。 そういえば、UnicodeやTRON以外の、今昔文字鏡のような文字セットは異体字をどうやってるんだろ。。 | ||
| 【Re:11】 | eclipse 【HOME】 | 2004年06月24日(木) 23時34分JST-9 【修正】 | |
|---|---|---|---|
[ 2adF0rWtCng ] |
よしなごとの次スレってここかな。 言語鍛冶MLどうなるか楽しみですね。 成瀬さん、randyさんも入ってきて嬉しいです。 凄いワクワクしてます。 | ||
| 【Re:12】 | 成瀬ゆい 【HOME】 | 2004年06月25日(金) 10時09分JST-9 【修正】 | |
|---|---|---|---|
[ GDqzJTJswmI ] |
えーっと、ここでしたっけ、なんかもう記憶が（弱 まぁ、あるものは使いましょう。 言語鍛治MLどうなるんでしょうね〜、もう30人も集まって。 どんな話が出来るんだろう（どきどき っと、ここをROMっている方で知らない方がいらっしゃるかもしれないので念のため。 http://www.rubyist.net/~matz/?year=2004;month=2Q;category=%B8%C0%B8%EC ＃＃＃ 最近言語学関連で行動し始めてみたり。。。 言語情報関連で生意気なガキがいたらわたしかもしれません（何 しかし、やっぱり文字コードとなると難しいようですね。 | ||
| 【Re:13】 | randy | 2004年06月25日(金) 19時47分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
=言語鍛治ML なんか徐々に人が集まって来てますね。 なにげに、結城先生らしきアドレスとかもあるし、 いや個人的に一番気になるのは森公一郎さんですけどね。 長年kmyacc一筋できた私にとっては、雲の上のお方ですし。 で、そろそろ誰か話題を振らないかなぁ。 いまんところ、入会希望のメールしかないのが残念。 （自分で振る気はないｗ） | ||
| 【Re:14】 | 成瀬ゆい 【HOME】 | 2004年06月26日(土) 00時04分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
50人くらいまでは行きそうですかね。 この人数が多いのか少ないのかはよくわかりませんが。 ＃おそらく日本の言語マニアは大体集まってるの・・・かな？ ＃そうすると少ないような気もしたり もうしばらくは人が集まるのを待って、ということになるのですかね。 一番最初に話を振るのはMatzさんな予感。。 | ||
| 【Re:15】 | randy | 2004年07月03日(土) 22時02分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
そういえば、言語鍛冶MLの過去ログって見れるんでしょうか？ どなたか、知ってます？ FAQな気がして、MLで訊けない小心者なのでした。(^_^; | ||
| 【Re:16】 | 成瀬ゆい 【HOME】 | 2004年07月04日(日) 03時31分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
聞いてみました（ぉ ＃よそうのはずれたなるせ | ||
| 【Re:17】 | eclipse 【HOME】 | 2004年07月04日(日) 10時33分JST-9 【修正】 | |
|---|---|---|---|
| [ rlXyaYg2rMk ] |
確かはじめの方で過去ログのURLが出てたんですが、 OS再インストールでメール消しちゃったのでわからなかくなってしまいました･･･ # 使えねー | ||
| 【Re:18】 | randy | 2004年07月04日(日) 19時31分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> 聞いてみました（ぉ お。わざわざすみませんです〜。 > 確かはじめの方で過去ログのURLが出てたんですが、 ああ。やっぱり出てたんですか。 新規入会者に過去ログのURLがわからないってのは ちとアレですよねぇ。。。（求む改善 ＜ 誰に？） | ||
| 【Re:19】 | 成瀬ゆい 【HOME】 | 2004年07月20日(火) 19時08分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
文字ネタだとここなのかな、 今日の朝日新聞の朝刊2面で人名漢字問題を大きく取り上げていました。 姿勢としては、やはり漢字制限の緩和反対、ですね。 「苺」が追加されたのは森山元法相の地元が苺の名産地だから、ってことまで書いてありました。 なーんか、やっぱり朝日って未だに漢字制限派なんだな〜、と。 ＃もちろん、わたしはアンチ漢字制限派です、念のため | ||
| 【Re:20】 | 成瀬ゆい 【HOME】 | 2004年07月25日(日) 02時47分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
Matzにっきとlangsmithのどちらに書こうか迷った挙句にここに書いてみます（ぉぃ よりカジュアルな、静的型を使える言語、ってのは欲しい言語の一つだったり。 「型をメソッドの集合によって表現する。 」ってのも、アイディアの一つだったんですよね。 細部をまだまだ詰められていないので、だめなんですけどね、 | ||
| 【Re:21】 | randy | 2004年07月25日(日) 09時47分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> よりカジュアルな、静的型を使える言語、ってのは欲しい言語の一つだったり。 いいですね。それ。 欲しい〜。 カジュアルということは、インタープリタとか？ で、インタープリタのくせして、やたら型にうるさくて、 ついでに総称型（Generics）なんかもつけて、Boost::Spritを超える 変態プログラミングが可能に、、、なんて妄想してみる。 「型をメソッドの集合によって表現する。 」ってのは、SMLのシグネチャとかとは 違うものでしょうか？ | ||
| 【Re:22】 | 成瀬ゆい 【HOME】 | 2004年07月25日(日) 19時13分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
カジュアルというのは、言語仕様的に、必ずしも常に厳密さを求めない、という感じですかね。 いや、ちょっと違うかな・・・。 とりあえず、OcamlやHaskellは‘カジュアル’ではない、と思うのですよ。 もっと気楽に僕と型推論しようよ〜、って、これもなんか違う。 インタープリタにするのは一つの方法ですね。 とはいえ、コンパイルできることを否定はしませんけれど。 ＃そんな変態言語がコンパイル可能なものになっているかは定かではないですが > で、インタープリタのくせして、やたら型にうるさくて、 いい加減に書くと、「エラー：キャストは明示的にしてください」が大量に出ます；） というのは冗談にしても、常に変数の型を意識しないといけないようになりますね。 少なくとも、Rubyのような「代入が宣言」なんて甘いことはせず、明示的に宣言させます。 そのときに、型を宣言することまでは必須にしないと思いますが〜。 型推論できなかった時に、自動的にGenericsにするか、エラーにするかは悩む所でしょうか。 そもそも、Genericsでなくマクロを使うって手も・・・（悩 その辺の作りこみはこれから何年かかけて・・・ 「型をメソッドの集合によって表現する。 」というのは、わたしはJavaScriptを意識しています。 if(obj.aMethod) obj.aMethod(); っていう。 結局の所、あるオブジェクトについて、ある一連の操作ができることを保障したいんです。 ＃JavaのinterfaceやRubyのModuleとどこが違うのかよくわかりませんが。 SMLのシグネチャ・・・OCamlのf : int -> intみたいなのとは違いますよね・・・？ すみません、どのようなものかよくわからないです。 あとは、名前空間周りをもっと厳密にやって、ライブラリをきちんと整え、 楽にインストールできるようにして、多言語をPerl並にして・・・（無理 | ||
| 【Re:23】 | randy | 2004年07月25日(日) 22時01分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> とりあえず、OcamlやHaskellは‘カジュアル’ではない、と思うのですよ。 同感。 カジュアルというと、「気軽に書けて、気軽に実行して、 気軽に直せる」っていうイメージですね。わたしは。 > 型推論できなかった時に、自動的にGenericsにするか、エラーにするかは悩む所でしょうか。 わたしも昔、型推論する言語を妄想してみたことがあるんですが、 似たようなところで悩んだ気がします。 オブジェクト指向＆型推論な言語を考えてたんですが、 すべてのオブジェクトがクラスObjectの子孫だとすると、 （脳内で）型推論していくうちに、全部Object型まで さかのぼれてしまってアレレー？ な感じだったんだっけかな。 > SMLのシグネチャ・・・OCamlのf : int -> intみたいなのとは違いますよね・・・？ えーと、それを集めたものというか。 ↓こんな感じ。（「プログラミング言語ML」Jeffrey D.Ullman著 から抜粋） OCamlがわかればだいたい見てわかると思います。 で、シグネチャは単なる型なので実体をつくることは出来ません。 のように構造体を表す型として指定するわけです。 まあ、一言で言えば、JavaのInterfaceみたいなもんです。 > あとは、名前空間周りをもっと厳密にやって、ライブラリをきちんと整え、 .NETに対応してライブラリは.NETまかせとかｗ （M$は嫌いなんですけどね。^^;) | ||
| 【Re:24】 | 成瀬ゆい 【HOME】 | 2004年07月26日(月) 05時05分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
> カジュアルというと、「気軽に書けて、気軽に実行して、 > 気軽に直せる」っていうイメージですね。わたしは。 そうそう、そんな感じです。 あとは、直感を裏切らない、というのも大切ですかね。 > すべてのオブジェクトがクラスObjectの子孫だとすると、 > （脳内で）型推論していくうちに、全部Object型まで > さかのぼれてしまってアレレー？ な感じだったんだっけかな。 あぁ、型推論の世界では、Genericsなんて考えなくても、Objectでいいんですね。 っと、ふと、任意のオブジェクトに対して、唯一の‘型’割り振る必要ってあるんですかね。 型を全廃して、signature/interfaceだけでやっていけるような気も。 いや、今思いついたので、全く詰めてませんけれど。 思いついた限りでは、例えば、 def a = 1; というとき、オブジェクトaはIStringとIInteger、IFloat、IRational、INumericなどなどを持っていて〜 以下次号（何 > SMLのsignature ふむ。 なんか、クラスの雛形って雰囲気ですね。 確かに、一つの‘型’はだいたいそんな感じです。 で、一つのオブジェクトに対し、複数の‘型’が自動的に適用される、と。 > .NETに対応してライブラリは.NETまかせとかｗ それも一つの解ですよね。 ぱっと見インタプリタ言語と見せかけて、実は裏で毎回コンパイルしている〜 なんてのも営業的見地から見たらありかな、とは思っていたりします。 | ||
| 【Re:25】 | eclipse 【HOME】 | 2004年07月26日(月) 20時02分JST-9 【修正】 | |
|---|---|---|---|
| [ rlXyaYg2rMk ] |
シグネチャってインターフェースとどう違うのかわからないんですが、 どっちにしろある型を別の型で定義することになりますよね。 メソッドの集合によって定義する型ってのは一般的なクラスとはどう違うのでしょうか。 型と命題は同じだとかどっかで見たんですが、Curry-Howardの同型対応って言うんでしょうか。 凄くわかりたいけどわからない世界。 意味論は面白･･･そう。 >ふと、任意のオブジェクトに対して、唯一の‘型’割り振る必要ってあるんですかね。 >型を全廃して、signature/interfaceだけでやっていけるような気も。 signature/interfaceと型の違いって、 一つのオブジェクトに対して複数対応付けられるか否かという認識で良いでしょうか。 「必要」というより、 型なしと型ありの間に妥協点としてsignature/interfaceがあるだけだと思います。 あと私はコンパイラが作れればインタープリタも作れると思っていますが間違ってます？ インタープリタ→コンパイラは難しいけど、 コンパイラ→インタープリタは簡単だということ。 | ||
| 【Re:26】 | randy | 2004年07月26日(月) 21時20分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> あとは、直感を裏切らない、というのも大切ですかね。 確かに。 他人が書いたperlのソースなんて、直感じゃ何もわからん。(-_-; > def a = 1; > というとき、オブジェクトaはIStringとIInteger、IFloat、IRational、INumericなどなどを持っていて〜 IStringも持つんだ。。。って話はおいといて。 これって継承関係があればいいのでは。 INumericを親として、IInteger, IFloat, IRational はその子供。 とすれば、aの型はINumericってことで済みそうな。 > シグネチャってインターフェースとどう違うのかわからないんですが、 うーん。実はわたしもよくわかりません。 同じと考えてもいいような気も。 > どっちにしろある型を別の型で定義することになりますよね。 > メソッドの集合によって定義する型ってのは一般的なクラスとはどう違うのでしょうか。 えーと。現在議論している話のなかでは、クラスは「型」ではない ことになるのかな。（別の意味では、勿論「型」と呼べると思いますが。） まず、クラスの「型」とはなにか、から考えてみます。 ここでは、クラスの「型」とは、そのクラスを特徴づける性質 ということにしておくか。。。（適当） たとえば、そのクラスは「valueという名前のint型の変数を持つ」とか、 「int型をとってint型を返すメソッドhogeを持つ」とか、そういうの。 実際に書くとこんな感じ↓。（疑似言語） で、この型を持つクラスは↓。 あるいは、これも↓ ってな感じ。 なので、 > signature/interfaceと型の違いって、 signature/interfaceはあくまで型であって、 > 一つのオブジェクトに対して複数対応付けられるか否かという認識で良いでしょうか。 というよりは、 継承関係にない別々のクラスにも、一つの型（signature/interface）を対応づけられる。 ということかと。 で、クラスにわざわざ型（signature/interface）を対応づけて 何が嬉しいのかっていうと、たとえば上記の例で言えば、 IHoge型を持つクラスならどれでも、関数hogeを 持つことが保証されているとか、そういうことかな。（たぶん） ＃自分でも何書いてるのかわかんなくなってきたぞ。。。(-_-; 蛇足ですが、C#だとスーパークラスもインターフェースも 同じ構文で指定するので、クラスとインターフェースの意味の差が 理解できないで一生を終える人が増えてしまいそうな予感。 （javaだとextendsとimplementsで分けてるから、まだマシなんだけど。） C#での例。 こんな構文だと「スーパークラスとインターフェースって 何が違うんじゃぁ！ 似たようなもの、作るな！」とか 思われてしまいそう。。。 > あと私はコンパイラが作れればインタープリタも作れると思っていますが間違ってます？ > インタープリタ→コンパイラは難しいけど、 > コンパイラ→インタープリタは簡単だということ。 間違ってはないような気がする。。。 インタープリタもコンパイラもフロントエンドの考え方は一緒。 内部コードも同じでOKでしょう。 違いはバックエンドで、インタープリタだと内部コードを実行するし、 コンパイラだと他の言語（アセンブリ）とかに変換しちゃう、 というところが違うわけですが、、、、まあ、バックエンドには あまり共通性がない気はします。 しかしながら、内部コードを実行しちゃうほうが、 変換するよりは技術的に簡単な（あくまで比較の問題）気がするので、 コンパイラのバックエンドを作るぐらいのレベルであれば、 インタープリタのバックエンドは作れるだろうと思われます。 | ||
| 【Re:27】 | 午後の紅茶b | 2004年07月27日(火) 00時07分JST-9 【修正】 | |
|---|---|---|---|
| [ rRvmEHBZLrw ] |
インタープリタなPerlなんかあると良いかも? | ||
| 【Re:28】 | 成瀬ゆい 【HOME】 | 2004年07月27日(火) 08時25分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
> メソッドの集合によって定義する型ってのは一般的なクラスとはどう違うのでしょうか。 あるオブジェクトについて、一般的な「型」やクラスは、その振る舞いの全てを規定します。 ＃特異メソッドとかは除いて それに対して、メソッドの集合によって定義する‘型’は、あるオブジェクトに対して、 ある一連の操作が可能な事を保障します。 この場合、その操作をした場合の振る舞いまでは、一般にはは規定していません。 Moduleは実装を伴っていますが、interfaceやsignatureは実装は伴いませんね。 > 型と命題は同じだとかどっかで見たんですが、Curry-Howardの同型対応って言うんでしょうか。 うーむ、わからないです。 でも、なんとなく面白そうな雰囲気はありますね。 > signature/interfaceと型の違いって、 > 一つのオブジェクトに対して複数対応付けられるか否かという認識で良いでしょうか。 いえ、「型」はオブジェクトの全てを決めるもの、 signature/interfaceはある特徴を決めるもの、ですね。 型は一つだけれど、signature/interfaceは複数になりうる、というのは、これに由来するものです。 > 「必要」というより、 > 型なしと型ありの間に妥協点としてsignature/interfaceがあるだけだと思います。 いえ、「型」とsignature/interfaceは本質的には別のものです、たぶん。 実用上は一方をもう片方で代用することが出来ますけれども。 > あと私はコンパイラが作れればインタープリタも作れると思っていますが間違ってます？ ラッパー言語のようなものですと、インタープリタを作るのは難しい・・・かも？ それでも、インタープリタからよりは楽でしょうけれども。 > これって継承関係があればいいのでは。 それはもちろんです。 あえて列挙したのは、a.hasInterface(IInteger)もa.hasInterface(INumeric)も、みんなtrueになる〜、 ってことを強調したかったからですね。 IStringを入れてみたのは、暗黙の型変換の話なのですが、ちょっと迷い始めたので保留、と。 > えーと。現在議論している話のなかでは、クラスは「型」ではない > ことになるのかな。（別の意味では、勿論「型」と呼べると思いますが。） インスタンスからみると、やはりクラスは「型」でしょう。 クラスの一部分が「型」で、その「型」の部分集合がメソッドの集合による‘型’ですかね。 randyさんの例の場合、 IHogeは「型」でなく、「型」の部分集合かと。 hoge = new Hoge;したとき、hogeの「型」がHoge、 foo = new Foo;したとき、fooの「型」がFooでしょう。 > IHoge型を持つクラスならどれでも、関数hogeを > 持つことが保証されているとか、そういうことかな。（たぶん） ある特定のメソッドがあるかどうかよりも、ある一連の操作が出来るかどうか、が重要に感じます。 ICloneableやICollectionあたりがその好例でしょうか。 > 蛇足ですが、C#だとスーパークラスもインターフェースも > 同じ構文で指定するので、クラスとインターフェースの意味の差が > 理解できないで一生を終える人が増えてしまいそうな予感。 スーパークラスとインターフェイスは同じものだ〜と主張しているのですかね？ langsmithでも多重継承の話が出ていましたが、 多重継承の複雑さを解消するために、スーパークラスとインターフェイスに分けたのだったら、 それらを使うときにはあえて区別する必要もないわけですし。 とはいえ、単に区別するのが面倒だったから、という可能性もありますが・・・。 Perlって今もインタプリタじゃないですか？ Perlのコンパイラは一応存在したような記憶が・・・ | ||
| 【Re:29】 | eclipse 【HOME】 | 2004年07月27日(火) 21時13分JST-9 【修正】 | |
|---|---|---|---|
| [ rlXyaYg2rMk ] |
>>randyさん >たとえば、そのクラスは「valueという名前のint型の変数を持つ」とか、 >「int型をとってint型を返すメソッドhogeを持つ」とか、そういうの。 型=シグネチャであって型!=クラスであると。 では、 interface A { int value; } interface B { int value; } このAとBという2つの型は同じ型でしょうか？ 型は型の実体だけでなく名前も識別対象になるのか、ということです。 なる言語もあればならない言語もある、 というとしたらそれは「型」の意味が言語によって変わるからであって、 クラス!=型であると断言できるなら、どちらかに定義されるかと思います。 > 理解できないで一生を終える人が増えてしまいそうな予感。 オーバーライドしないと警告されるから気付くと思いますよ。 個人的にはC#の文法の方がシンプルで好きです。 OO初めてな人にはJavaに比べて教えにくい部分が多いですが。 > しかしながら、内部コードを実行しちゃうほうが、 > 変換するよりは技術的に簡単な（あくまで比較の問題）気がするので、 比較の問題ですか… その変換が素人考えではかなり難しそうに思いますけど。 もちろんその手前までの道のりも大変なのは百も承知です。 >>成瀬さん > > メソッドの集合によって定義する型ってのは一般的なクラスとはどう違うのでしょうか。 > あるオブジェクトについて、一般的な「型」やクラスは、その振る舞いの全てを規定します。 > それに対して、メソッドの集合によって定義する‘型’は、あるオブジェクトに対して、 メソッドの集合と言ってしまうと実装を伴うものと想像してしまいます。 C#でいうデリゲートの集合になりますかね。 それはつまりインターフェースですよね。 > いえ、「型」とsignature/interfaceは本質的には別のものです、たぶん。 > 実用上は一方をもう片方で代用することが出来ますけれども。 「本質」とはなんでしょうか？ 私はオブジェクトに束縛を与えることによって何らかの益を得るための手段、 という意味において同じベクトル上のものと捉えているのですが。 > あと私はコンパイラが作れればインタープリタも作れると思っていますが間違ってます？ > ラッパー言語のようなものですと、インタープリタを作るのは難しい・・・かも？ すみません、ラッパー言語とはどういったものでしょうか。 できれば具体例お願いします。 > インスタンスからみると、やはりクラスは「型」でしょう。 > クラスの一部分が「型」で、その「型」の部分集合がメソッドの集合による‘型’ですかね。 型はインスタンスに一つだけ対応するものであって、 インスタンスの持つ全ての「フィールドの殻」と「メソッドの殻」の集合ということになりますかね。 randyさんへのレスにも書きましたがそこに型自身の名前は含まれると考えますか？ > スーパークラスとインターフェイスは同じものだ〜と主張しているのですかね？ まさか… 細かい文法はC++に倣っただけでしょう。 Javaのように予約語増やすよりは良いとの判断かと。 > 多重継承の複雑さを解消するために、スーパークラスとインターフェイスに分けたのだったら、 > それらを使うときにはあえて区別する必要もないわけですし。 むしろ利用方法を区別するために多重継承を消してインターフェースにしたのでは？ 実装の継承とインターフェースの継承ってやつですね。 区別する必要なかったら多重継承だけでいいでしょう。 > Perlって今もインタプリタじゃないですか？ ですね。 スクリプト言語と名乗るものは大体インタープリタでしょうね。 | ||
| 【Re:30】 | 成瀬ゆい 【HOME】 | 2004年07月28日(水) 03時05分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
> メソッドの集合と言ってしまうと実装を伴うものと想像してしまいます。 > C#でいうデリゲートの集合になりますかね。 > それはつまりインターフェースですよね。 「メソッドの集合」が実装を伴うか否か、 つまり、C#やJavaのinterfaceのことか、RubyのModuleのことか、というのは迷う所です。 ってか、迷っていて、まだ決めていません。 interfaceのようなものになりますね、delegateとは違うかと思います。 ただ、わたしが考えているものはJava/C#のinterfaceとは、また少し違うかも。 a = 3; のときのaの持つ‘型’の話でもそうなのですが、うちのは継承が起きるのです。 > 「本質」とはなんでしょうか？ その概念がでてくる由来・・・かな。 「型」に求められるものと、interfaceに求められるものは別のものです。 とはいえ、実際問題として、同じベクトル上のものであることは確かです。 interfaceは「型」の部分集合になります。 > すみません、ラッパー言語とはどういったものでしょうか。 たとえば、HTMLのラッパ言語である、RDやWiki文法のようなものです。 プログラミング言語の例が思いつかなかったので、いまいちな例で申し訳ないですが＾＾；； > 型はインスタンスに一つだけ対応するものであって、 > インスタンスの持つ全ての「フィールドの殻」と「メソッドの殻」の集合ということになりますかね。 そういうことです。 また、「型」は実装を伴います。 ＃と、言ってしまって問題ない・・・と思う > randyさんへのレスにも書きましたがそこに型自身の名前は含まれると考えますか？ クラスと近似される「型」は名前は含まれないと考えます。 しかし、interfaceと近似される‘型’には名前は含まれるでしょう。 ＃含まれない場合も考えられますが、その場合は名前の衝突が起きるように感じます。 このへんは、 a = 3; のとき、aは、a.IString.plusやa.IInteger.plusを持っていて・・・という話でしょうか。 同じplusメソッドを持っているものの、意味づけが大きく異なる以上区別されるべきで、 その区別は‘型’の名前によって成されるであろう、という考えからですね。 代替手段がある場合、この話は吹き飛びます＾＾；； > むしろ利用方法を区別するために多重継承を消してインターフェースにしたのでは？ それもあるかとは思います。 けれど、Rubyの例もあるので、実装の継承とインターフェイスの継承の分離は必須とは言えないかと。 クラス/「型」の部分集合を表したい時は、クラス/「型」の多重継承でなく、 interface/‘型’を使いましょう、ってことではないかなぁ。 | ||
| 【Re:31】 | randy | 2004年07月28日(水) 21時15分JST-9 【修正】 | |
|---|---|---|---|
| [ LZHfA06U/y. ] |
> あえて列挙したのは、a.hasInterface(IInteger)もa.hasInterface(INumeric)も、みんなtrueになる〜、 > ってことを強調したかったからですね。 なるほど。了解です。 > インスタンスからみると、やはりクラスは「型」でしょう。 > クラスの一部分が「型」で、その「型」の部分集合がメソッドの集合による‘型’ですかね。 えーと。どうもうまく説明出来ないなぁ。。。 わたしが今語っている考え方（これが絶対的な考えというわけではない）では、 １．インスタンスの「型」はクラスである。 ２．クラスの「型」はsignature/interfaceである。 というイメージなわけですよ。 この考え方に意味があるかどうかは別問題。(^_^; （あれ？ 前に書いたのでは「クラスは型ではない」とか言ってるなぁ。＞自分） > interface A { int value; } > interface B { int value; } > このAとBという2つの型は同じ型でしょうか？ これは、、、、言語の設計次第かと。 同じとする言語も作れるだろうし、違うとする言語も有りでしょうね。 > 比較の問題ですか… > その変換が素人考えではかなり難しそうに思いますけど。 変換は面倒ですよね。 現在どういうわけかトランスレータを書いてたりするんですが、 元言語->目的言語の変換はやはり面倒です。 =多重継承 langsmithで出てる多重継承の話題ってなかなかレスがつきませんね。 クラスの多重継承のほうが、インターフェースの多重継承よりも 実装は難しいはずなんだけどなぁ。。。 なんで、誰もレスしないの？ 実はレスしようかと思ってるんだけど、説明を考えてみると 結構面倒くさいし、自分もよくわかってるわけじゃないから どうしようかなぁ、、、と悩んでたり。 結局、クラスの多重継承をすると、メンバ関数を呼ぶ出すときに 場合によっては、thisポインタのオフセットを計算してから メンバ関数に渡す必要があるとか、そういう問題じゃなかったでしたっけ？ | ||
| 【Re:32】 | 成瀬ゆい 【HOME】 | 2004年07月29日(木) 22時20分JST-9 【修正】 | |
|---|---|---|---|
| [ GDqzJTJswmI ] |
> １．インスタンスの「型」はクラスである。 あえて指摘する意味があるのかは疑問なのですが、念のため、 インスタンスの「型」＝クラス ではないですよ。 少なくとも、クラスメソッドは、インスタンスの「型」とは関係のないものでしょうから。 > ２．クラスの「型」はsignature/interfaceである。 インスタンスの「型」と、クラスの‘型’は、位置づけが結構違いますよね。 クラスの‘型’は複数存在するというのが一例だと思うのですが。 で、思ったのですが、今まではクラスベースで考えていましたけれど、 プロトタイプベースにしたら、この辺は悩む必要がないかな。 obj = Object.clone obj.include superclass obj.include module1 obj.include module2 obj.ownmethod = func{ print "hoge" } のような感じで。 ＃ここでmoduleとは、実装を伴ったinterfaceです > langsmithで出てる多重継承の話題ってなかなかレスがつきませんね。 クロージャの話もそうだったのですが、多重継承も、ちょっとうちの限界を超えてます＾＾；； 前に見た限りでは、多重継承をするとダイヤモンド継承をしたときのメソッドの衝突が面倒だとかは聞きましたが・・・、 | ||