This discussion feels like deja-vu all over again!
What is wrong with the various generic programming extensions that have
already been discussed? Derive, PolyP and their progeny?
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-212-697-0184 voice The Easiest Way To Shop
On Wed, 26 Jan 2000, Fergus Henderson wrote:
> On 25-Jan-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> > Tue, 25 Jan 2000 18:12:32 +0100, jwit <[EMAIL PROTECTED]> pisze:
> >
> > > What I'm getting at is some kind of way to get your
> > > hands on an abstract syntax representation of a Haskell
> > > expression/datatype/module, modifying it, re-typechecking it,
> > > and then transforming it back into a Haskell value.
> >
> > In other words you want to embed a Haskell compiler in your program.
> >
> > It could be useful in practice sometimes, but it's a very far concept
> > from a simple extension of the language to allow reflection.
> >
> > Haskell is quite complex and can be compiled. IMHO the distance
> > between the source code and the running program is very big in the
> > case of Haskell. In other words, much is done at compile time instead
> > of runtime. I like this principle, because it allows an elegant and
> > powerful language with lots of static checking and optimizations,
> > even though it makes reflection harder.
> >
> > A function definition is the specification of what an identifier
> > means in its scope, not the physical bytes of its compiled or
> > source code. It can be inlined, instantiated, unfolded, analyzed for
> > strictness, rewritten using RULES etc. - it does not have to appear
> > in a physical form that can be examined by the program. C's dlopen()
> > is different because C is a more low level language - in C there is
> > a closer correspondence between the source function and the execution
> > time object.
>
> Well, Mercury has the same approach as Haskell, in the sense of being
> a language which at least aims at being elegant and powerful with
> lots of static checking and optimizations. But we do support
> dynamic linking (on some platforms), using an interface built
> on top of dlopen() and dlsym().
>
> Supporting dynamic linking need not inhibit optimization to any
> significant degree, I believe. At worst, you may need to disable
> inter-module dead-function elimination. Even that need only be done
> if dynamic linking is used.
>
> The next stage of support for reflection, being able to at run-time
> get your hands on an abstract syntax representation of a Haskell
> expression/datatype/module, does have a higher cost. The compiler
> needs to keep information around at run-time which it would otherwise
> not need. In Mercury we currently support that for types, but not
> for expressions or modules.
>
> One way of reducing the cost of this feature is to require
> programmers to explicitly mark with some declaration
> those entities for which the compiler should keep the
> information around at run-time. ISO Prolog takes this
> approach; predicates for which you can use the
> `clause/2' builtin to look up their definition
> need to be declared "dynamic" using a `:- dynamic' declaration.
> Ada takes the converse approach: by default, it keeps
> around some tables to allow you to convert enumeration constants
> into strings, but there is a standard pragma which allows
> you to suppress that for a given enumeration.
>
> The final stage -- being able to take a representation of
> a Haskell expression, re-typechecking it, and then transforming
> it back into a Haskell value -- does not actually _require_
> any language or runtime support, I think; you can program
> it in standard Haskell. Though I guess some support might be
> required if you want to introduce new types at run-time.
>
> --
> Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
> WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
> PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
>
