Hi Tomas,

> variable/symbol is searched in a stack of dictionaries while picolisp
> has shallow binding where the value is in one place (dictionary) and
> saved/restored into/from stack frames, it made me think that such

That's right.

> functionality like 'save' and 'restore' in postscript might be harder
> or less efficient to implement in picolisp because I would need to
> save all bindings of all variables (this would not be problem if the

True. This could involve very many symbols.

The functions 'eval' and 'run' do something equivalent, though kind of
reversed, as they change the environment back to a previous one by
modifying only those symbols that where re-bound meanwhile.

> What were the reasons that you decided for shallow binding in picolisp
> and would you think it is still better even though the implementation
> language would be javascript and not C or assembly?  Or, in other

As you say, the main reason is speed.

For an interpreter there is probably no faster way. Switching to an
implementation language like JavaScript would not improve the speed, as
you probably will not be able to use the variables of the language for
the variables of the target language.

For a compiled system, the opposite is true. Then you can statically
compile the offsets into bind frames, and get a high runtime speed, but
a low interpretation speed.

> words, what does shallow binding gives and takes away over the deep
> binding except the raw access speed of a variable value?

Not much as far as I remember (it's been a long time ago ;-)

But the speed difference is considerable. Especially as I want functions
and variable bindings to behave in the same way. Imagine that for each
and every function call a lookup through a list of environments has to
be done. For shallow binding, both finding the code of a function and
the value of a variable is a single machine instruction like

         ld A (C)  # Get VAL

possibly followed by the call itself

         jmp (A)  # Eval SUBR

And this is basically all what the interpreter is doing. The actual work
happens in the jumped-to functions.

- Alex
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to