> 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/
_______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
