> i thought that in the inferno sh the bit inside the {} was parsed, and later
> converted
> back to a string if passed to a command (uniform treatment of {} as in `{},
> and you
> discover your syntax errors in good time). i don't remember what es did.
that's true, but es did exactly the same thing. the internal representation is
the
shell's syntax tree (which means that evaluation of sub-blocks is reasonably
efficient,
unlike tcl, which has to rescan the string each time through), but the string
representation
should generate exactly the same tree when parsed, so for most practical
purposes,
it can be treated as if it *was* verbatim (excess white space is removed, as
are comments).
i could have used a similar approach to your v7 "export a function containing
the code", but
it's nice to be able to pass code fragments around to unrelated processes, for
instance
to remotely execute some code on a file server.
the other thing the inferno shell allows, which i thought quite neat at the
time,
is that a running program can load itself as a module into an instance of the
shell,
and define shell "builtins" that call back into the program, thus giving
scriptability
at little cost. for instance, the window manager does this for its
initialisation script:
the "menu" primitive adds a new item to the window manager menu (its argument
is,
of course, a shell command to run when the item is invoked).
