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.
If you want to embed a compiler or interpreter in your program, then
OK, but the compiled or interpreted language need not to have much
in common with the language the program is written in. It's cool if
it's again Haskell because Haskell is cool (and because it's easier to
exchange values) - not because each language should contain a compiler
of itself! The compiler used to produce our program and the compiler or
interpreter working inside our program are completely different beasts.
I would be very careful in designing "reflection capabilities" in
Haskell. Especially I'm afraid of producing an inelegant solution
which would be abused because of either lack of some other mechamisms
or the laziness of a programmer ("laziness" not in FP sense).
I agree that we should design a way of allowing dynamic linking of some
plugins. IMHO it should be clearly separated from the main language
and nicely designed for dynamic linking of additional code, not for
examining the program internals by the program itself. Internals that
are not relevant for program execution should go away at the time of
compilation. Identifiers used in the source should go away.
IMHO it should be a sort of FFI specification, allowing linking at
runtime. May be Haskell-centric, but formally quite independent of
where a program using it came from. Not expressing all the details of
Haskell language in first-class values. Not needing to parse Haskell
code at runtime to link a module!
What I mean by abusing an embedded compiler. For example building
function names from pieces and parsing the resulting expression instead
of creating a mapping between function names and actual functions.
Or translating an arithmetic expression entered by the user to Haskell
expression instead of writing a parser of arithmetic expressions.
Or passing values between functions by their source name instead of
by themselves. Or doing things that are hard to fit in the type system
instead of expressing them differently or improving the type system.
I don't know what is the GHC and Hugs integration going to look like.
I have good feelings about it, only I'm afraid of abusing it or
implementing some features along with lack of some more important ones.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
