Prelude/main magicks?

[Niklas Broberg]

I wrote:
>| 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 explicitly 
import 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.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

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/