Linear Lisp -- Linear Lisp EVAL

Linear Lisp EVAL

Linear LispのEVAL

It is interesting to analyze the operation of a traditional Lisp interpreter written for this Linear Lisp Machine (see Appendix).

このLinear Lispマシンのために書かれた従来のLispインタプリタの操作の解析をすることは興味深い(付録を参照)。

Since traditional Lisp utilizes "applicative order" evaluation, an argument used multiple times is only evaluated once.

従来のLisp「適応命令」評価を利用しているので、複数回使用される引数は一度だけ評価されます。

The traditional problem in "call-by-need" evaluation has been the shared flag variable which indicates that the argument has already been computed; Linear Lisp utilizes its arguments exactly once, with an explicit copy required for additional uses, so the applicative-order/normal-order issue is moot and the shared flag variable is not necessary.

「必要により呼ぶ」評価における従来の問題は引数がすでに計算されたことを示すフラグ変数の共有でした：Linear Lispはまさにその引数を一度だけ使用します、さらなる使用のために明示的なコピーを必要とします、そのため適応命令/通常命令の発行は現実的な意味がなく共有フラグ変数は必要ありません。

Our use of hash consing requires transitive strictness on both of its arguments; otherwise EQUAL'ity could be decided prior to the determination of a lazy value, since EQUAL and EQ are equivalent for hash conses.

私達のハッシュコンシングの使用はその引数の両方で推移的な厳密さを必要とします:そうでなければ(EQUAL)等価性は遅延した値の確定に先立って決定される可能性があります、EQUALとEQはハッシュコンスに対して等しいので。

Thus, parallel evaluation of arguments can be supported, but not laziness.

このように、引数の並行評価はサポートされるが、遅延はサポートされない。

On the other hand, the implicit synchronization required to strictly resolve a "future" [Baker77] can be efficiently performed with a swapping operation [Herlihy91].

一方で、「未来」を厳密に解決するために必要とされる暗黙の同期はスワッピング操作で効率良く実行することができます。

Since the association list of variable bindings must be destroyed in order to search it anyway, the "shallow binding" technique utilizing "rerooting" [Baker78] is essentially optimal.

変数束縛の連想リストは探索のためにとにかく破棄されなければなりません、「再定着」を利用する「浅い束縛」テクニックは本質的に最適です。

We can destroy the Lisp program during evaluation in the manner of combinator/graph reduction [Turner79] [Kieburtz85] [Kieburtz87] [Johnsson85] [Johnsson91]; indeed, we must destroy it, since we cannot reference it otherwise, as all of its reference counts are one!

私達はコンビネータ/グラフリダクションの方法での評価の間にLispプログラムを破壊することが出来ます：本当に、私達はそれを破棄しなければなりません、それを他の方法で参照することはできないので、その参照カウントは実際すべて1です！


>> Lively Linear Lisp
>> Abstract
>> Introduction
>> A Linear Lisp Machine
>> A Linear Lisp Machine with FREE, COPY, EQUAL and Assignment
>> Dataflow-like Producer/Consumer EVAL
>> Reconstituting Trees from Fresh Frozen Concentrate
>> Linear Lisp EVAL
>> Implications for Real Multiprocessors
>> Conclusions and Previous Work