top recent

グラフ計算ソフト(仮称)

目次

  1. グラフ計算ソフト(仮称)...
  2. マクロないしはスクリプト...
  3. スクリプトの実装案1...
  4. proto...
  5. むー、面白そうですね。...
  6. 属性値として属性に保持させる値の種類...
  7. シンボル入力補完機能...
  8. ライバル出現かぁ(ぉ...
  9. Excel症候群...
  10. Excelの向こうを張るといえば...
  11. SheetViewの内部構造...
  12. データが蠢くのが見えるデバッガ...
  13. 属性入力欄に入力またはDragDropされた時の動作...
  14. フォーカスのネスト...
  15. ブラウザに出来る(べき)こと...
  16. これって、継続...
  17. 継続渡しってコマンドパターン？...
  18. 多返し値と引数との対称性を強引に引き合いに出す...
  19. 継続とフォーカス？...
  20. webアプリ版...
  21. インターネットに公開されたオブジェクト環境ってカッコイイ...
  22. DragDropを本当に使うか?...
  23. フォーカスは働きすぎである(?)...
  24. Viewは当然ネストする...
  25. 「ソレ」は『セレクション』のことですね...
  26. トリガーわすれてた(笑)...
  27. セレクション以外のパターンもありますね...
  28. これってWinのレジストリエディタみたいだ？...
  29. ScriptObjectのrunの結果は、必ず継続を返す(返し値は常にそれダケ)、ということにするとどうなる？...
  30. JSPで汚い版を作ってみるテスト...
  31. calcpad...

グラフ計算ソフト(仮称)

表計算(Excelみたいな)の向こうを張って、
表構造じゃなくグラフつーかNetworkつーかな構造を
(エンド)ユーザーがすいすい弄れる＆プログラミング(!)出来る
ような環境(としてのアプリ)を、世間へと提供できないものか？

名称は悩んでいます。Object間の参照関係みたいなのを表現する一言って、
「グラフ」でも「ネットワーク」でも不味ゲなんで…

OOPでいうところのObjectを、ExcelでいうところのSheetのようなもの(ちょっと違うが)の雰囲気で
ユーザーに「見せる」「直接触らせる」ってのが味噌。

Objectは２次元表じゃなく1次元表つーかVBのPropertyEditorやDelphiのObjectInspectorのようなものとして表示される。
--つまり、デフォルトで(少なくとも)1種類のViewを用意された、Hashオブジェクト(Model)である。これを汎用(?)Objectだと捉える。

Objectの属性名はExcelに敬意を表して(^^;、「デフォルトでは」
A-ZとかAA-ZZとかを用意しておく。リネームの権利も当然ユーザーにはある。

属性名の考え方はJavaScript風。つまり配列は属性名が0から始まる数字(の文字列)になっているObjectだ、と考える。

属性の値は、文字列とかの即値のほかに、ほかのObjectの参照も書ける。
当然(?)文字列もObjectだとするが、UIはまだ考えていない。

Object(Hash)は、デフォルトで「グローバル名」を持っている。
つまりこれがグローバル変数。
Objectのグローバル名を削除(長さ0の文字列?へ変更)すると、
ほかのObjectから参照されてないとGCの対象となるだろうな…

Objectの属性値として書ける「ほかのObjectへの参照」は、
グローバル名か、またはほかのObjectの属性値への参照(ってのか)か、
どちらかとして保持される。

画面にHashなObject(の表)を複数表示しておき、
一方のObjectを他方のObjectの属性値欄へDragDropすると、
後者の該当属性名へ、前者のObjectの参照が(グローバル名として)代入される。

---
表形式の利点は、入力の簡便さと見た目のわかりやすさにあると思います。
そのあたりが上手に処理されたUIがあるとうれしいですね。

ExcelのSheetを小さくしたみたいなものが画面に散在(?)して感じを今は想定してます。
Focusの移動のしかたの機微とかは、後知恵でなんとでも改良できるんで、
「それっぽく」という程度に軽くしか考えてません。

Objectの関連を見やすくする表示モードとして、
今注目してるObject(Sheet?)を画面の中央に置き、それの属性から参照されてる他のObject(Sheet)を
元の奴の周囲に放射状に配置する、他のObjectを選択しFocusが移動したら、今度はそれが中央に移動する、
というのを妄想しています。ちなむと放射状の位置を決めるアルゴリズムは、NattoViewとかXCruiseとか(^^;みたいに
その参照属性名から計算して求めるようにして、人間さまが自由に並べることは敢えて控えたほうが良いかもと妄想。
アルファベット順に時計周りに12時の方角から並べるとか。まぁ全部を確実に並べきれるわけではないでしょうけども…

あと、上記のような表示画面は、願わくば複数を同時に表示できたいものです。
Objectの関連という名のView(????)を、同時に複数の方向から見たいでしょうから。
そして、片方から他方へ、情報を移動(DragDropとか)出来るようにしたい。

----
思索はさておき試作の環境、どうしようかなあ？
Delphi(Kylix)だとDesktopで嬉しいような気がするけど、
コレってGCの無い言語で開発するのも辛そうだし、
動作プラットフォームが限定されるのも嫌っぽい。
やっぱ理想はWabaっすかね(ぉ

Wabaみたいな微小環境でやろうと思ったら、UIも一ひねりが必要かも。
PC画面みたいに俯瞰と詳細を同時に見せたい(いわゆるメーラー的3ペイン表示などなど) ってのは無茶だろうから。

----
Delphi(Kylix) + Ruby は？とか使ったこともないのに言ってみる。それはともかく、そろそろWikiName化？

とりあえずWikiName化。
signature: 戯

[[id:548]] 2002-05-12 11:31:01

マクロないしはスクリプト

そっか。Apolloって手も有るんですね。
個人的にはRubyについては最近、気にいらない文法な個所が数ヶ所有るんで
(JavaScriptのほうが良いと思っている)
あんまり意識に乗せないようにしていた(ぉ)節があります…
そのせいでApolloの進捗状況もよく理解してないし。

ま、思索/試作なら細かいことはどうでもいいか。

さて、ScriptObjectについては、HashObjectの特殊化したものとして実装しよーかと思ってます。

-CODE(たとえば)という名の属性名に文字列をあたえると、それがScriptの実行実体(のソース)となる。Macのリソースの真似か?
-直接アクセスできる変数やメソッドは、Hashとしてのselfのメンバ変数「だけ」。
-じゃあ他のObjectをどうアクセスするか?というと、あらかじめ「手作業で」他のObjectの参照をselfの好きな属性名にDragDropしておいてもらうことにする。
-他のObjectのメンバは、上記手段でいったんアクセス可能になったObjectから、hoge.fugaというようなお馴染の文法でアクセスする。
-グローバル名にバインドされたObjectも、あらかじめ「手作業で」以下略。

こーゆーScriptObjectを作り、ほかのObjectの属性名にバインド
(つまりDragDrop)しておけば、そのObjectの「メソッド」として使えるようになる、というわけで。

さらに、文法を自作するならば、ですが、

-ローカル変数は、無い!! (ぉぃぉぃマルチスレッド捨てるのか?)つまりこの言語には、ひたすら属性名しか無い!!
--protoの仕組を使って後輩Objectを作ってソレを動かすことにすれば、マルチスレッドとかを捨てる必要は無くなるのでは?
--そのObjectを捨てればメソッド一回実行ごとに干渉される心配はないし、故意に捨てないことで継続だって表現できるんでは?
--なんでこんなことしたいかというと、変数が例のSheetモドキを使って必ず「見る」ことが出来るようにすべきと思ったので。たとえローカル変数であっても。「止めて、見る」ことができるのが必須。

-つまり俗にいうローカル変数は、ScriptObjectのメンバ変数(つまり属性)として実装しちまえば良いはず。
-引数も、立場が特殊なローカル変数と見なせば済む(ほかの言語でおなじみの通りに)ので、これでいけばいいかなーと。
--それってもしかして、 自由変数を持つ関数 (プログラミング言語) ってのと近い概念じゃないのか?
--一時的な無名変数つーかは、どうするんだ？Stackでも用意しといて値を積むことにするか？
--引数つきで手続きを「呼び出す」ときは、たぶん引数は「必ず」名前付き引数になるだろな。というか名前付き引数で名前無し引数をエミュすることはできるが、逆は無理だ。
---つまり手続き呼び出しとは、以下の手順をマクロ化したもの。
----ScriptObjectのproto後輩を作る。
----その後輩の属性に、与えられた引数を、名前に従って、代入。
-----ふつうselfとかReceiverとか呼ばれるモノ(ScriptObject自体でもScript#CODEでも無い)も、引数と同じ扱い。
----CODE属性の中身をInterpretする。
----終って返ってきたら、RESULTという属性(笑)を読めばそれが所謂返し値だ、という約束にしておく。delphiの真似?
----- RESULTが、 属性値として属性に保持させる値の種類 (#6) の「何もない」になっていれば、返し値は無いとする。
------ protoの仕掛けを使えば返し値のデフォルト値を予め用意することも可能。
----特に必要なければこのproto後輩を捨てる。もちろんGCが有るならば参照を切るだけだが。

-import(java)とかinclude/require(ruby)とかの概念も、同じように、ほかのObjectの参照をDropしてもらうことで解決させちまえば良かろう。なんという手抜きだ…
-つまりこの言語で直接アクセスできる変数は、ローカル変数(として扱われるメンバ変数)しか無いわけだ。手続き参照も同様。ローカル変数の初期化(ってのか)を手作業DragDropでやる、というわけ。
--これは、ちょいと毛色のかわったアクセス制御(巷ではpublicとかprivateとか言うアレ)。手動importすることでアクセスを許されたObjectの他へは、外界に触れる能力が無い、ということ。

signature: 戯

[[id:561]] 2002-09-25 15:11:39

スクリプトの実装案1

マクロないしはスクリプト(#2)

020925 書いてみるテスト
TikiGuion:六本松/言語案020911

021001 名前空間ずらしver2 を考えてみるテスト。
同上。
これなら実装できるかなと思うが、結局Lispに勝ててないという罠(^^;

[[id:1302]] 2002-10-01 12:51:43

proto

やぱーりプロトタイプOOPでしょう(笑)

あるObjectから属性名「Proto」で参照したObjectが、
おなじみの先輩Objectだ、ということにする。

基本的なクラス(??)のプロトタイプは、
起動時にあらかじめ用意しといたグローバル名に
ぶらさげておこーかな。
$Intとか$Stringとか$Objectとかとか。

とーぜん自作も有り。

[[id:562]] 2002-05-12 11:43:45

むー、面白そうですね。

簡単でもいいから動いているところが見てみたい...

スクリプティング可能なオブジェクトは特に面白そう。
MacのCocoaみたいなGUIとかも良さそうですね。

[[id:563]] 2002-05-13 12:56:34

属性値として属性に保持させる値の種類

ちょっとまとめておこう。

-Object(ぉ
--値
---即値(Immutableってことにしたほうが良い…だろうか?
----文字列 to_s(?)が返すのはソレ自体
----数 to_sは所謂普通の10進数文字列
---シンボル
----グローバルシンボル to_sは $シンボル名
----ローカルシンボル(つまり属性名(selfのシンボルを参照できて嬉しいのか?? to_sは シンボル名
----＃注：シンボルは実際にはFlyWeightパターンつーかProxyパターンを使い、本体をPoolして共有すべきだろう。
---nullとかtrueとか雑多な奴 to_sはまぁお馴染のアレ
---式(ScriptObjectと役割が被るから不要かも??
--Hash(例のSheetみたいな奴(の参照 to_sは 「>>(あれ)」とか「>>(自分で持ってるグローバルシンボル名)」とか
---配列(各属性名が数字にRenameしてあるだけ(^^;
---ScriptObject
-「何もない」という状態。proto先輩から継承した値が透過して見える(ただしReadOnly)。 to_s(????)は透過先を Italicで 表示

蛇足：属性名として使える(つまりシンボルに保持され得る)値の種類
--即値
--正規表現 future workとして…

蛇足2：ScriptObjectのCODE属性に代入して意味が有る(つまり評価できる)値の種類
--文字列(ぉ
--Native手続き(ってのか?
---つまり、手書き(?)ScriptだけじゃなくNativeとかも、「アクセス可能な変数はソレの属性だけ」という制約を、課されてる。

--

シンボルについては、いろいろな事を迷いますねえ。
[[ばぶばぶ]]考えたときから迷っている、というか、
言語が「言語」であるがゆえに存在する必要悪、というか、
しゃーないべや、というか…

signature: 戯

[[id:577]] 2002-06-03 02:16:10

シンボル入力補完機能

C++やJavaやDelphiのような、コンパイルする強い型付けの言語では、
この機能をIDEとかが持つことは一般的だが、
Rubyとかの弱い型付け言語では、それは困難だ、と言われている。

が、今回のコレでは、実は容易に可能なのではなかろうか?
なぜなら、その情報を調べるべきオブジェクトは、既にそこ(メモリ上)に、存在するのだから(^^;
#もちろん、属性名の取得という(メタ)機能は、最初から有ると仮定して。

今書きつつある式を評価し、その先に来ることができる名前一覧を
取得する、ってのが1つ。

もう1つは、今のところメモリ上に有る全部のシンボルから
選択する、っていうやりかた。

両方できるとお洒落かな。

評価といっても、手続き(Script)にぶち当ったら、そこで止めること。
実行(?)時でないのに「評価」しちゃったらヤバい(かも知れない)から。
ただ、Scriptオブジェクト「の」属性を手繰るのは、アリだと思える。
signature: 戯

[[id:580]] 2002-05-18 01:40:02

ライバル出現かぁ(ぉ

だからそのノリは止めろっての…>おれ

俺はユーザーがデータをイジる(という欲求)から話を始めたが、
Corbis (OODB) は逆に、いじられた結果(?)としてのデータを
保存するところから話が始まっている。

そして、
>オブジェクトビューア
とかに話が進むらしい。

signature: 戯

[[id:581]] 2002-05-18 02:18:03

Excel症候群

(このWikiNameにとっては)余談だが。

http://www02.u-page.so-net.ne.jp/xa2/senoh/98-03-d.htm#98-03-23

印刷に振り回される人(つーか猿)のことは
ペーパーレスな解決(成敗)をしてもらえばいいのでさておくとして、
それ以外の面については、表「計算」ソフトという名前がアレなのかも。

計算は欲しいわけじゃないけど「表」ソフトが欲しい人は多いのだろう。

で、両方の機能を抱き合わせ(不可分)にしちまってる実装(ジャンル)がたまたま有り、
それが俗に表計算ソフトと呼ばれる、という程度のことか。

計算といってもアレは、計算機一般に言うところの「処理」だろう。
つまり、データと処理がユーザーによって記述も閲覧も楽(建前は)に出来るシステム、ということだ。
データと処理を、表という整理形態に、整理(?)する、というもの。

で、前述のように、整理形態は表以外にも有りえるよな？というのが、このWikiNameの話。

>もっとも、どちらも一個所 (関数 や シート)に、全てのモノ (コードやデータ) を詰め込む傾向があり、分割するよりまとめる事を好み、やたらと巨大で分割不能なモノを作り上げるという点

あのー。Object指向もLispも、それに通じるんですけど(^^;

#というか、分割と一体化の軸というか(メタ的な)方角が違うというか、そういう感じかな。
----
すべてを一箇所にまとめて巨大で分割不能なものを作るっていうのが、OOやLispと通じるものがある？？？
元のエッセイは、OOで言えば複雑なアプリケーションを巨大な一つのクラス(しかもシングルトンとか)にしてしまうような輩のことを言っている文章だと思います。

[[id:1093]] 2002-09-01 23:17:02

Excelの向こうを張るといえば

やっぱりHyattでしょうかね!!(ぉ

エっちゃんと呼べばー、ハっちゃんと答えるー
shellのechoの嬉しさよー(違

試作品の名前はコレかな(まぢか？

----
ゴルゴも真っ青なショットを繰り出すか、はたまた、突然レッドスクリーンで倒れるか...
スリリングなソフトウエアになるかも。

-Googleしたら、ホテル名(世界各地の)ばっかりが出てきました(藁

----
六本松キボンヌ。
激しくキボンヌ。（違

-あ。それは魅惑的かもぉー
--でも精神は岩田に置換済みという罠

- http://www5c.biglobe.ne.jp/~rikudou/mini/syougyousi/syougyou.htm まだ続行してたのCar…
-- http://www5d.biglobe.ne.jp/~yu-ki/hot/gallery/2222hit.htm モトネタは福岡だったのCar…

- RoPponMatsuですか？ならば拡張子は.rpmですね(違(傍迷惑

- 実用(?)の暁には、モバイル版とデスクトップ(ノートでもいいがとにかくPCクラス以上)版とをそれぞれ欲しいと思っていますので、ちょうど六本松1号と2号とに相当しますね(^^;
-- もちろん、外見は違っても中身のデータはコンパチだという(ぉ。
-- もしかして1号はとても＊重い＊、とかいうんじゃ‥‥。
---ありそうな話です(ぉ

----
歓談中すみませんが、会話を弾ませていらっしゃるのはどなたとどなた？
わたしといえば話のネタも全く理解できてません。--SHIMADA

-半分は戯ですが、あとはどうなんだろ…
-話題のネタは エクセルサーガ (本棚:コミック) 。エクセル君はハイアット君をライバル視してるっす。

-六本松キボンヌしてしまったのは通りすがりの者です。ずっとROMっていたのですが、エクセルネタに激しく反応してしまいました……。
-HashedWiki‥‥イイすっね。←ヲイ

----
というわけで流されて、mkdir 6pm してシマタあるよ。データファイルは*.6pmかもかも。

[[id:591]] 2002-05-28 21:51:48

SheetViewの内部構造


表示Objectの所有(?)親子関係：
-Sheet
--aKeyValueSet : KeyValueSet
---aKeyValueContainer : KeyValueContainer
----aValueContainer : ValueContainer implements Copyable
-----aValue : Value
-----aKey : Value
--GlobalName : ValueContainer
--NameSelectionButton
--ThisSelectionButton

クラス(?)関係：
-Value(値。実際には 属性値として属性に保持させる値の種類 (#6) で挙げられてる色々なClass。)
-interface Copyable (Copy操作の単位)
--KeyValueContainer implements Copyable (Hash内のKeyとValueのPair。Pair単位でCopyも出来るほうが良かろう。)
--ValueContainer implements Copyable (値1つ単位に対するViewとユーザー操作(Control)を受け付ける。)

signature: 戯

[[id:602]] 2002-05-25 18:10:41

データが蠢くのが見えるデバッガ

やっぱりこれが必須でしょう。

実行中(といか実用的にはデバッグとかのステップ実行中)にゃ、
どっかのHashのどっかのデータが「書き換えられたら(られるたびに)」、そこにViewのフォーカスを飛ばすことができる。

副作用は全部見えますが、何か？(ぉ

ついでに、データを参照しただけで飛ばすモードも、有ったほうがいいかな？
ReadのときとWriteのときのそれぞれ、飛ばす飛ばさないの設定が、
View Instanceごとに(同時に複数見えるようにしたいので)出来るようにする、と。

signature: 戯

[[id:610]] 2002-05-28 22:04:05

属性入力欄に入力またはDragDropされた時の動作


まず、あるObjectのある属性(のView?)に、入力(文字列とか?)のためのFocusを持ってくるか、
またはDragDropのTargetとした(つまりDropした)ときに、
左辺値Objectって考え方に意味は有るでしょうか？ (プログラミング言語:文法談義) の左辺値(漏斗)Objectが生成される。

Dropならば「入力」行為は既に確定しているので、その漏斗Objectを介して
そのObjectのその属性にDrag Sourceだったものを流し込む。

テキスト入力みたいに確定を待たないとならんものは、漏斗がしばらく存在し続ける。
(内部的にこの漏斗を掴んだ)テキスト入力Widgetが1つ立ち上がり、ユーザーに入力してもらう。
ユーザーが確定動作をしたら、漏斗経由で流し込み、自分(と漏斗)を片付ける。

つまり、ScriptObjectを実行するときにも、またユーザーが入力するときにも、どちらも
Objectへのアクセスは統一された仕組み(漏斗とか)によって行われる、のを期待してる。

----
ところでFocusってどうしよう？
あれ、うざいんだよね。特に現代主流のGUIだと、Focusという概念を凄く「使い勝手の悪い」かたちで実装しちゃってる。
#TikiGuion:GetFocus

具体的にいえば、既成のテキスト入力WidgetとかがOSやVM?の支配に基づいてFocusをやり取りする仕組みと、
今回作るであろう個性的な(^^;Widgetが独自にFocusをやり取りする仕組みと、を
どうやったら同居させられるだろうか？と。うーむ…
だからってテキスト入力Widgetも自作するってのは寒い方向性だし。

てゆーか「ネストされたFocus」ってどう扱われるんだっけか？
データ入力の対象は、Value→NameValuePair→Hashtableという風に階層構造になってるわけだけど、
じゃあそれに対応する(操作する)Widgetも階層構造にしたいじゃん。#危険思想か?
そしてその階層構造の中(というか一番上というか下というか末端というか)には
既存Widgetであるテキスト入力欄とかが来る事もあるわけで。
どうなるんだっけこーゆーのって？

[[id:671]] 2002-06-08 20:08:30

フォーカスのネスト


親と子に対するリンクを持つことにすると、フォーカスはネストしなくてもいいのかも。。

普通のオブジェクト間のリンクを辿る操作が水平移動だとすると、親子関係を辿る操作は垂直移動に相当する、とか。

ーばし

[[id:717]] 2002-06-16 00:47:05

ブラウザに出来る(べき)こと

ブラウザといってもwebじゃなくてObjectを見るツールだけどね。
でもどっちもブラウザであるだけはあって、似てる面も多いと思われる。

-ブラウザ(Viewだよ)の複製。IEでいう ファイル→新規作成→ブラウザ に相当。1つのViewを2つにcloneつーかforkしたい。
-Clickでのリンク手繰り
-「戻る」ボタン
-今表示してる位置…どのObjectのどの属性か？…を、保存＆再現する。ブックマークやショートカットに相当。
--保存といっても保存先はHash自体を使えばいい。つまりViewの状態自体もModelに保存する。
--「戻る」ボタンは、この「状態」を1つ前のものに戻す処理を行うボタンである。
---ということは、状態を表すObject(Hash)を、LinkedListにすればいいのでは？Linkを手繰ると過去のほうに行く奴。
---LinkedListにすれば、TikiGuion:分岐可能なStackのように考えることで、ブラウザの複製にも対応できる。分岐と履歴が分岐可能スタックになるわけで。

[[id:686]] 2002-06-13 22:33:08

これって、継続

＞属性入力欄に入力またはDragDropされた時の動作 (#13)

この、漏斗の考え方って、継続とパラレルじゃないですか。text widgetに対して、「値が確定したら取るべきアクション」をカプセル化して送ってやる、つまり継続渡し。

属性にfocusが移ったら、概念的には次のようなスクリプトが実行される：

expr.attr = textwidget.value

でもって、左辺値オブジェクトっていうのは要するに「値が与えられた時それをattrにセットする」って動作をするオブジェクトだから、クロージャに翻訳すれば

(lambda (value) (set! expr.attr value))

っていう「もの」。これを使って、textwidgetに「valueが確定したらそれをこいつに渡してね」っていうメッセージを投げてやる。

textwidget.value.passTo(左辺値オブジェクト)

ここで、object.passTo(ほげ) はobjectの値が確定したらそれをほげに投げてくれ、というメッセージを表記したものとする。

UIでなく、スクリプト中に上のような代入式が出てきた場合も同じように解釈されるとする。すると、代入に関しては継続渡しをしているのと同じになる。

で、通常の言語では、ユーザからの入力が別の手続きへの引数になる場合なんかに、継続渡しに変換するのがちょいとややこしい。

proc(textwidget.value, 3)

==> textwidget.value.passTo( (lambda (value) (proc value 3)) )

でもこの言語に関しては、手続き呼び出し＝フレームオブジェクトを作って引数をその属性にバインド、だから、属性への代入と同じように処理できる、と。

そうだとすれば、スクリプトの戻り値を扱うのに マクロないしはスクリプト(#2) にあるようにRESULTみたいな特殊なオブジェクト属性を用意しなくてもいい。スクリプトは「実行結果の受け手(左辺値オブジェクト)」を取ることにすれば。

なんて、つらつら考えてみました。--Schemer

----
-関数呼び出し以外の全ての事象(ここで問題にしている「代入」も含めて)を「行為」という1つの抽象概念で説明しようとするならば、行為とそれに必要な付加情報という意味での継続は、もしかして全ての事象に対して適用可能なんじゃないかな(^^; -戯
--つまりはワイルドカードって奴。最強。

-RESULTのかわりに、RESULTER(そんな英語ないだろけど)が渡されるってーか。インタビュアにマイクを渡される感じ？

-うーん。俺のOOPの捉え方だと微妙にズレるかな。俺は「止め絵」をやりたいんです。プログラムを走らせたくないんです。「処理屋に処理(の依頼)を投げる」って考え方から脱却(ぉぃぉぃ)したい。データを「置き」たいんです。まぁ継続でも止め絵は出来るとはいえ…


----
- 「止め絵」ですか… うーむ。私は適用範囲を把握してないかも。

- Dependency acyclic graphを作っといて、データフローにより計算が進む、というメカニズムは使ったことがあります。3D CGのオーサリングソフト(Maya)です。グラフを作っておいて、どっか変えるとぱぱぱっと計算が伝搬して結果が表示されます。ノードにスクリプトを仕込めたり、動的に属性を追加したりできました。ただ、スクリプト言語のOO化は不徹底で使いにくいものでしたが。

- 問題は、仕事でデータをつくるとすぐにグラフのノード数が数千というオーダーに達してしまうことでした。グラフを表示させてみると文字通りのスパゲッティ:-)

- 教訓は、グラフは作るのは簡単だがメンテは難しいなと。従来の言語で、大きな機能をモジュールで区切って、exportされた手続き以外でアクセスしないようにする、というのと同様に、ノード(オブジェクト)の塊を塊として扱える手段がないと編集が難しそうです。

- いや、実装レベルでは単にfacadeとなるオブジェクトを作るだけでいいのかな。viewerがその裏にあるものを隠せるようになってれば。 --Schemer

[[id:688]] 2002-06-12 05:53:27

継続渡しってコマンドパターン？

Re: これって、継続 (#16)
読んで思ったんですが、視点を変えると継続渡しっていうスタイルはコマンドパターンなのかなと。
# C++とか無名関数で処理を渡すという習慣がないのでオブジェクトで渡しているだけとか？　いやいやUNDOの処理まで考慮しているからなー。

----
- 継続渡しのイイところ、ってのは、関数の出口が一つでなく複数作れるところです。成功した場合はこっち、エラーになった場合はこっちに行ってね、というような呼び方ができます。ですんで、呼び出し毎にundoの場合の継続も作って渡してやることも出来ます。 --Schemer

[[id:760]] 2002-06-24 18:25:10

多返し値と引数との対称性を強引に引き合いに出す

> これって、継続 (#16)
>手続き呼び出し＝フレームオブジェクトを作って引数をその属性にバインド、だから、属性への代入と同じように処理できる、と。
>そうだとすれば、スクリプトの戻り値を扱うのに マクロないしはスクリプト(#2) にあるようにRESULTみたいな特殊なオブジェクト属性を用意しなくてもいい。

ふと、WiLiKi:Scheme:多値の議論を思いだしました。
あれは、関数の、入力値と出力値の扱いの対称性の話題でしたよね。

最初に俺が「RESULTという属性値で返しちゃえ」と思ったのは多分、
「入力も属性値で渡しちゃえ」との対称性が、頭の隅にあったんだと思うんです。

ということはあれかな。「名前付き返し値」(しかも複数有り)
とでもいうものを実装すれば、完全に対称になれる、のかな?(ぉ

そんな言語、使いやすいのかよ?、という素朴な疑問が(^^;;;;;

ついでにいえば、そこまでやっちゃうと、普通のObjectとどう違うの?という気しかしてこなくなる罠(^^;;;;;;;;;;;;;

----
ところで継続ですが、今回(?)の言語で継続を実現するには
まずその継続をどう用意するの?やっぱりObject使うの?
ではそのObjectが必要とする継続の機構はどうやって得るの?
というプリミティブ論争が再燃するような気が(^^;;;;

となると、どっちが「先」かという話になるかなと。
既に継続が有る系の上でコレを実装するならば、あの場面で(も)継続を使うと楽かつ綺麗でしょうね。

- 私が「継続」を持ち出したのは、継続を実装せいという意味では無くて、再粒度ダイナミックオブジェクトがクロージャとパラレルになるような感じで、この左辺値オブジェクトって継続とパラレルになるよなあ、と思っただけなので… --Schemer

-あ。そうじゃないかなとは思ったんですが(俺には)確信が持てなかったので、シュートコースを塞ぐ(謎)動作をしましたm(__)m -戯
-ただ、(少なくとも俺が当初考えた)左辺値Objectは、継続よりは汎用性は無い代物(に過ぎないの)で、パラレル(比肩と訳して良いですよね?)というほどのものではないようにも思いました…

[[id:715]] 2002-06-16 12:05:47

継続とフォーカス？

どちらかというと、継続というよりは、個々のオブジェクトが自分自身の
スレッドを持っていて、フォーカスが外れるとサスペンドするような
イメージなのかな。。
と思ってみたり。
それって継続と等価なのかもしれないけれど。

ーばし

[[id:716]] 2002-06-16 00:38:43

webアプリ版

GUIを作るのが面倒なら、いっそhtmlつーかCGIつーかでやる、という手も…?

他にもメリット(?)は有りますね。
-webは普及してるから、Objectをそのまま家の外(?)に晒すことが出来る。やって嬉しいかどうかはさておき…
- ブラウザに出来る(べき)こと (#15) で言うようなViewの仕組としてそのままwebブラウザが使えちゃうので美味しい。
--ほんとにそのまま使えるかどうかはダウト。「戻る」ボタンが往々にしてwebアプリの問題をややこしくしてる現状などを見るにつけ…

webだとボロいGUIしか出来ないけど、まぁどうせこっちもそんなに色々やりたいわけじゃないし。

CGIじゃキツいかな。Objectをいちいちファイルに落さないとならんようでは。JavaServletみたいな常駐型が望ましい。
-ファイル落としのPerformance劣化までは許すとしても、ObjectのIdentifyが面倒かも。スマートなObjectID→StringのMapping方法が必要だ。
--それこそDelphiでも参考にしたらどうだ？あれはForm上のComponentをNameプロパティで区別する。永続化するときはこれをアテにするし、DoubleBookingはExceptionを出すようになってる。一意名を自動生成するMethodも有る。
----
「自社ビル」 (WorldWideWeb) とか
----
JSPで汚い版を作ってみるテスト (#30) JSPで超素朴なものを一応作った。噂(?)の妙な言語とかは全く実装してないので、見る価値無いかもだが。
----
もしかして、Tikiプラグインを使って実装することは可能ではないか？(^^;;
-もし出来たら、ある意味とてもお洒落かも。

[[id:728]] 2002-08-25 20:36:31

インターネットに公開されたオブジェクト環境ってカッコイイ

Re: webアプリ版 (#20)

オブジェクトスペースをRWiki:PRb (データペース)のようにDBに格納する形にすれば、CGIでもかなりイケるような気がします。

逆にオブジェクトをどのような形でブラウズするか、スクリプトの文法をどうするか、そこらへんのほうが問題として大きいのでは。

# うまいUIでラッピングするとWikiやHyperCardのようなアプリケーションに``も''化けそうな。

----
CGIについては。
実装上、それも純粋にパフォーマンスの問題でしかないんですが、
状態をDBとして外に出すと今度は、そのDBとの接続を「オープン」するのに
結構な処理時間を食うというのが問題でして。
localDBでもFile.openが馬鹿にならなかったり。
DBが要請するデータ構造をメモリに(多少なりとも)展開するのは、それなりに重い処理です。

いちいちプロセスを終了しないことによって、そういうオーバーヘッドを無くせるわけです。
JavaServletやJavaOSの路線がこれですね。
ServletEngineをボロい計算機で使うと、Engineの起動は重いですが、動作中はあんまりしんどさを感じません。

最近はConnectionPoolとかいってますね。Database.closeすることすら惜しんでいます。

[[id:763]] 2002-06-25 00:35:27

DragDropを本当に使うか?

属性入力欄に入力またはDragDropされた時の動作 (#13) でDragDropと言っているが、本当にそれを使うべきか?
#いや、試作なんだから実装の詳細はどうでもいいんだが…とりあえず気になったので…

-DragDropは、UIとしてイマイチだという捉えかたが、昔から有る。たしかにボタンを離さずにズリズリするのは手が凝るんだよね。
-DragDropは他のやりかたに代替可能。たとえばコピーしたいものを「どこかに」置いておいて、あとでそれを「取りにいく」という手。ClipBoardだと思えばCopyPasteと大差無いことが判る。
-これならDragDrop非対応な環境(昔のJava awtとか、webブラウザとか)でもヤれる。ボタンくらいならwebでも使えるわけで。

[[id:729]] 2002-06-18 01:22:39

フォーカスは働きすぎである(?)

#↑この煽り文句は、LENSという言語の能書きのソレの、パロディですぅ

フォーカスのネスト (#14)

フォーカスと呼ばないほうが正しいのかも知れないけど、
実際にフォーカスとソレ(なんて呼ぶのかな)を兼用させてる世界は多いんで…

ソレとは、例えば、Copyするときの選択範囲みたいな概念のことです。

ValueもCopyの対象にしたい。Nameも対象にしたい。Name+Valueのペアも対象にしたい。
となってくると、Valueを「選択」した状態にすることが出来ないと困る一方で、
Name+Valueペアをペアとして「選択」することもまた出来ないとならない。

[[id:739]] 2002-06-18 16:23:38

Viewは当然ネストする

フォーカスは働きすぎである(?) (#23)

待てよ。Modelが階層構造を持つってのは論外だ(階層構造を打破したいのがそもそもこのソフトの主眼なんだから)が、
その断面(3次元物体を2次元に「投影」するかの如く)であるところのViewは、階層構造を持っていていいのではないか？
ある角度(?)から見た(=View)とき、階層構造が有るかのように見えるわけで。

で、そう考えると、フォーカスがネストなんてことを考える必要は、あんまり無くなるのではないか？

言い換えれば、左辺値Objectだか代入屋継続だかを、GUI操作において生成するのは、Viewの仕事なのかな？、と。
そのViewにおける親子階層関係を知っているのはViewである、ということ。

----
よだん：
Viewといえば、Script字面上でのViewという概念も、アリだよね。
a.b.c.d // C系文法だとして
っていうソースでのObject手繰りPathは、つまりそういうViewを見ようとしていることと、パラレル(用法これで合ってます?)だ。

[[id:741]] 2002-06-18 20:27:19

「ソレ」は『セレクション』のことですね

Re: フォーカスは働きすぎである(?) (#23)

ヒューメイン・インタフェース―人に優しいシステムへの新たな指針 (本棚)に提示されている新しいGUIモデルの案では、現在選ばれているセレクション、古いセレクション、２番目に古いセレクション、以下続く、という複数のセレクションを選択できるようにして、複数の箇所を指定する操作を簡単にしよう、とされています。
#僕はその箇所を読んでグラディウスのオプションを思い出しました。:)
それら複数のセレクションはそれぞれ見分けがつくようにコントラストに差をつけたり、小さな数字を付記させたりすることが考えられているようです。

[[id:742]] 2002-06-18 21:55:00

トリガーわすれてた(笑)

LispかSmalltalkの処理系をひとつでも (プログラミング)

タイトル参照。もー笑ってください。わははは…

>#永続化された情報から処理系の上に特定の状態を呼び出すことをRunと呼ばなければ。

そーですねえ。というわけで前言(プログラムはRunするものなのか？ (プログラミング))を少し訂正します。

プログラムはRunから始まる(ないしは、Runによって囲われている)ものなのか?、と。
(メイン?の)Runの始まりによって全てが開始され、それの終了で全てが終る、という世界観は、それほど快適(ぉ)なものなのか?と。

まあ、main()を無くせと言った人はいるけど、メソッド全部を無くせと言った人はあんまり居ないかもです。

というわけでトリガーの局所化。
個々のScriptObjectや、個々の「ScriptObjectを参照しているName-Valueペア」のところに、
Run(かEval)ボタンでもつけるってことにしましょーかね。

-あるいは、トリガーObjectってものを考えましょうかね。表示形態はボタンだったりするかも。
--[[MAX]]とか[[PureData]]には、BangというトリガーObjectが存在するらしく。

よだん：
>ウィジェットをキャンバスに置いた時点でそれがそのものとして動き始める

厳密にいえば、「動く」かどうかは別問題だと思っています。
もちろん動く権利が有るのは嬉しいことですが、義務だと言われると辟易しちまう。

あえて言えば望んでいるのは、「有り始める」ですね。
「動作」が「存在」の前提条件というか当然条件(そんな日本語無いぞ?)である、という感じには、俺にはどうにも思えなくて。
#人々は、心臓が"止まったら"死んでしまう人体の宿命に、思考が規定されてるんじゃないか?とまで思ってみたりする俺。

そういやこんなものも作ってみたこと有り鱒。
これぞ「置いた時点で即動く」の極み。
でもまぁ、これでお腹いっぱいというか。
しかもこれも、真の能動Objectは実は1つしか無くて(メトロノームがそれです)、それ以外は結局、データとしてソコに存在するだけ。

[[id:730]] 2002-06-24 16:52:37

セレクション以外のパターンもありますね

> 「ソレ」は『セレクション』のことですね (#25)

たとえば、あるモノに対応するViewを、こんな感じで表示することにしたとする。 (模式図ですが、ほんとにGUIでこんな風に)

([x][c][v] hogehoge)

xcvってのは、Mac/winでお馴染みの、cut/copy/pasteを表します(ぉ
いちいちcutとか書くのが面倒(＆狭苦しい)なんで1文字で略したんですが、つまり、
データ(ここではhogehoge)を、(今それが参照されてるObjectから)「cut」「copy」するとか、
(今それが参照されてる場所にClipboardのデータを)「paste」するとか、
そういう命令をするための「ボタン」が、そこに表示されてるという風にしようかなと。

で、そうすると前述のように構造を持ったものを扱おう(=表示したり編集できるようにしたり)とすると、
例えばName-valueペアなら、

([x][c][v] ([x][c][v] name1) ([x][c][v] value1))

という風に表示することになっちゃうかなーと、思ったものでして。

更にname-valueペアの束であるところのHash君あたりだと、

([-][c][-] ([x][c][v] GlobalName1) (
([x][c][v] ([x][c][v] name1) ([x][c][v] value1))
([x][c][v] ([x][c][v] name2) ([x][c][v] value2))
([x][c][v] ([x][c][v] name3) ([x][c][v] value3))
)
)

ってとこか？
え？くどい？まぁそのとおりなんですけどね…
そりゃそうと括弧がたくさん有りますが某言語とは多分無関係です(ぉ

GlobalName「を」copyしたいことも有ると思うので、ここにもボタンをつけると良いかなと。

[-]は無効(灰色)ボタンっす。Hashedじゃなく参照モデルなObjectなので、cutやpasteをするためのコンテナが定義できないので、
ボタンは削除or灰色化されています。でもObject(の参照)をcopyするっていう考え方は有っても良さそうな気がするので、cボタンは存続。

[[id:834]] 2002-07-03 15:06:35

これってWinのレジストリエディタみたいだ？

セレクション以外のパターンもありますね (#27)

モデルがTreeでなくGraphであることを除けば、かなりタイトル参照な感じだなあ(^^;
これじゃやっぱり「つまんない」だろうか？

[[id:877]] 2002-07-15 13:41:39

ScriptObjectのrunの結果は、必ず継続を返す(返し値は常にそれダケ)、ということにするとどうなる？

マクロないしはスクリプト(#2)
いや、どうなるっていうか、まぁその…

走り終わった継続(?)Objectの属性として、いわゆる普通の返し値に相当するものが入っている…かも知れない…という。

[[id:954]] 2002-08-08 13:57:55

JSPで汚い版を作ってみるテスト

[TikiGuion:六本松] http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=%CF%BB%CB%DC%BE%BE からどうぞ。
なんかいいかげんな公開のしかただなあ…

-020813 ちょっと直した

[[id:972]] 2002-08-13 20:05:16

calcpad

Cygwinでも動くR5RS準拠のScheme処理系rhizome/pi (プログラミング言語:Lisp)の配付書庫に入っている
demos/ww/calcpad.scm というアプリケーションが非常に面白そう。
ww というのは Windows-api Wrapper ライブラリだそうです。

以下に配付内の README.j から引用します。

----
calcpad.scm
計算用紙です。マウスをドラッグしてセルを作ります。各セルにはラベル及び計算式が付随します。ラベルは任意の文字列、計算式はSchemeのS式を含み、セル内には計算式を評価した値が表示されます。計算式内では後述の'?'マクロを使用して他のセルの値を参照できます。再計算はセルの作成順で、これを変更する手段は用意されていません。メニューのWindow->Consoleで別のウィンドウが開き、その中でread-eval-printループが実行されます。通常Schemeの式を評価できますが、以下のマクロ・手続きがセルを参照・操作するために用意されています。
　：
　：

[[id:1071]] 2002-08-29 16:08:03

top recent

HashedWiki version 3 beta
SHIMADA Keiki