| (*) a standard haskell' api providing the commands of ghci/hugs
| style interactive systems would be a start, together with an
| annotated AST, parser/typer/pretty printer. more detailed
| specifications could be left for future revisions.
A reasonable suggestion, but I'm unsure what you actually have in mind.
what I have in mind are things to come, which would be quite
different from the initial steps we could reasonably expect Haskell'
to take. initially, a separate libary may be an acceptable start; but
ultimately, I don't want two separate Haskell implementations
shipped for each installation.
for the moment, I'd like the Haskell' committe to say this is useful,
and commit to making a start, then see how far we can get.
at the very least, Language.Haskell needs to be expanded on,
to cope with modules, to provide type information, and to cope
with language extensions [also, one might want to check whether
SYB-style traversals, which are so useful for annotated ASTs,
are permitted within the limitation of Haskell']. but even there,
adding and maintaining a type/module system implementation
would be more work than exposing the existing one, and the
same goes if we want loading/evaluation as well.
the difference between such an extended Language.Haskell and
the standardized interface I suggested is that the former is one
naive implementation of the latter. the difference between an
extended Language.Haskell and the implementation by reflection
I had in mind is that the latter reuses the underlying Haskell
implementation to provide the same interface more efficiently
(even if that might involve translating between internal types
and those in Language.Haskell+).
It is meta-programming because it allows Haskell programs to
operate on representations of Haskell programs. It may use
reflection to do so, if it permits Haskell programs access to
their own representations and to parts of the implementation
they are running on.
I don't say to do it all perfectly for Haskell', but just to make
a start that goes beyond current Language.Haskell. For that
start, it may still be sufficient to leave most things in an library
(**), and it doesn't have to support everything GHC's API
does (though it does have to define implementation-independent
interfaces).
But ultimately, there will be ramifications for future language
definitions (how to pass from programs to representations
and back? how to type these things? how to extend programs
at runtime? ... all the issues common to Template Haskell,
hs-plugins, and type Dynamic [as done in Clean, not the
poor man's version of Haskell]). Simon M adds extensible
data types to the list. I'm sure there's more, once we start
looking.
I find it interesting to note the the folks who claim this is
a libary-only problem are willing to put up with lots of
non-Haskell' hacks, not to mention partially functioning
work-arounds for features that belong in the language
definition (a proper type Dynamic, for instance, with
support for polymorphism, and with a way to address
the issue of representations of types originating from
separate programs).
I'd prefer to flush out these secret hacks hidden in so-called
libraries, and to call a language feature a language feature.
Cheers,
Claus
"Ideals are like stars. You may never be able to reach them,
but you can navigate by them."
(**) one of the attractive things about early Haskell reports
was the combination of language definitions and libraries.
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
