Re: Eval - Pro's and Con's

[Chris Dollin <kers@hplb.hpl.hp.com>]

Someone tangled in a sequence of attributions says:

| This problem might be simplified by having the EVAL module define
| object types to represent syntax-independent program-fragments.  These
| might be necessary anyway, for a multiple-syntax language.  EVAL would
| be handed such structures, instead of syntactic expressions.  (Is it
| the Pop language that has these sorts of structures?)

No (not yet, anyway). Pop [*1] has an EVAL equivalent, ``popval'', which takes
a list and compiles and executes the program (fragment) in the list. Unlike
EVAL, which takes a list which is more-or-less a syntax tree, popval's list is
just a token sequence. Pop also has ``compile'', which takes an input source
and ``compiles'' (ie, executes) that; the source is either a file identifier
(string, word (like a symbol), device) or a character repeater.

Pop programs also have access to the ``code-planting'' routines of the Pop
compiler, so they can generate code on the fly. This makes writing compilers
for suitable languages (Lisp, ML, Prolog, Scheme, and of course Pop itself)
fairly straightforward. Perhaps it is this that the original poster was
reminded of?

[*] As appearing in the Poplog environment. Further Pop questions can be
directed to comp.lang.pop.

Regards,    | "Layered protocols give the software implementor a chance to
Kers.       | ruin his performance in each layer." - Don Gillies