[...]| Is there some simple way to make GHC treat our own base library in the same | magic way as the Prelude, so that it is always implicitly available?
Simon Peyton-Jones wrote:
A -fprelude-is flag would certainly be implementable. The questions are
a) Would it be desirable? After all, there isn't much difference between
module Main where { ... } ghc -fprelude-is Foo Main.hs and module Main where { import Foo ... } ghc Main.hs
And arguably the latter it better because the code is more self-describing.
Well, that all depends on your perspective. =)
Haskell is great as a host for embedded domain specific languages (DSL) and there are several such languages already (Lava, Pan, Fran, WASH etc.). Such languages could from one perspective be seen as nothing more than libraries for Haskell directed at helping you write programs within a certain domain.
From this point of view, arguably it would be more descriptive to explicitlyimport these libraries into any written modules, they are after all "just libraries".
But if you choose the perspective that these are indeed languages in their own right, aimed at applications within their domains, I would argue the other way around.
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. I have friends who study Lava solely for its application to hardware description, and these same friends would never dream of taking a course in Haskell (or any other general purpose language). From this perspective, Lava is the Language, and Haskell is reduced to a backend. Then it would make sense to talk of things like a Lava compiler, to invoke directly on your Lava source files. And said compiler would then preferrably be able to provide the users with the domain-specific functions that make up the "Prelude" of its domain, without the users having to import anything.
I would definitely argue that from this perspective, the former would be far more descriptive in the following guise:
module Main where { ... }
lavac Main.hswhere 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
In my opinion having these flags or not boils down to whether or not GHC aims at being "the perfect tool" for "embedded compilers", much as Haskell is allready "the perfect language" for embedding domain specific languages.
Simon Peyton-Jones wrote:
b) GHC has a myriad of flags. Every time we add one, even a simple one, it costs us an hour or two, and (worse) potentially interacts with stuff in the future. Each one is "just one little flag" but they do add up!
Aye, there's always a trade off, isn't there?
I wouldn't claim to know how these flags could interact with things in the future, but seeing that there is already a -fno-implicit-prelude flag makes me wonder if generalising this to explicitly specified "preludes" makes it much worse?
For suffixes of input files, I can forsee some problems such as what happens if you say -hssuf lhs for instance, should the compiler then treat it as a literate or not-so-literate source file? But I'm sure such issues can be properly disambiguated, and after that it should (hopefully) be a simple matter of pretending that the specified suffix is actually .hs.
I'd be interested to know if lots of people thought this particular one was very important, though.
So would I. I sure think so. =)
I wrote:
[...]| And while I'm asking about magicks; In our language we have a special | function, called "page", that we require be present in "executable" modules, | much like a main-function.
Simon Peyton-Jones wrote:
This seems less widely applicable to me; I suggest you use the ideas suggested by others in their replies.
I agree, this is not general enough and cannot be said to be applicable to embedded DSL since most applications written in such languages would still rely on an ordinary "main :: IO ()" function.
We still have no really good solution to our problem though, so suggestions are more than welcome. The problem now is to know which modules that must have said "page" function, i.e. which are the "executables"? If we could get the hs-suf extension I suggested above, then we could solve it by giving another suffix to "executable" pages, but for now we need to hack our way around it.
/Niklas
_________________________________________________________________
Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
