[Mono-devel-list] Using System.Reflection.Emit for interactive languages

[Jim Blandy]

Miguel de Icaza <miguel at ximian.com> writes:
> > I've been playing with the System.Reflection.Emit stuff, and I have
> > some questions.
> > 
> > - Is it possible to re-define a method?  Is there anything less
> >   horrible than MethodRental.SwapMethodBody?
> > 
> > - Is it possible to delete a method altogether?
> > 
> > - Is it possible to create anonymous modules, types, and methods?
> 
> It would be useful if you gave us some background information on what
> you are trying to do, to give a better answer.

Yeah, Paolo's reply made me realize that my questions weren't very
well-phrased.  I'm still in the process of figuring out exactly what I
don't understand.  :)

I'm experimenting with a Lisp-like language for Mono.  The idea is to
have Lisp's syntactic flexibility (s-expressions; hygenic macros), but
Mono's data world, to be able to take advantage of Gtk#, the database
support, the XML support, and everything else that anyone hooks up to
Mono.  It's a chance to have a Lisp that doesn't isolate itself from
the rest of the programming world --- to the extent that that world
embraces Mono, as I think it will.  The language will live or die on
its merits as a medium of expression, not on the quality of its
library.  Tachy is a nice start; there are a few things I want to do
differently internally.

But while I'm putting good Mono citizenship above compatibility with
Scheme or CL, I'd like to support as much of the rest of the Lisp
paradigm as I can.  That's why I posted my idea about classes that
implement IList, but still resemble the lists used by traditional
functional languages.

In particular, supporting lambda is important.  I got hung up on
anonymity, which I see now isn't really the issue.  What's more
important is whether the code representing the body of a lambda can be
GC'd when all closures referring to that body are dead.  Paolo said
this doesn't happen; but as I think about it, I'm not sure it's a big
deal for the moment.

More interesting is how we can support interactive development.  If a
user is redefining classes as they work, then their changes really do
need to be reflected in the normal way in the dynamic assembly they're
operating on.  Treating the System.Reflection classes as your internal
data structures only works if nobody else is going to reflect on your
assembly.  But since my whole goal is to work well with other Mono
languages, I can't afford to have much of a dichotomy between the view
I give my user and the view other languages will have of the
assemblies my user generates.  If it looks like a spade,
System.Reflection had better call it a spade, too.

This is a fuzzy requirement: obviously, getting the effect of
anonymity by choosing strange names is something that's visible via
reflection, but it's hard to imagine it causing much of a problem.  In
this case, you don't mind being told, "pay no attention to the man
behind the curtain named '<Proxy-0>'".  But if I'm working
interactively on an assembly that exports a class named 'Foo', my
redefinitions had better show up under that name, in the simplest,
most obvious way.

It seems like redefining classes on the fly isn't something that's
been thought through already; that's not too surprising, since it's a
real rat's nest in some ways.  The "static" information the compiler
has about the class isn't entirely static any more.