RE: Erlang challenge

["Anton van Straaten" <address@hidden>]

Steve Dekorte wrote:
> On Sunday, June 8, 2003, at 11:24 AM, Anton van Straaten wrote:
> >> Btw, does Evaling a string at runtime involve a C compiler being
> >> spawned?
> >
> > If that's what you want, sure.  Gambit, for example, has the usual
> > 'eval' function which interprets code at runtime, but it also has
> > a 'compile-file' function which will compile a source file, through
> > C, to an object file.  The resulting object file can be dynamically
> > loaded at runtime, on platforms which support dynamic loading.
>
> Is code=data like (I've been told) it is in LISP?

In Scheme, code=data means roughly the following somewhat interdependent
things:

1. Program source is represented using a parenthesized representation of a
nested list structure.
2. The 'read' function converts text input from the parenthesized list
representation, to Scheme list values.  Once this is done with source code,
the "code" is essentially in the form of an abstract syntax tree,
represented as a nested list, which can easily be programmatically
manipulated.
3. The 'eval' function converts Scheme list values to executable code
(internally) and evaluates that code.  This can have the side effect of
modifying the environment, e.g. defining new variables, including functions,
or mutating data structures.

Scheme interpreters use a read-eval-print loop (REPL) which uses read & eval
to evaluate input and print the results.  Compiled Schemes usually support
including a REPL in a target program.

I would say point #1 above is the central meaning of code=data in the
context of Lisp & Scheme, though.  To a compiler or interpreter, obviously
code is data, in any language.  However, the syntax of Lisp/Scheme code
blurs the line between code and data in a way that's not possible in most
other languages.  The full effects of this are hard to summarize - very
powerful macro systems are just one consequence.

It's sometimes claimed that with appropriate parsing tools etc., a more
syntax-heavy language could provide similar capabilities.  In practice, none
have actually done so.  One of the benefits of code=data in practice is
similar to the benefit of using text formats for specifying configuration
data in an OS: it allows existing tools to be used in the manipulation of
that data.

To duplicate the code=data capability in a syntax-heavy language, you'd have
to provide a rich API for reading and manipulating code.  Lisp & Scheme
don't actually provide such an API: they simply give you the code in nested
list form, and it's easily manipulable and usable in that form because it
mirrors the structure of the source.  The AST for a syntax-heavy language is
much more difficult to manipulate, since it's full of extraneous stuff (take
a look at what Python offers in this area, for example).

> If so, can you still introspect that data in these C compiler schemes?

That's outside the scope of the Scheme standard.  In general, even in many
interpreted Schemes, no link is maintained between source and executable
code, except for system purposes like debugging.  However, since evaluation
can be done under program control, it's easy enough to create Scheme
programs that do maintain such a link, and this can even be encapsulated and
made transparent via macros etc.

> If so, what happens when you modify the data?

If a program keeps track of the source to a function, then modifies that
source and wants to use the modified function, it would simply have to
'eval' the modified source.  The modified function would replace the
original function, as long as either the source or the code which evaluated
the source contained the appropriate 'define' or 'set!'.

> How does debugging work?

Depends on the implementation.  In a very basic Scheme, debugging may be
little more than dropping you into a new REPL in which you can evaluate
code, inspect variables, and run some debugging commands.  In full-featured
Schemes, such as PLT, full GUI debugging is supported, with full links
maintained between source (including macros) and executable code.

For anyone who designs or works on languages, I highly recommend
investigating Scheme, more than superficially.  Scheme has been a laboratory
for language research, and there's a lot that can be learned not only from
the language itself, but also from the wealth of implementations that
explore almost any aspect of language design you care to name.  And of
course, books like SICP and EOPL, and a large academic literature, will
become more accessible and useful.  Much of this has relevance far beyond
Scheme, as I was arguing earlier in connection with EOPL.

Anton