Friends for --print-libdir
I think there should be a GHC option --print-sharedir (or you could call it --print-datadir), corresponding to ghc --print-libdir. Thus on our system ghc --print-libdir prints out /home/linux-bkb/ghc/ghc-6.2.1/lib/ghc-6.2.1 and I would like ghc --print-sharedir to print out /home/linux-bkb/ghc/ghc-6.2.1/share/ghc-6.2.1 At the moment I use ghc --print-libdir | sed -e 's+/lib/\([^/]*\)$+/share/\1+g but this isn't exactly the happiest of solutions. The reason my scripts want access to the share directory is that they want access to HTML files and Haddock interfaces stored there. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Friends for --print-libdir
On 14 May 2004 08:12, George Russell wrote: I think there should be a GHC option --print-sharedir (or you could call it --print-datadir), corresponding to ghc --print-libdir. Thus on our system ghc --print-libdir prints out /home/linux-bkb/ghc/ghc-6.2.1/lib/ghc-6.2.1 and I would like ghc --print-sharedir to print out /home/linux-bkb/ghc/ghc-6.2.1/share/ghc-6.2.1 At the moment I use ghc --print-libdir | sed -e 's+/lib/\([^/]*\)$+/share/\1+g but this isn't exactly the happiest of solutions. The reason my scripts want access to the share directory is that they want access to HTML files and Haddock interfaces stored there. Remind me why you need --print-libdir again? I have a feeling that this information should be private to GHC. Oh, is it because the package specs contain the string $libdir? Anyway, to get access to the Haddock interfaces and HTML docs, we've been thinking that this information ought to be in the package specs. And we're revamping this design at the moment as part of the library infrastructure project... stay tuned (the draft design will be publish in a matter of days). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Prelude/main magicks?
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
RE: Prelude/main magicks?
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. Where is the difficulty in writing lavac as a program which: - generates .hs files from .lava - inserts appropriate import statements - invokes GHC as the back end? This seems to be a nicer (more modular?) solution than contorting GHC. And I think it would make it easier to use other Haskell compilers, should you wish too. - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude/main magicks?
Niklas Broberg [EMAIL PROTECTED] writes:
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
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.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHCi on OpenBSD
GHCi/TH works on OpenBSD/i386! Finally, after 1 year of being a really annoying bug, I finally worked out why the dlopen library wasn't behaving itself, and why you needed to set the heap above 512M to stop getting SIGSEGV'd. paprika$ ghc/compiler/stage2/ghc-inplace --interactive ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude print System.Info.arch print System.Info.os i386 openbsd Prelude Leaving GHCi. Yay. -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
