May 2004 - Glasgow-haskell-users

GHCi on OpenBSD
by dons＠cse.unsw.edu.au 14 May '04

14 May '04

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

1 0

RE: Prelude/main magicks?
by Niklas Broberg 14 May '04

14 May '04

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/

2 1

RE: Prelude/main magicks?
by Bayley, Alistair 14 May '04

14 May '04

> 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. *****************************************************************

1 0

RE: Friends for --print-libdir
by Simon Marlow 14 May '04

14 May '04

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

1 0

Friends for --print-libdir
by George Russell 14 May '04

14 May '04

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.

1 0

checking for a working System.Console.Readline
by Bernard James POPE 13 May '04

13 May '04

Hi all, In buddha I've started using System.Console.Readline for the command line (which btw is very nice, thanks to those who made the binding). Buddha uses autconf to configure itself. I want to check whether the host supports System.Console.Readline. One option is to ask ghc-package to list the available packages and see if readline appears. Another option is to try to compile a simple Haskell program that imports the library, and test if it succeeds or fails. The first option looks simpler, but I have run across machines where ghc _thinks_ it has readline support, but in fact it is broken. In other words the package readline is mentioned in the package configuration, but it is broken (normally because libreadline isn't where ghc thinks it ought to be). Are there other (better) ways to test for this? Cheers, Bernie.

2 1

RE: checking for a working System.Console.Readline
by Simon Peyton-Jones 13 May '04

13 May '04

| One option is to ask ghc-package to list the available packages and | see if readline appears. We're hatching a plan, as part of the library infrastructure project, to do just that. Stay tuned. We should emit a draft spec for comment in a couple of weeks. Simon

2 1

RE: Two problems with heap profiling
by Simon Marlow 10 May '04

10 May '04

On 10 May 2004 11:14, Simon Marlow wrote: > On 09 May 2004 16:07, Stefan Reich wrote: > >> Yes, same thing here on RedHat 9... apparently a problem specific to >> the Windows port. > > Sigbjorn has found the problem - parts of the 6.2 RTS didn't get > rebuilt when the buid was updated to 6.2.1. You can fix the bug by > replacing the profiling RTS with this one: > > http://haskell.org/ghc/dist/6.2.1/libHSrts_p_win32.zip I should mention in case this wasn't clear: this only affect the Windows version of GHC 6.2.1, installed via the MSI installer. Cheers, Simon

1 0

RE: Two problems with heap profiling
by Simon Marlow 10 May '04

10 May '04

On 09 May 2004 16:07, Stefan Reich wrote: > Yes, same thing here on RedHat 9... apparently a problem specific to > the Windows port. Sigbjorn has found the problem - parts of the 6.2 RTS didn't get rebuilt when the buid was updated to 6.2.1. You can fix the bug by replacing the profiling RTS with this one: http://haskell.org/ghc/dist/6.2.1/libHSrts_p_win32.zip Cheers, Simon

1 0

RE: Haddock can't parse data declaration involving operator
by Simon Marlow 10 May '04

10 May '04

On 09 May 2004 15:07, Stefan Reich wrote: > I hope this is the right place to ask about Haddock problems? > > I'm using Haddock 0.6 (RedHat RPM module) under RedHat 9. When I > invoke haddock on this file (Op.hs): > > module Op where > > infixl 4 := > data a := b = a := b > > I get the error "Op.hs:Illegal data/newtype declaration". > > Is this a known problem? > > Asking more broadly - maybe there is another tool that does what I > need: I just want an overview of all my modules including their > exported identifiers and all type signatures (including inferred > signatures). This is a GHC extension that Haddock doesn't support (unfortunately). I'll add it to the ToDo list... Cheers, Simon

1 0