Re: Erlang challenge

[Matt Hellige <address@hidden>]

[Steve Dekorte <steve@dekorte.com>]
> 
> 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? If so, can you still 
> introspect that data in these C compiler schemes? If so, what happens 
> when you modify the data? How does debugging work?

Given what I know of Io, my guess is that you're really interested in
something that isn't normally covered by Lisp-style code=data, what
I'd call reflective reification. Scheme does not, in general, allow
you to decompile or reify function values into their code, either as a
string or as an AST. There is a good reason for this (aside from
performance/compilability concerns). Since "functions" are really, for
the most part, lexical closures, it's not clear what the meaning of
the code for the function would be outside of that lexical context.

So in Lisp, code=data means that the abstract syntax is structurally
isomorphic to the concrete syntax, anything you can write in the
concrete syntax will parse into abstract syntax, but only a subset of
possible ASTs are actually valid programs (acceptable to eval).

Code=data does not mean that the runtime representation of programs is
convertible to or reifiable as the AST that would produced it. For
that reason, whether the code is compiled or interpreted doesn't
matter so much. Obviously a language like Io that attempts to provide
a full two-way convertibility between ASTs and executable program
denotations would need to address this issue, both for reasons of
efficient compilation (if that's a goal) and for reasons of reasonable
scoping and closure semantics.

Matt

-- 
Matt Hellige                  matt@immute.net
http://matt.immute.net