|
|
Re: (Re-)Introducing the Heron Programming Language
|
Posted: Mar 16, 2010 1:45 PM
|
|
> Thank you for the replies.
>
> > 1) Even for introspection, the type data needs to be
> > present and it will affect the size of the executable.
> I
> > don't know if it can be kept separatelly - do you know
> a
> > language which supports such option?
>
> I do not know such a language, but I do not think it is
> difficult to do. A compiler could create two modules for
> each source code file: one with the actual code, and one
> with the metadata. If the client code uses reflection,
> then it should also link with the metadata module. The
> metadata are always different symbols from the actual
> code.
As usual, your intuition is not too far off, Achilleas!
The actual solution must be more object-oriented. You should only get a reference to the code module from an object that governs access to both the code module and metadata module. This is different from how things are done in .NET. IMHO, as a consequence, it significantly complicates the design of various subsystems such as the Profiling API, which must maintain shadow stacks in order to properly trace tail calls - evil voodoo!
> >
> > 2) Affecting optimization is still a concern. Unused
> > methods cannot be optimized away because they might be
> > called dynamically.
>
> For dynamically linked libraries, this problem does not
> exist, because the compiler does not optimize anything
> away, since the libraries are loaded dynamically.
Correct. Dynamic linking literally means dynamic linking. If a bytecoded method does not need to be JIT'ed, it will not be. Only JIT-cache what you need to, due to memory pressure. However, some JIT's have a hard time recognizing that a piece of JIT-cached code will never be used again, ever.
> For statically linked libraries, and for source code, the
> problem can be solved by optionally marking symbols not
> eligible for reflection, including whole classes and
> modules.
>
> >
> > 3) To enable emitting code at run-time, basically a
> > compiler needs to be embedded with the executable.
> >
> > I hope I answered your questions.
>
> The compiler can exist as a module which is linked only if
> used.
>
> Anything else I am missing? so far, I don't see reflection
> being a problem for a system language, given the choice to
> avoid it if not desired, just like garbage collection.
You should read papers by Greg Morrissett. He created a typed assembly language that supported reflection.
Also, there is a difference between procedural introspection and procedural intercession (which is more general than what Reflection.Emit allows, since this involves advanced code marshaling services for thread-safe, memory-safe code-update-in-place). Recently, Andrej Filinski has been doing some exciting work in category on monadic reflection, too. You may also want to check out the recently proposed language ARCHON, which has some interesting thoughts on reflection.
But, IMHO, the coolest reflective system devised so far is Alessandro Warth and Ian Piumarta's OMeta PEG parser: it is so mischievously ingenius.
|
|
Previous Topic
