Prelude/main magicks?

[Niklas Broberg]

I wrote:
> > Taking Lava, a hardware description language, as my example, I would 
>argue
> > that many users of Lava don't really care if it's embedded in Haskell or
> > whereever it comes from, they would just use it.   ....
> >
> > 	lavac Main.hs
> >
> > where lavac is could simply be a script alias of
> > 	ghc -fprelude-is Lava
> >
> > By using an explicit Lava compiler you declare that this is indeed a 
>Lava
> > program, and you don't expect it to work in any other setting, in 
>particular
> > not with a Haskell compiler like GHC.
> >
> > And in the same line of thinking, I would want a way of specifying 
>suffixes
> > of input source files. It would be much neater to call your files 
>Foo.lava
> > or similar, and be able to tell GHC to treat them as normal .hs files, 
>i.e.
> >
> > 	lavac <== ghc -hssuf lava -fprelude-is Lava
>

Malcolm Wallace wrote:
>Very intriguing ideas.  However, I'm sure there are easier ways
>of implementing a 'lavac' (or other domain-specific compiler) than
>adding new flags to ghc (and by implication, to every other Haskell
>compiler as well).
>
>All you really need is to hook up a rather simple pre-processor.
>For instance,
>
>     #!/bin/sh
>     { echo 'module Main where\nimport Lava\n' ; cat $1 } >`basename $1 
>.lava`.hs
>
>If you want an automatic file association based on suffix, then
>something like hmake can do the mapping of .lava onto .hs via this
>little pre-processor script.  This solution has the additional benefit
>that it is compiler-agnostic.

Aye, it would be simpler, I sure won't argue that.
But then I might have to create another pre-processor to make it work on 
Windows, and a third for some other system. And then for the next EDSL that 
comes up, the designer of that will have to do the same thing. Is the sum of 
all that work still simpler?
Clearly it would be better for the EDSL designer to know that someone else 
has thought of these things once and for all. I'd like to see my approach as 
the high-level one where the designer just has to think about _what_ he 
wants, whereas your suggestion would be the low-level approach where the 
designer must also know _how_ to get what he wants.

>From my perspective what it comes down to is, is this a recurring pattern? 
If a new EDSL comes around once in a blue moon, then one might argue that 
the work needed to add these flags to GHC would be ill-spent. But if EDSLs 
are a more common development pattern, then surely it must be the supreme 
goal of any compiler writer to make life easier on the users? =)
And if we think one step ahead, then it isn't all that difficult to imagine 
that such a feature might even encourage the design of more EDSLs, which in 
my book would be a Really Good Thing (tm).

As for being compiler agnostic, then sure, that would be a good thing for 
any library.
But there are already tons of nice extensions added to GHC that aren't 
implemented by other compilers, making any code that makes use of these 
extensions compiler-specific. Why would this be different?
And as for those users of Lava I mentioned in my example, I doubt that they 
would even know of or care about the existence of other compilers and/or 
interpreters than the one(s) the language designer provides them with. After 
all, from their perspective those other tools are for Haskell, not Lava!
That said, I sure wouldn't mind seeing these features added to other 
compilers as well. =)

I could even volunteer to try to add these features to GHC, if the team 
would accept the help. There are still the issues of update-compatibility 
for the team to deal with, but I stubbornly believe that they won't be that 
bad. ;)

I'm starting to get a bit worried though, am I completely alone in this? I 
would have thought at least someone would agree with me and support me in 
wanting such features, so please, anyone? =)

/Niklas

_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE 
download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/