top recent

プログラミング言語

関連ページ

プログラミング言語:高階関数 プログラミング言語:Lisp プログラミング言語:Haskell プログラミング言語:スクリプト系 プログラミング プログラミング言語:URLメモ プログラミング言語:文法談義 プログラミング言語:FPsystem プログラミング言語:高階関数:談話室 プログラミング言語:糊

目次

  1. その他の関連ページ...
  2. 自由変数を持つ関数...
  3. メソッド名とかに曖昧な名を許す言語...
  4. Smalltalkは子供向けじゃなくて子供から大人までオススメです...
  5. Cocoaはやっぱり!...
  6. RubyCocoa@SsPuki...
  7. 全てのInstanceをメモリ上の1つの巨大データ(?)として持つ実装...
  8. 無礼講言語...
  9. 継続とObjectと掲示板とWikiと...
  10. Prograph...
  11. データ駆動型のプログラム実行(data flow graph)...
  12. インタプリタのインスタンスを複数作ろう!(笑)...
  13. PostScriptとLispのいいとこどりしてみよう...
  14. 言語の語順による「不気味さ」をいかに除くか...
  15. 言語を開発(試作)するエンジンまたはフレームワーク...
  16. パーサーだけが言語のありようを決するわけでもないんで...
  17. List Comprehension...
  18. StackじゃなくFIFOでやっちゃう、あれ系言語？...
  19. このDAOはいつか来たDAO...
  20. msekiya:Eiffel...
  21. RubyとHaskellの語順の比較...
  22. プログラミング言語のモジュラリティ...
  23. Programming Language Design and Implementation...
  24. グラフィカルな配線型言語...
  25. いままで見聞きしてきた...
  26. いままで見聞きしてきた (#25)ってFPゆかりのものが9割を占めてますね。...
  27. プログラミング言語:哭きのC言語...
  28. データもプログラムもハッシュであるような言語...
  29. 名と体の逆転現象...
  30. Algol N...
  31. プログラミング言語:C++:スマートポインタ...
  32. 十進BASIC...
  33. jython...

その他の関連ページ

プログラミング:企画もの
OOP
FP
Java
Delphi
Smalltalk
PHP
Ruby

[[id:1098]] 2002-09-02 12:16:54

自由変数を持つ関数

コンパイラ演習レジュメ (プログラミング言語:URLメモ) の「2.仕様説明」
http://www.is.s.u-tokyo.ac.jp/~vu/jugyo/processor/process/soft/compilerresume/coverq2/coverq2.html
に書かれている概念。

Cの関数内static変数は、そのインスタンスが(変数1つあたり)プロセス中に1つづつしか存在しないが、
自由変数のほうは(文法のサポートが有れば)なんぼでも"作って保持(保存)しとける"もの
#という理解で良いですか？>識者
- 自由変数 (λ算法)をご参照ください
BASICを捨ててCに移って少しして、まず非autoな変数の必要性を感じて、次にstatic変数が
auto変数の限界を一部解消してくれるものの別の問題も導入してしまう困った存在であることに気づき、
戯は、OOP(変数を外出しにすることでこの問題を解決する)マンセー方角に走ったわけだが、
別の方角として、変数つきの関数のインスタンス(だよね?)を好きなだけ作る、という世界観も
有った、ということか。
ああ。もっと早くLispとかに遭っていれば、人生は変わっただろうなあ…(よしあしはさておき)

signature: 戯

[[id:574]] 2002-06-24 18:19:55

メソッド名とかに曖昧な名を許す言語

てゆーか、たとえばメソッド名として「正規表現」を許す言語

…なんてのが欲しいねー、と言っていたのはCUE氏だったかな(^^;

Rubyみたいな言語でも(method_missingを使えば)同等機能は実現できるが、
ソース字面は一体感が無いよね。ん？Schemeなら平気なのか？(^^;

で、いずれにせよこれを実現しないことには、Integerに、Integerな名前のMessageを送信すると、Floatな値が返される。 (プログラミング言語:文法談義) みたいなことは(簡単には)出来ないんだよねえ…
signature: 戯

[[id:626]] 2002-06-02 16:52:01

Smalltalkは子供向けじゃなくて子供から大人までオススメです

Re: 簡潔さは力なり (プログラミング言語:URLメモ)
>それを論拠とすると、難しいものは要らない、という需要には対応できない。
>Smalltalkが子供向けを謳ったのが、Lispへの皮肉であるかのように思える。

コンピュータの中に世界をつくり、それを分かりやすい形で提示するという課題は解くのが難しい問題ではないですか？
それも入り口から奥底まで一貫したデザインを保つのは並大抵ではないでしょう。

Smalltalkはまさにそうだと思っていますが、そういう奥底の部分、内蔵されているコンパイラやらメソッド自身の実行環境やらのメタな機能（ちゃんと「こいつらも使ってやってね」と抽象化されて提供されています）を使いこなそうとすれば子供向けどころじゃないですよね。

結局何が言いたいかというと、Smalltalkという言語には難しい問題を解く力があって、その力がなければ「簡単なことをより簡単に。なおかつ難しいこともそれなりに。でも自由度は思いっきり高く」という需要には応えられなかったはずだ、ということです。

-子供向け「のみ」を謳った、と言いたかったわけではないです(^^;
-むしろ、Smalltalk側の主張(?)を信じるならば、Lispだって普通の奴らに使いやすい言語だ、と言えてもおかしくないはずなのでは…
-言えるでしょう。プログラミングの予備知識が無い人にSchemeを教えるとごく自然に習得していくそうです。
--その手の「私は見た」を、OOPファンはOOPにおいて、SQLファンはSQLにおいて、それぞれ目撃したと主張しております(^^;。どれとどれが信じられるのやら…

[[id:748]] 2002-06-22 02:51:50

Cocoaはやっぱり!

http://www.big.or.jp/~crane/cocoa/indexOnline.shtml

MacOSXのあの開発環境の説明(と書籍宣伝?)頁。

…それにしてもすごい開発環境だなあ。すごいというのは「是非欲しい」機能が一杯有るという意味で。
最低でもこれくらい出来ないIDEは「使いづらい」と呼ぶべきじゃないかな。

----

MacOSX/エディタへ移動しました。

[[id:644]] 2002-06-23 23:17:10

RubyCocoa@SsPuki

http://mwave.sppd.ne.jp/wiki/pukiwiki.php?RubyCocoa
インクリメンタルサーチができるParagraphWikiViewerでも作りますか。

Cocoaはやっぱり! (#5) : Cocoaつながり。

[[id:648]] 2002-06-06 08:19:05

全てのInstanceをメモリ上の1つの巨大データ(?)として持つ実装

RWiki:PRb (データペース) がやっていることを、
RDBじゃなくメモリ上の(1つの)Hashtableに対して行うと、
メモリ上のインスタンス(????)が1つしかない、という言語(というかObjectの有り方)が実装できそう。
RDBって永続Hashtableみたいなものだからねえ。(暴言?)
-テーブルが３枚ありますから、正確に言うとインスタンスが３つ、ですよね。
まあ、やって嬉しいかどうかは知らないけど、なんとなく。 -戯

[[id:670]] 2002-06-24 19:40:07

無礼講言語

某所(笑)でも書いたが、ふと思ったこと。

SchemeとかJavaScript(?)とか(他多数)は、「無礼講」に依って立つ言語、なのではなかろうか?

アクセス制限をすることで成りたつのではなく、
しないことで成りたつ、という感じ。

たしかにclassだinterfaceだprotocolだを考えるのは
戦略的には重要だろうが戦術(?)的には繁雑だなってことが多いのは賛同できるんで。

#ところで、上のほうで「酔って立つ」という誤変換をして笑った。酔拳言語?

[[id:673]] 2002-06-09 15:11:58

継続とObjectと掲示板とWikiと

> MailのSubjectよりWikiNameのほうが多分短い言葉を期待されてると思う (ひとりごと)

継続は掲示板に、ObjectはWikiに、似ているんではないか?(笑)

[[id:714]] 2002-06-15 17:43:58

Prograph

そういえば、ちょっと戯さんのとは方向性は違うのですが、かつてPrographっていうVisual Programming Toolがあったのを思い出しました。
‥‥ガイシュツ？
（カレントトピックとはずれた話題ですんません。）

http://members.aol.com/paulc999/cpx/demo.html
http://www.taylor-design.com/datalink/

[[id:722]] 2002-06-16 21:44:59

データ駆動型のプログラム実行(data flow graph)

以下、岩波講座 情報科学 12 「算法表現論」 木村 泉、米澤明憲 著 (本棚) より引用。

プログラムを特別な順序のない命令(instruction)の集まりとみなして、各命令はそれに対するデータあるいは操作対象(operand)の準備が出来次第いつでも非同期的に実行できるようになっていると考えると、より高度の並列性を達成できることがある。このようなプログラムの実行形式をデータ駆動型と呼ぶ。

- 実際はあんまり細粒度だとプログラマが困るんで，適当に意味のある塊の中はふつうに書くものが多い．
- Lisp だと結構小さな粒度でも自然に見えたりはする．

----
化学的コンピュータ？
酵素の型があった場合に処理されるとか。
試験管の場合は数の多さで勝負できそうだけど、
電算的な場合は条件がそろったことの確認が難しそうですね。

- なんかタグ付のメッセージバッファがあってどうこうっていう話を聞いた覚えが．

----
今風に言えば、Event駆動とかawkとかですかね。
というかawkは、文字列パターンという(メタっぽい)イベントによる駆動なわけだけど。

----
実はトポロジ固定の active object によるプログラムと区別がつかなかったりする．
データフロー計算のノードも actor っていうんだよな....

日本では ETL の EM-4，EM-X なんか? で，そのへんで検索すると学生時代の先生の
名前が出て来る :-)

そういえば Sharp がデータフローチップを商品化したんじゃなかったっけ．

[[id:726]] 2002-06-18 10:26:00

インタプリタのインスタンスを複数作ろう!(笑)

> TinyBASICにはローカル変数がないので (プログラミング言語:文法談義)

以前どっかでOOPを説明するときに使ったことのある表現なんだけど、
「オブジェクト=ポケコン」という説明(^^;

さすがに変数名固定はイタイけど、そこまで言わないにせよ
ポケコンのメモリって数Kとかいうオーダーだったわけで、
それって今風にいえば時として1つのObjectのサイズだったりするんだよね。

RAMには状態が、ROM(ポケコンCPUからはそう見える)にはルーチンとかが、
用意されてるという。

で、そんなポケコンが「無数(?)に」連携動作する、っていう説明をしたことがあります。

さすがに1つじゃ美味しいことは殆どできないけど、
多数あつまれば色々と…

----
そういや、クラス(ってのか?)「ごと」にパーサーを持っている、という言語(実装)の話を、どっかで聞いたような…
----
http://todo.org:80/cgi-bin/jp/tiki.cgi?c=v&p=%B8%B8%A4%CESmallTalk%C9%F7%A5%B9%A5%AF%A5%EA%A5%D7%A5%C8%B8%C0%B8%EC
↑これじゃないですか？
でもココで言及されてるようなパース方法はForthでは昔からやってる事なんですけど、知名度が低いのであんまり知られてないみたいですね。
ーばし

WORDワードの事をなどをおっしゃっているんですね？そういえばそのような方法を使って定義されているワードもいくつかありますね。というか、「何でもできちゃう」という文脈で読まれてしまうと、説明はそこで終わって（というか通り過ぎて）しまうので、ナニなんですが…--CUE

- えー、「何でもできちゃう」という文脈で上の文章を書き込んだつもりはありませんです。パース作業がプログラマ側に解放されている言語の古い例としてFORTHがあるけれども誰も言及してくれないのでやむを得ずオイラが書いてみた、といったところです。ちなみにFORTHは「パースする必要のある」ワードはすべてそのワード自身がトリガになってパースしますです。--ばしを

[[id:765]] 2002-08-26 20:44:29

PostScriptとLispのいいとこどりしてみよう

正ポーランド記法の言語を考えてみます。

[[id:772]] 2002-06-25 22:22:38

言語の語順による「不気味さ」をいかに除くか

PostScriptとLispのいいとこどり。 (ポーランド記法モドキの言語)
>(ちょっと苦しげ)

なんで苦しくなるんだろう？ちょっと考えてみる。

-OOPから見れば、CやLispの手続きが「先頭」に来るのは不気味。
--逆にOOPは手続きが「途中」に来るのが不気味。
-OOPから見れば、bbbbの(^^;主語が「最後の1つ手前」に来るのは不気味。

なんだろうなあ。結局は、
-手続きは特異で特別な存在である。
-主語も(手続きとは全然別の意味で)特別な存在である。
ってとこか？

受け入れられてる(ぉ)文法の語順って、限られてるかも。
動詞,名詞,名詞…
っていうのは(既に先達が需要を満たしている(ぉ)ので)さておくとして、そのほかは、
1:名詞(主語),動詞,名詞(残り)… #OOP流?
とか
2:名詞(主語),名詞(残り)…,動詞 #独語の「枠構造」とやら、とか日本語とか
とか、ですかね？

さて。bbbbは何故、主語が後ろから2番目にならざるを得なかったのか？
それはね、名詞の羅列の先頭を確定するReasonableな手段が、他に無かったから、だよーん。

じゃあReasonableに確定する手段があれば、2の語順をやれるのではないか？

そう考えると、 PostScriptとLispのいいとこどり。 (ポーランド記法モドキの言語) の「スタックをクリア」するという動作は、重要になるんじゃないかな。

[[id:771]] 2002-06-25 17:05:10

言語を開発(試作)するエンジンまたはフレームワーク

ってのは、なんか有るんでしょうか?

パーサー作るところまでなら、yaccやその子孫たちとか色々有るわけだけど、
その先を定型化&楽化するような道具って、少なくとも私は知らない…

それとも、それは定型化しようのないもの、なのでしょうか?

ポーランド記法モドキの言語とかを読むにつけ、
試作をさくさくと気楽にしてみれるようになるには、
どんな道具があればいいのかな?と思いましてね。

#それはLispだ、というオチではなかろうな?(ぉ

[[id:820]] 2002-06-30 22:50:56

パーサーだけが言語のありようを決するわけでもないんで

コンパイラ関連情報サイトへのリンク (プログラミング言語:URLメモ)

パーサーより後の段階の問題もありますよね。

例えば、その言語処理系が内部データをどう持つか、つまり(かな)、
その言語のFirstClassObjectを何にするか？を決めないとならんですし。

だから、パーサーを取り替えただけでは、例えばLispとJavaScriptを行き来することは出来ないと思います。
まぁ一方が他方になりすますという消極的な関係は構築可能だろうけど、それだけのこと。
どんな言語にも対応できる万能内部アーキテクチャなんてものを作ったら、多分重くて重くて…

逆にいうと、内部データアーキテクチャを1つ決めて、それに従う言語を複数用意する、というやり方はありでしょうね。
#MS .NETがソレなのでしたっけ？

まあ1つだけ決めるってのはさておくとして、色々ある中から使いたいものを選ぶってのを許容するとして、
ここで「選ぶ」ことが可能なんじゃないかな？と思うのです。
つまりアーキテクチャを幾つかのパターンに分類することが可能なんじゃないかと。
この世の全てのアーキテクチャを分類して表現可能にしよう、とまでは言いませんが、
幾つかのアーキテクチャを幾つかの分類に振り分けることは、可能なような気がする。

で、大分類(?)の中から好きなのを選ぶ、その個々の分類の中はフレームワークになっていて
少々の拡張をユーザーが行えば出来上がる、ってのが理想かなーとか気楽に言ってみるテスト。

[[id:841]] 2002-07-04 16:14:20

List Comprehension

チュートリアル (プログラミング言語:Haskell)では、「リストの内包表記」と訳されている。
最近のPythonにも新しい機能として採用されたようだ。
----
Haskell:
[(x,y) | x <- [1,2,3,4], y <- [10,15,3,22], x*y > 25]

Python:
[(x,y) for x in (1,2,3,4) for y in (10,15,3,22) if x*y >25]

----
SQLの問い合わせを連想した。
欲しい要素を挙げて(expression)、それが属する集合を指定し(generator)、抽出のための条件を書く(qualifier)。

xs = (1,2,3,4), ys = (10,15,3,22) のとき、
CREATE xs (x INTEGER);
CREATE ys (y INTEGER);
SELECT x,y FROM xs,ys WHERE x*y > 25;

やっぱり似てる。

[[id:838]] 2002-08-06 03:24:10

StackじゃなくFIFOでやっちゃう、あれ系言語？

これってパイプラインモデルだ! (ポーランド記法モドキの言語)

http://dell.tanaka.ecc.u-tokyo.ac.jp/prosym01/contest/
「予選問題」だそうだ。

>以下の妙なプログラミング言語 FIFOL(FIFO Language)を使って

妙とか言われてるし(ぉ

>poorな処理系を何種類か用意する予定

だそうだ。Awk版もあるようだ(ぉ

----
ある意味当然で、またある意味で感心してしまうのだが、どれもソースは短いなあ。
そうか。こんな程度m(__)mで言語って出来ちゃうものなんだ。
いちいち道具がどうとか言う必要も無いのかな？

ちなみにjavaには StreamTokenizer という超美味しいクラスが純正で存在する。
引用文字列やコメント(Javaスタイルの)まで勝手に処理つまりトークン切り出しをしてくれる。
もしかしてこれ、javaコンパイラ「が」使っているクラスなのだろうか？

----
FIFO型Objectが、Stackの替わりであり、かつ配列としても使われる。
-switchというオペレータで、カレント(?)FIFOと、FIFOトップに参照されてるFIFOとを、入れ替える。

[[id:843]] 2002-07-16 20:37:24

このDAOはいつか来たDAO

TAO(中国語で"道")に掛けてるつもり。

java world 2002/8 p81
DataAccessObjectパターンでリソース層を抽象化する

あう。どっかで聞いたような話が…

----
http://www.borland.co.jp/tips/bes/bes005/
DAOはもうお払い箱らしい。
そういう仕事はEntityBeanのお仕事になる、と。

たしかに、理想的に言えばそうなるべきではあるだろうな。
EJB2.0でEntityBeanがComponentManagedRelationshipをサポートしたので、
原理的には表現力の不足は無いはずだし。

[[id:854]] 2002-07-17 13:14:15

msekiya:Eiffel

http://kasiwa.sci.hokudai.ac.jp/cgi-bin/tiki/tiki.cgi?c=v&p=Eiffel
"Design by Contract" がEiffelのキモらしい。
-JavaWorld 2002/9 もDesign by Contractが特集されてる。

[[id:856]] 2002-07-30 15:42:26

RubyとHaskellの語順の比較

算譜の記:2002-01-10-1
演算子を簡単に定義できる言語があると、優劣を比較しようという気にもならなくなるんですね。
気に入った方を使えばいいから。:D

[[id:928]] 2002-08-06 17:59:49

プログラミング言語のモジュラリティ

プログラムの部品分割能力は結合の容易さに依存するらしい --SHIMADA

１．ＧＯＴＯ
行番号指定
条件付ＧＯＴＯ
スパゲッティ

２．サブルーチン
コール・リターン構造
グローバル変数への副作用
行番号・ラベル名での宛先指定

３．関数・引数つきサブルーチン
コールやリターンに値が伴うようになった
構造化

４．ファーストクラスオブジェクトとしての手続き
コール・リターン構造
コール・コール・コール‥‥‥構造もありえる（末尾再帰 or 継続渡し）
処理の詳細をパラメータとして渡す
継続をパラメータとして渡す
手続きの詳細を生成する手続き

５．データ＋手続き＝オブジェクト




ネストしたコール・リターン構造の複雑化
obj.method(arg) は、
FUNCALL(LOOKUP(method,CLASSOF(obj)), obj, args...)
のシンタックスシュガーだがclass の評価が実行時まで決定が遅延されることが重要

[[id:1022]] 2002-08-21 18:00:17

Programming Language Design and Implementation

http://wouter.fov120.com/proglang/
プログラミング言語がいっぱい。
グラフィカルな言語ってけっこうたくさんあるんですね。 --SHIMADA

-この人の自伝(ぉ)頁っすね。
--G言語の紹介の絵を見て、変数ってものについて哲学したくなってしまった。＞グラフィカルな配線型言語 (#24)

[[id:1040]] 2002-08-24 15:32:26

グラフィカルな配線型言語

とっさに考えた造語「配線型言語」。-戯

一般には、データフロー型、というんでしょうか？
-でも、配線によって表す対象(概念)は、データの流れだけじゃないと思うんだよな。
--他のObjectへの参照だって、線で表していいだろう。
---他の手続きへの参照だって…
--データの流れは他のオブジェクトや手続きへの配線の中を流れていくのでは。--SHIMADA
---たとえば、参照は「矢印」であって「流れ」とはあまり呼びたくないんですけど。何かを流しているわけではない。 -戯
---ところで、「流す」というとどうもPush型のものを連想しちゃうのは俺だけでしょうか？Pull型のもの(参照もコレに属すると思う)は別だよな、という…
---誘導紐みたいなイメージかな。Pipe(Flowを伝えるもの)の一端を遠方に繋げるために、紐にPipeを括りつけて、紐の一端自体をどこかに「飛ばし」て紐を手繰って貰うと繋がる。一方で紐は救命浮き輪(Flowではない)も括りつけて飛ばすことが有る。

----
実例：
-PureData 間接参照しとこう。 http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=PureData
-PlugWare これも間接。http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=PlugWare
-MAX てゆーかこれも間接。http://todo.org/cgi-bin/jp/tiki.cgi?c=v&p=MAX

[[id:1041]] 2002-08-24 22:04:40

いままで見聞きしてきた

いろいろな言語のいけてる機能をまとめてみる。分類などもいまいちですが…。

第一群：データオブジェクト
-ファーストクラスオブジェクトとしての関数
-辞書(連想配列)
-多相型と型推論

第二群：メタプログラミング
-ユーザー定義演算子(関数を演算子として自由に宣言できる)
-call by nameサンクによる引数の遅延評価
-万能評価関数(eval, apply)

第三群：処理系
-末尾再帰の最適化
-VMとバイトコードによる可搬性

第四群：文法と表現
-レキシカルスコープ
-関数のカリー化
-クラス／型によるメソッドディスパッチ

以上私見ですが、ぜひこれも！ というのがあれば教えて下さい。--SHIMADA
----
↑あー、混ぜないで分けて書いていただけるとありがたいです。--SHIMADA

----
10-4．ええと，私が加えたのはこれぐらいだったかな．更に付け加えてみると
....かたよりまくり．

データ構造
- 遅延評価を利用した無限ストリーム

メタ
- 事前/事後表明と不変表明を利用した「契約によるデザイン」

実装
- boot strapping
- garbage collection

コード上の表限
- List comprehension
- 構造化例外処理構文

計算モデル
- 並行処理と相互排除/条件同期関連
-- actor model/並行オブジェクトモデル
-- future call/wait by necessity
-- monitor
-- synchronization constraint/guarded method
- 述語論理と unification によるプログラミング
-- guarded horn clause をベースにした並行論理型言語
- label-selective lambda-calculus with optional arguments

[[id:1059]] 2002-08-28 14:54:25

いままで見聞きしてきた (#25)ってFPゆかりのものが9割を占めてますね。

「今の」自分にとってビビッドなネタ、という感じの収集でしょうか。
過去に感じた(そして今もお世話になってる)ビビッドがあんまり出てないような。
それとも、マヂで、よさげな過去ネタはあんまり無い？

-過半数(というのは乱暴か?)の言語が既に導入してる機能については、「個別の言語のいけてる機能」とは呼べなくなる、とか？

- えーと、正規表現とかのいわゆるライブラリや制御構造のようにメタプログラミングで済むものはなるべく入れてないという感じです。（とかいう --SHIMADA
-- うーんそうでもないなー。やっぱり慣れ親しんでいるものは空気みたいになっているだけかも。--SHIMADA

[[id:1060]] 2002-08-28 14:24:51

プログラミング言語:哭きのC言語

あとでWikiNameに展開しようかな…

----
1の哭：一時変数地獄

-必要となる一時変数が多すぎる
--返し値の文法に柔軟性が無いので、引数ポインタ返しを多用せねばならず、その際いちいち変数が必要になる
-一時変数をいちいち宣言しないとならない
--しかもブロックの冒頭でなければならないので、必要な個所から遠く離れてしまうことが多い。
---それがイヤならいちいちブロックを導入する羽目になる。あるいは関数分けか。
----関数に分ければまたしても変数の受け渡しで悩まないとならない。

という合わせ技により、一時変数作成で、ソースの行数の半分くらいが食われてしまう(ぉ

----
2の哭：括弧の種類が多すぎる
たった3種類だが、これら種類の間には深刻な溝がある。

主に面倒なのは{}と()の差。
-{}はLocal変数を作れるが値になれない
-()は値になれるがLocal変数を作れない

[[id:1135]] 2002-09-05 15:43:40

データもプログラムもハッシュであるような言語

LISP (LISt Proccesser) にちなんで HASP (HASh Proccesser) ? --SHIMADA

PRb(RWiki:PRb (データペース))のように、オブジェクトをハッシュとしてモデル化するようなストレージアーキテクチャにふさわしい言語処理系のデザインは何か、この数ヵ月間頭の隅でぼんやり考えて来たけれど、今日やっとひらめいた。＜遅すぎ

Lispが二分木／ドットペアをデータ構成の基本要素として持ち、プログラムも構文木を二分木やそれを見やすくしたS式によって表現するように、ハッシュをオブジェクト構成の基本要素とするなら、構文木もハッシュによって表現したい。

構文要素をあらわす抽象クラス Expr は抽象メソッド eval() を持つ。
具象クラスには例えば IfThenElse, CaseCond, Begin, MsgSnd などがある。

例えば IfThenElse クラスのインスタンスは if, then, else という３つの属性をもち、それぞれに Expr のサブクラスである構文要素をあらわす具象クラスのインスタンスを格納する。

IfThenElse::eval() は expr を評価し、真ならば expr-t を、偽ならば expr-f を評価する。
IF-THEN-ELSE {
:IF => <expr>,
:THEN => <expr-t>,
:ELSE => <expr-f>,
}

CaseCond::eval() は expr を評価し、返り値と等しい <cond x> の <expr-x> を評価する
CASE-COND {
:CASE => <expr>,
<cond a> => <expr-a>,
<cond b> => <expr-b>,
<cond c> => <expr-c>,
:
}

Begin::eval() は キーの昇順に expr を評価する
BEGIN {
1 => <expr>,
2 => <expr>,
3 => <expr>,
:
}

MsgSnd::eval() は (RCVR の <expr> を評価した値である)オブジェクトの (MSG を評価した結果である)メソッドを (ARG を評価した結果である)値を引数として呼ぶ。(ああ長い)
MSG-SND {
:RCVR => <expr>,
:MSG => <expr>,
:ARG => <expr>,
:
}

「exprを評価する」とはその属性値として束縛されているオブジェクトの eval() というをメソッドを呼ぶこと。

上記はパース後のハッシュの状態を表しているだけで、ソースの字面はもうちょっと見やすいものになると思う。…多分。

----

- そういえば、HLISPというのがありましたねぇ。--Haskeller
Hash cons という実装で、equal なら eq であるような実装で、関数を片っ端からメモ化できるというしろものだったような。。。
- これですね。センセイのエッセイはどれも面白いです。--SHIMADA

-----
うひー。 Hasp(掛け金)という名称だけならばぶばぶ/dictとobjとclassの実装の統合なんかでも既出ネタだけど、
実装のほうは…(^^;; -戯

Listとか(Cでも使われる)引数とかの仕組みって、「順番」ベースですよね。
いっぽうHashだと順番のかわりに「名」ベースなんで、なんか色々愉快なことになりそうです。
とりあえず何をやるにも(ぉ)名前つき引数のほうがデフォだろうし。

[[id:1141]] 2002-09-06 09:24:15

名と体の逆転現象

http://www.amy.hi-ho.ne.jp/~lepton/program/p2/prog245.html みたいな末期的な状況までは問わないとしても(^^;、だ。

プログラムでは変数に「きちんと(人間様に)判り易い名」をつけることが強く求められるのに、
一方で上記のような考え方が「存在する」のは、何故なんだろう？と思って。

----
唐突だが思い出したのが、修学旅行とかの後の、写真注文票だ。

3年生(^^;の廊下の壁一面に写真が鈴なりに貼りだされ、それらに「番号が」付けられている。
我々は写真を見て、欲しいものを選び、その「番号を」自分の注文票に書いて提出し、買う。

なんでこれ、番号なんぞで事足りるのだ？と。

----
つまり、変数とは逆に、番号で事足りる世界が、存在しているようなのだ。

では、変数の世界(^^;と、番号で足りる世界とは、ナニが違うんだろう？

----
ちょっと考えてみたが、これはもしかして、
名によって指される対象が、「見ればわかるじゃん」なものであるかどうか？なんじゃなかろうか？

写真は、最悪注文を間違えたら(ても)、その写真をちらっと見れば
「あ、これ違うじゃん！」とすぐ判るはずだ。人間なら。
#あと、間違っても訂正がラクじゃん、という面もあるが。

ところが変数とObject(OOP用語に限らず)においては、大抵の場合、
変数(名)に指されたモノを「見れば判るじゃん」というわけにはいかない。
なにせ見えないのだから。

ならばどうするか。
たぶんやれることは多くなく、たとえば変数の名というものに「見れば判る性」を「委譲」
せざるを得ない、という程度の手しかないのではないだろうか？

で、当然だがリアルワールドでのほうが、「見れば判る」ものの存在率(?)は、多いだろう。
わざわざViewを作ってあげないと手も足も目も(?)出ない計算機のメモリの中身とは、逆に。

----
そう考えると、逆に、VB/DelphiとかのGUI RADにおいて、Objectをbindするデフォルトの「変数」名が
すごく素っ気無い通し番号とかになっちゃってることの、多少なりともの合理性が、判る。

GUI RADではまさに、Objectは「見れば判る」のだから。

Objectをbindする変数にうだうだ名前を付ける(そしてリファクタリングで
しばしばその名前を変える必要に迫られる(ぉ))ようなことをするより、
見れば判る(Propertyとかもすぐ見れる)し、Clickすれば関連するCode(事実上の「中身」)に一発ジャンプできる、
という仕掛けに頼るほうが、ラクであることが確かに多いだろう。

更にいえば、Objectの数が(1画面上に)多くなりすぎたときに、このヤリカタが破綻するのも判る。
見ても判りにくくなるからだ(^^;

更にいえば、GUIリソース(なんでこう呼ぶのだ？)をCodeと独立して編集するタイプの GUIエディタは、
ちょっと使いにくいということになるんじゃなかろうか。

----
>> まとめ (Smalltalk)

[[id:1160]] 2002-09-11 15:27:01

Algol N

自己拡張性をもった言語で日本製らしいんですが、ネットでは資料が見つかりません。
どなたかご存知ないでしょうか？ --SHIMADA

[[id:1171]] 2002-09-12 11:01:40

プログラミング言語:C++:スマートポインタ

std::auto_ptrはダサい。
もっといいのはないのか？という話。

-http://www.tietew.jp/cppll/archive/2848
--boost::smart_ptr
--Loki::SmartPtr
--http://www.dodgson.org/lab/hat/ptr.html
- boehmGCとかでやっちゃえ、という声もあるが…

[[id:1176]] 2002-09-12 16:34:08

十進BASIC

http://hp.vector.co.jp/authors/VA008683/
使おうという気はおきないけど、好感が持てる処理系。

[[id:1192]] 2002-09-16 21:51:52

jython

http://www.jython.org/
http://www.jython.jp/

[[id:1324]] 2002-09-29 19:16:54

top recent

HashedWiki version 3 beta
SHIMADA Keiki