GHC 6.2.2 on Linux with glibc2.2
I've put a compiled version of ghc6.2.2 for Linux machines still using glibc2.2 on http://www.informatik.uni-bremen.de/~ger/ghc In fact it should work on glibc2.3 as well, thanks to a minor hack from Christian Maeder. Documentation is not complete, but does at least include HTML. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Compiling faster
I am responsible for a large project containing 577 Haskell library modules, with almost 120 KLOC. These modules are divided into packages. They can be compiled either (1) the old way, using ghc -M to generate dependency files, and then using make to call GHC once for each file. (2) the new way, compiling each package in one GHC invocation using --make. There is a big difference in speed between the two. The new way takes 4 minutes 16 seconds; the old way 6 minutes 55 seconds, both measured in wallclock time. (This is, admittedly, with -Onot.) My guess is that a lot of this is due to initialisation, particularly the need to read and parse lots of .hi files. This takes a lot of time, even though in fact all the .hi files during this test were on local disks. I think therefore the section Sooner: producing a program more quickly http://www.haskell.org/ghc/docs/latest/html/users_guide/sooner-faster-quicker.html#SOONER should recommend using --make to compile lots of files at a time. And by the way, that might not be a bad idea for GHC itself ... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Marshalling Haskell String - UTF-8
I have implemented code to do this which I think is better than John Meacham's, because it (a) handles all UTF8 sequences (up to 6 bytes); (b) checks for errors as UTF8 decoders are supposed to do; (c) lets you determine if there is an error without having to seq the entire list. Here is a link: http://www.haskell.org//pipermail/glasgow-haskell-users/2004-April/006564.html ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Volker Stolz wrote (snipped): The functions are C89, so they should be present *somewhere* in libc anywhere. Yes, you're right. Normally isspace and friends are used as macros, but ANSI C requires them to be also available as functions so they must be exported that way. Therefore if you don't import ctype.h, what happens is that (isspace) is implicitly assumed to be a function of type Int - Int, which (in this case) happens to work. The reason for the incompatibility is (see comments in ctype.h) something to do with locales now being thread specific. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Christian Maeder wrote: What is ctype.h good for? A good question. Its only use seems to be in ghc/rts/RtsFlags.c where it is used for functions like isdigit and isspace for decoding the RTS flags. Maybe it should be retired altogether. I'm rather puzzled how this works if ctype.h isn't there at all, as it seems to. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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: Windows ghc6.04
Sigbjorn Finne wrote: Not sure what 2) refers to, but 1) and 3) is already in 6.2.x; no need to use the heavier-weight -threaded stuff to enable it. What I mean is a Windows version of Simon M's: http://www.haskell.org//pipermail/libraries/attachments/20040317/609414e2/Process-0001.obj or alternatively http://tinyurl.com/2yx2g I'm glad that (1) (world not stopping on IO) and (3) (networking) are already present in 6.2.x though, since it increases the chance of a uniform interface to processes working on Windows. Is there any chance of this in 6.4? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Windows ghc6.04
Is there any chance that GHC 6.04, or any GHC version in the next few months, will support the following on Windows: 1) use of native threads so that the world won't be stopped every time you wait for a character; 2) the new system-independent runProcess interface; 3) Network.Socket. (Maybe it does already?) I have a feeling the answer will be Yes, if you implement it, but sadly my time is limited ... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
UTF-8 encode/decode
I have implemented UTF8-encode/decode. Unlike the code someone has already
posted it handles all UTF8 sequences, including those longer than 3 bytes.
It also catches all illegal UTF8 sequences (such as characters encoded
with a longer sequence than necessary). Here is the code.
-- cut here ---
{- This module contains functions for converting to and from the UTF8
representations for Strings.
-}
module UTF8(
toUTF8,
-- :: String - String
-- Converts a String (whose characters must all have codes 2^31) into
-- its UTF8 representation.
fromUTF8WE,
-- :: Monad m = String - m String
-- Converts a UTF8 representation of a String back into the String,
-- catching all possible format errors.
--
-- Example: With the Haskell module Control.Monad.Error, you can
-- instance this as
-- (fromUTF8WE :: String - Either String String)
-- to get a conversion function which either succeeds (Right) or
-- returns an error message (Left).
) where
import Char
import List
import Data.Bits
import Computation
-- --
-- Encoding
-- --
-- | Converts a String into its UTF8 representation.
toUTF8 :: String - String
toUTF8 [] = []
toUTF8 (x:xs) =
let
xs1 = toUTF8 xs
ox = ord x
mkUTF8 :: Int - String - Int - Int - String
mkUTF8 x0 xs0 xmask0 xmax0 =
let
xbot = 0x80 .|. (x0 .. 0x3f)
x1 = x0 `shiftR` 6
xs1 = chr xbot : xs0
in
if x1 xmax0
then
chr (xmask0 .|. x1) : xs1
else
let
xmask1 = xmask0 .|. xmax0
xmax1 = xmax0 `shiftR` 1
in
mkUTF8 x1 xs1 xmask1 xmax1
in
if ox = 0x7f
then
x : xs1
else
if ox `shiftR` 31 /= 0
then
error (Huge character with code ++ show ox ++
detected in string being converted to UTF8.)
else
mkUTF8 ox xs1 0xc0 0x20
-- | Converts a UTF8 representation of a String back into the String,
-- catching all possible format errors.
--
-- Example: With the Haskell module Control.Monad.Error, you can
-- instance this as
-- (fromUTF8WE :: String - Either String String)
-- to get a conversion function which either succeeds (Right) or
-- returns an error message (Left).
fromUTF8WE :: Monad m = String - m String
fromUTF8WE [] = return []
fromUTF8WE (x0 : xs0) =
let
ox = ord x0
in
case topZero8 ox of
7 -
do
xs1 - fromUTF8WE xs0
return (x0 : xs1)
6 -
fail UTF8 escape sequence starts 10xx
0 -
fail UTF8 escape sequence starts 1110
-1 -
fail UTF8 escape sequence starts
n -
let
r = 6 - n -- number of 6-bit pieces
xtop = ox .. ones n
minx =
bit (
if r == 1
then
7
else
5*r + 1
)
mkx [] _ _ =
fail UTF8 string ends in middle of escape sequence
mkx (ch : xs1) x0 count0 =
do
let
och = ord ch
if och .. 0x80 /= 0x80
then
fail (UTF8 escape sequence contains continuing
++ character not of form 10xx)
else
return ()
let
xbot = och .. 0x3f
x1 = (x0 `shiftL` 6) .|. xbot
count1 = count0 - 1
if count1 == 0
then
return (x1,xs1)
else
mkx xs1 x1 count1
in
do
(x,xs1) - mkx xs0 xtop r
if x minx
then
fail (UTF8 escape sequence contains character not
++ optimally encoded)
else
do
xs2 - fromUTF8WE xs1
return (chr x : xs2)
-- --
-- Binary utilities
-- --
-- | return the number of the top bit which is zero, or -1 if they
-- are all zero, for a number between 0 and 255.
topZero8 :: Int - Int
Re: UTF-8 encode/decode
David Brown wrote (snipped): What license is your code covered under? As it stands now, it is an informative example, but cannot be used by anybody. As author, I am quite happy for it to be used and modified by other people for non-commercial purposes. As far as I know my employers wouldn't any problem with that either. If it is important to your lawyers that you have a definite licence, say so, and I'll see if I can do something. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO
Sven Panne wrote:
Huh? I'm not sure what you mean exactly, but with the help of unsafePerformIO
and a pragma for clever compilers you can simulate something like a global
variable in Haskell. Here an excerpt from the GLUT menu handling module:
{-# NOINLINE theMenuTable #-}
theMenuTable :: IORef MenuTable
theMenuTable = unsafePerformIO (newIORef emptyMenuTable)
...
Definitely not something to be proud of, but quite handy from time to time. :-)
Alternatives are passing the IORef to every function which needs it (but this
would clutter up the GLUT API in the above case) or using the FFI for holding
global data on the C side. GHC uses a similar hack internally, too, BTW.
This is not just handy from time to time, but very frequently. I've
just discovered it occurs about 100 times in 100K LOC that I am
responsible for, so often that I have stopped feeling guilty about it.
I don't really know what else I could do. One solution would be to use
implicit parameters to pass a global state variable around, but this would
require me to change the type of huge numbers of functions, since implicit
parameters are still explicit in types.
I don't remember having any actual bugs caused by unsafePerformIO. Well,
only one, before I knew about putting NOINLINE in.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc6.2 on Solaris
I have produced, with Simon M's help, an unofficial binary release of ghc 6.2 on Solaris. This may be downloaded from http://www.informatik.uni-bremen.de/~ger/ghc/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fail: unknown exception
Simon Marlow wrote: This has to be one of the most irritating ways a program can fall over. Can't the Haskell RTS try just a /little/ harder to help the poor programmer? For example by saying what sort of exception it is, and (if it's a dynamic exception) what type it has? An unknown exception is a dynamic exception. GHC just uses the ordinary instance of Show on Exception to print out the value of an exception, and it so happens that all it prints out for a dynamic exception is unknown exception. Arguably the show instance should print out the type too. It could; I just looked into it and unfortunately there's an annoying module loop in the libraries which means doing this would entail some restructuring. Why can't GHCi just print out the type itself? Because it has to be done in the context of the interpreted program, which means GHCi would have to compile a little snippet of code to show the exception. Annoying, but doable. Alternative suggestion: could the RTS provide a global variable containing a value of type Maybe (Exception - Maybe String)? If set, this would be called whenever the RTS attempted to display an uncaught exception, and the String returned if any displayed. I know this is really an awful hack but (a) it's what I want; (b) you didn't expect exceptions to be nice did you?; (c) wouldn't it avoid the above restructuring and GHCi hackery? We could argue the details of the value. For example storing a list of functions with tags [(String,Exception - Maybe String)] to be tried in order would allow the user to selectively delete particular descriptive functions. This hardly seems necessary, but in any case it might be better to restrict the visible user interface to addGlobalExceptionDescriber :: (Exception - Maybe String) - IO () to allow for future developments ... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fail: unknown exception
This has to be one of the most irritating ways a program can fall over. Can't the Haskell RTS try just a /little/ harder to help the poor programmer? For example by saying what sort of exception it is, and (if it's a dynamic exception) what type it has? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
forkProcess type changed?
For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the parent or child process? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making GHCi object files on MacOS
[EMAIL PROTECTED] wrote (snipped): I don't have such duplicate definitions in my files ... producing a package with ghc-pkg -a works OK for me with Wolfgang Thaller's GHC 6.0.1 build. Is that how you're doing it, or are you trying to produce the GHCi object file manually? I was producing it by invoking ld directly, since I wrote the Makefile before the --auto-ghci-lib was introduced. However now I use --auto-ghci-lib and it seems to work, thanks. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Making GHCi object files on MacOS
Section 4.10.3 of the GHC manual tells me to use ld -r --whole-archive to convert a .a file into a .o file suitable for GHCi. However these options only work for GNU ld, which doesn't seem to be available on MacOS (uname -srv gives me Darwin 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC). Specifically, I tried compiling the GNU binutils but got a message from its ./configure telling me that this wouldn't work for the ld directory. I presume there must be some way of producing GHCi object files on MacOS, but how is it done? Thanks ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Template Haskell and the command line
Template Haskell is frightfully good and we want to get rid of cpp and use it instead, but there's one tiny problem, namely that for cpp it is possible to define variables on the command line (-DSIMON=MARLOW and so on) while with Template Haskell it doesn't seem to be. Could there be some kind of dictionary, like the cpp environment variables, which the Template Haskell code has access to? One obvious way would be to accept the -D/-U arguments, and provide Haskell functions which look at them. Of course one /could/ presumably use System.getArgs and analyse the arguments to ghc oneself, but that would mean making guesses about the current GHC syntax. In the meantime we shall still replace cpp with Template Haskell, but find another way. Thanks for Template Haskell! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Pestilential behaviour of gcc3.3 on Macs
Yes I know this is really Apple's fault, but according to http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/GCC3.html The GCC 3.3 preprocessor inserts a new pragma, #pragma GCC set_debug_pwd, as part of the new Distributed Builds feature. (See below.) This may surprise tools and scripts that depended on the exact form of preprocessed output from GCC. These scripts should be rewritten to ignore unrecognized pragmas. Would it be possible for GHC to ignore this line? Otherwise ghc -cpp is going to fall over with gcc3.3 on Macs. Of course in the ideal world I know we should be using Template Haskell. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HTk + ghc6.01
Binaries for HTk (a Haskell graphics package that uses HTk) for ghc6.01 on Linux, Solaris, Windows and FreeBSD are now available from the HTk page: http://www.informatik.uni-bremen.de/htk/ Many thanks to Guy Coleman for the FreeBSD package. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hash functions
Many thanks for Data.HashTable, which I am about to use. Unfortunately I seem to need an unseemly hack because the key I want, namely ThreadId's, don't have a hash function defined, and defining one requires me to muck around with GHC internal functions. Could some more hash functions be provided? The logical method would be to have class HashKey key where hash :: key - Int32 and define it for as many types as possible. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HTk for ghc5.04.3
I have created binary bundles for HTk, our Haskell interface to Tcl/Tk, for ghc5.04.3 on Linux/x86 and Windows, and put them on the download page: http://www.informatik.uni-bremen.de/htk/download/INSTALL.BINARY.html I will add FreeBSD and Solaris bundles when I can get hold of ghc5.04.3 on those platforms. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FreeBSD + FIFO pipes
Yes I know it's a FAQ, but despite the information in the GHC FAQ I can't get my program to work. I'm trying to get HTk to work on FreeBSD (actually FreeBSD running inside a VMware virtual machine, but I don't think that should make any difference). How HTk works is it creates a couple of pipes (readIn,writeIn) - Posix.createPipe (readOut,writeOut) - Posix.createPipe It then forks off a process which first dup2's readIn onto its stdin and writeOut onto its stdout, and then runs the Tcl/Tk shell wish (which does graphics). The idea is that sending commands along writeIn will cause them to be executed by wish, and wish's output can be read from readOut. We do the reading/writing of readOut/writeIn using the Posix fdRead/fdWrite primitives. In addition, before every call to fdRead we do a Posix.threadWaitRead on it, to make sure there is actually input there. All this works fine on Linux and Solaris by the way. (On Windows we use a completely different mechanism.) The problem I am getting with FreeBSD is that fdRead sometimes reports EOF, even though threadWaitRead has just reported the presence of data. (And no, I don't think we have a race condition here, the relevant bit of code is in an exclusive lock.) If I tell it to ignore the EOF and try to read again and again it just throws it into an endless loop, seemingly. The GHC FAQ says: A workaround for all systems is to open the FIFO for writing yourself, before (or at the same time as) opening it for reading. What does it mean open the FIFO for writing yourself? I've tried putting in the following lines immediately after creating the pipes byteCountOut - fdWrite writeOut # (strIn,byteCountIn) - fdRead readOut 1 case (byteCountOut,byteCountIn,strIn) of (1,1,#) - done x - error (ChildProcess.999 error++show x) byteCountOut - fdWrite writeIn # (strIn,byteCountIn) - fdRead readIn 1 case (byteCountOut,byteCountIn,strIn) of (1,1,#) - done x - error (ChildProcess.9998 error++show x) which just write a single character down each pipe; unfortunately this doesn't seem to help. Any other suggestions? By the way this is all GHC5.04.1, which seems to be the last FreeBSD version available, at least with pkg_add. Thanks. George Russell ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD + FIFO pipes
Volker Stolz wrote: In local.glasgow-haskell-users, you wrote: I'm trying to get HTk to work on FreeBSD (actually FreeBSD running inside a VMware virtual machine, but I don't think that should make any difference). How HTk works is it creates a couple of pipes (readIn,writeIn) - Posix.createPipe (readOut,writeOut) - Posix.createPipe The problem I am getting with FreeBSD is that fdRead sometimes reports EOF, even though threadWaitRead has just reported the presence of data. (And no, I don't think we have a race condition here, the relevant bit of code is in an exclusive lock.) If I tell it to ignore the EOF and try to read again and again it just throws it into an endless loop, seemingly. Can you cut this down to a simple program, maybe executing /bin/echo instead of 'wish'? Notice that the FAQ doesn't apply here as the FAQ talks about FIFO createt by mkfifo (which exist in the file system), while you talk about pipes. I'll try to think of something, but I'd be glad if you already had a usable program to reproduce this error. I think this one is going to remain unsolved. I have fixed the problem, by reimplementing the relevant code in a different way (actually resurrecting an old implementation, with a vital fix) and now it works. However the cause of the problem I reported is a mystery to me, and producing a simple test case does not look very easy. Thanks for your help, George ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Alex wrote
[snip]
Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some
horrible problems with inconistent treatment of filenames, especially
when using (gnu, cygwin) make. In a nutshell, make seems to be passing
paths such as /usr/local/hmake (etc) to ghc, which is, as I understand
it, interpretting these in a manner consistent with windows, but not with
cygwin. (i.e., it'd expect the above to be something like:
/cygwin/usr/local/hmake, where the root of the cygwin installation is in
c:\cygwin. Experimenting with similar arguments to ghc by hand seems to
confirm this.
[snip]
The UniForM/HTk distribution includes the attached very simple Haskell98 program,
which is compiled and run during the ./configure stage. This program transforms
stdin to stdout, globally replacing the string #PWD with whatever GHC thinks the
current directory is called. This program is used in various ways; in particular
./configure uses it to set a variable GHCTOP corresponding to GHC's name for the
top of the source distribution, which is then what gets passed to GHC. The program
is also used for various unholy tricks involving package config files, which also
of course need the Windows name.
Fortunately GHC doesn't mind if some slashes are the wrong way; thus if GHCTOP is
C:\foo\bar\uni, then I can refer to C:\foo\bar\uni\baz as $GHCTOP/baz, as
it would be on Unix.
{- This program converts stdin to stdout. It replaces all occurrences of
the string #PWD in stdin with the current directory in which it is
executed, C escaped. The string #pwd is similarly replaced, except that
it is not escaped. Everything else is left unchanged.
If an argument is supplied, this is used instead of the current
directory.
The program occupies an unusual place in the UniForM sources; it is not
part of the main sources, but is only used during building (see suffix.mk)
and is compiled during configuration. Since it only uses completely
standard Haskell 98, this ought to be pretty easy.
We do things this way rather than with some sort of script so that this
will work even in the extremely hostile environment of Windows (with no
cygwin). Also, using GHC's getCurrentDirectory means we get at what
GHC thinks the current directory is (IE the Windows file name) rather than
what it is in cygwin's Unix world.
-}
module Main (main) where
import Directory
import System
main :: IO ()
main =
do
input - getContents
args - getArgs
toInsert - case args of
[arg] - return arg
[] - getCurrentDirectory
let
escapeString s =
let
withQuotes @ ('\':rest) = show s
in
take (length rest - 1) rest
quoted = escapeString toInsert
transform [] = []
transform ('#':'P':'W':'D':rest) = quoted ++ transform rest
transform ('#':'p':'w':'d':rest) = toInsert ++ transform rest
transform (c:rest) = c:transform rest
putStr . transform $ input
HTk for ghc-5.04.2
I've compiled HTk for ghc-5.04.2 on Solaris, Linux and Windows, and put binary bundles at http://www.informatik.uni-bremen.de/htk/ So you can write portable graphical user interfaces using the latest release of your favorite Haskell compiler. Sorry it's a bit late; it's not that it's difficult, it's just that I am a shortage of manpower. I hope I produce binaries for ghc-5.04.3 a bit faster. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Avoiding No explicit method ... warnings
This isn't a bug, just a suggestion. It's not even a very important
suggestion, but one that might be worth implementing if it's easy and you can
find the the time. Or perhaps I am just doing things the wrong way?
The point is that I sometimes have something like the following situation
class ComplicatedClass x where
simpleTitleFn :: x - String
muchMoreComplicatedTitleFn :: extra arguments - x - IO (WithError (Source blah
blah blah String)
muchMoreComplicatedTitleFn _ x = [ ... some expression involving simpleTitleFn ...]
The idea is that only muchMoreComplicatedTitleFn must always work; however instances
may
choose to implement it directly, or implement the much simpler function simpleTitleFn
(if that does all they want).
At the moment the situation is that someone who defines just
muchMoreComplicatedTitleFn
will get an unnecessary warning message from the compiler about No explicit method or
default method for simpleTitleFn. I suggest instead introducing a new class of
optional method (for example, via a pragma {-# OPTIONAL_METHOD simpleTitleFn #-}) which
compiles exactly as normal except that (1) no warning is given for instances which
don't
define it; (2) a warning is given whenever anyone outside the class declaration *uses*
simpleTitleFn.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Avoiding No explicit method ... warnings
Simon Peyton-Jones wrote: [snip] One other idea though. Suppose you say class ComplicatedClass x where _simpleTitleFn :: x - String muchMoreComplicatedTitleFn :: extra arguments - x - IO ... In general GHC doesn't report warning unused for variables whose name begin with an underscore. In the case of class methods, I don't think it suppresses the warning, but that would be an easy change to make. Indeed, it would arguably be more consistent to do so anyway #-}) which compiles exactly as normal except that (1) no warning is given for instances which don't define it; (2) a warning is given whenever anyone outside the class declaration *uses* simpleTitleFn. The _ idea would achieve (1). You could get (2) by not exporting the _ method from the module defining ComplicatedClasss. How would that be? [snip] Yes, this looks just as good as my original idea, if not better. Especially as it would be an easy change to make. In fact there are some cases where I might want to use simpleTitleFn on a Trust me, it's defined for this type basis, but that could be achieved by exporting an equivalent, but deprecated, function. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Suggested improvements to .hi-boot files
I am using .hi-boot files quite a lot at the moment. I'm very grateful for the recent
change to a more Haskelly syntax, but I have a couple of suggestions for the GHC team
to implement in their no doubt ample free time. 8-)
(1) Importing a module {-# SOURCE #-} into itself currently produces a warning, but no
other action
so far as I can see. I suggest instead that this provoke a check that the .hi-boot
module accurately
reflects reality. (Otherwise there is no way of checking is there?) Or perhaps you
could add a
pragma {-# RECURSIVE #-} at the top of the module that indicates the presence of a
.hi-boot file which
should be checked.
(2) Instance declarations (with empty bodies) should be permitted.
(3) There should be an option to pass .hi-boot files through cpp. This would not be
particularly useful
to me, as I have already implemented a pre-compilation phase which does just that, but
it might
be useful for others.
(4) The manual should recommend using say the GHCi :info command to find out that,
say, IO must be called GHC.IOBase.IO. (If I'd known this it'd have saved me having
to trawl through the GHC sources.) Obviously one would ideally be able to type IO
rather
than GHC.IOBase.IO, but my guess would be that this would be (a) harder to implement
than
the other suggestions, (b) less useful.
Happy New Year by the way. If any Simon is still reading, about long have we got
before the
current old library hierarchy is done away with in an official release? Sometime
before then
I will need to carry out a massive global-exchange.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow-haskell-users digest, Vol 1 #672 - 1 msg
[EMAIL PROTECTED] wrote: [snip] I've been experimenting with making an asynchronous IO library. At the moment it uses Haskell threads but the idea is that it could be transparently extended to use system AIO. I think what you are really asking for is asynchronous events, a la Reppy. I don't like to blow my own trumpet (well, I do actually), but I've already implemented these in Haskell, see the paper in ICFP 2001. Of course John Reppy got there first with PML/CML. http://charlesstreet22.force9.co.uk/~duncan/projects/aio/AIO.hs My question is if there is an effecient way to block / wait on multiple MVars. takeMVar readMVar can wait on one MVar. The puspose is to be able get the reults of a list of AIO operations, in the order in which they complete. Not at the moment. Also I'm not sure such a thing could usefully be added without more or less adding events anyway. It's not enough to have takeOneMVar :: [MVar a] - IO a which looks for the next a, because pretty soon someone is going to want you to implement data MVarActionPair a = forall b . MVarActionPair (MVar b) (b - IO a) takeOneMVar' :: [MVarActionPair a] This I suppose could be done without too much trouble, but then you run into problems because the supplier of events has no way of knowing if these events are actually being picked up or not, something that can be very important. To solve this problem in general you need Reppy-style higher-order events. So you might as well have implemented those from the beginning anyway. Also I am very much opposed to loading extra burdens onto the implementors of MVar's unless we can be reasonably sure that MVars won't get slower as a result. MVars are an excellent low-level abstraction; it's better to build more complicated things on top of MVars as required. Good luck, George Russell ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
DeepSeq
Would it be possible to bring the DeepSeq library into the libraries distributed with GHC? (I think Dean Herington is responsible for it.) Of course it's easy enough to drop it into one's own program (I am just about to do this) but (1) It is fairly common to want to force deeper evaluation. (2) DeepSeq is simple enough to be dropped in the GHC distribution, without it causing much trouble or making it much bigger. (3) At the same time, it is not so simple that it can be reimplemented in a couple of lines. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: package name mismatch
Simon Marlow wrote: [snip] Can't you just fix your build so that the situation doesn't occur? [snip] Grumble. Yes, I suppose so. I hate being an implementor instead of a bug-reporter. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: package name mismatch
Simon Marlow quoted Max Kirillov [snip] Building htk, I've got an error: =20 TestGetPut.hs:6: Module `GetPut' is located in package `Main' but its interface file claims it is part of package `uni-events-test' =20 It happened (as far as I got) when ghc saw in current path the *.hi file built for installation. There are some ways to work around it, but, there was a lot of such places, so can I just skip the 'package name' check and go as it is? This was converted to a warning in, I think, ghc 5.02.3. Please upgrade, preferably to 5.04. [snip] It must have been only a warning in 5.02.3, or I could never have compiled it there. (Before 5.02.3 we didn't use the package system like this at all.) Actually I would like this message to go away altogether in this case, if possible. The actual situation is that GetPut.hs is in fact part of the package uni-events-test, and the compiler is told to load uni-events-test on the command line. However GetPut.hs is *also* in the current directory during this compilation, so GHC loads it from there instead. I'm not sure what logic would be best here, but my suggestion would be that where a .hi file is found in an import declaration and has an unexpected package name, GHC keeps on searching. If it finds a .hi file with a matching package name, it accepts it, otherwise accept the .hi file with the wrong package name and issue a warning. If that's too complicated, just ignore .hi files with the wrong package name. But then people might complain . . . [ - for Max's eyes only - As a matter of fact, this file is not needed for uni-htk anyway (it's just part of a test case) so Max could just work around it. If you just do gmake package rather than gmake or gmake all I don't think it will occur, though that will also mean the test programs don't get made. If you want the HTk examples go into htk/examples and do gmake main and/or gmake test there. - ] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc5.03 .hi and .hi-boot files don't you just love those incompatible changes?
Ah, I've figured it out. The new .hi-boot file format is actually Haskell!! Well almost. You have to fully qualify type names (you can't use Int, you must use GHC.Base.Int) and the input isn't run through -cpp. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-pkg (5.03.20020204) problems
Can you stop ghc-pkg complaining when it can't find the library for a package, and insert the package into its configuration file? Some of my scripts rely on being able to build the package.conf file ahead of time. What with this, and because ghc-pkg doesn't seem able to cope with private config files (see previous report) ghc-pkg in 5.03 is causing me lots of problems. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc5.03 .hi and .hi-boot files don't you just love those incompatible changes?
Formerly .hi and .hi-boot files had the same format; however ghc5.03 has a binary format for .hi files and a textual one for .hi-boot files. This is a nuisance for me, because I have an ingenious scheme by which .hi-boot files are themselves from Haskell files by ghc, which thinks it is generating .hi files. Since I don't particularly want to go from writing to Haskell to writing interface files, I would like to keep the old scheme, but then I need a way of getting GHC to generate .hi-boot files from .hs files. One might think the options -ddump-hi or --show-iface would do the job, but they don't. --show-iface produces a file which causes Haskell later to choke with the message failed to load interface for `DisplayView': Bad interface file: DisplayView.hi-boot DisplayView.hi-boot:1: parse error on input `__interface' -ddump-hi is even worse, since it adds an extra two totally useless lines at the start (but otherwise appears to be the same as --show-iface). So is there any way of getting GHC to generate .hi-boot files? Or should I give up on using .hi-boot altogether and simply compile the Haskell direct to the .hi file? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cygwin GHC
Simon Peyton Jones wrote: I am therefore deeply reluctant to provide both GHC-for-mingw32 and GHC-for-cygwin. One build on Win32 is enough! We ended up with a mingw32 basis because it meant we could make GHC=20 completely self-contained -- no dependence on cygwin1.dll etc. This was *huge* step forward: GHC installs and runs with no problem on Windows now. I agree about it being a huge step forward. I do not think I would be in favour of undoing this and going back to having to install cygwin (in the right version) to get GHC to run. 1. GHC does not understand cygwin paths in the file names passed to it on the command line. 2. GHC on Win32 does not come with a Posix library. If we used a Cygwin basis, Posix would be easy because cygwin does all the hard work. 3. I/O on Win32 is *blocking*. A blocking input operation freezes all the other Haskell threads. I am a little but not hugely bothered by (1) and (2), as they can all be worked around in various ways. The real problem is (3), since it means that not just IO events but almost all events from the non-Haskell world cannot be waited on without bringing the Haskell world to a halt. Is it possible to do something about (3) without switching back to Cygwin? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Multiply Recursive Modules
Writing .hi-boot files is a pain, and the works (allegedly) containing a compiler which does mutually recursive modules properly seem permanently gummed up. Therefore may I suggest a new .hs-boot suffix which compiles Haskell to produce just a .hi-boot file? I already have two .hs-boot files (except I call them .boot.hs to make ghc happy) and they seem to work reasonably well. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Casting dynamic values
It would occasionally be nice to have a function cast :: (Typeable a,Typeable b) = a - Maybe b which returns Just a if a and b have the same type, and Nothing otherwise. This may seem rather a curious need, but it arises with existential types; if you have data A = forall a . (context) = A a (context including Typeable a) then this allows you to getB :: (Typeable b) = A - Maybe b getB (A a) = cast a and so extract a value from A, if you can guess its type. Clearly we can implement cast = fromDynamic . toDyn My question is: is this the most efficient way of doing it, or is there a better way? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc --make + #include directories
Simon Marlow wrote: What's wrong with just saying -Idir whenever you say -idir? This seems to work but for more complicated combinations the two options have slightly different formats. For example, if I have several directories separated by colons, and end the list with a superfluous colon (which arises naturally enough when the path is auto-computed) I get messages like: gcc: cannot specify -o with -c or -S and multiple compilations /home/ger/uni /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -c util/WBFiles.hs -iutil:cvs: -Iutil:cvs: -package concurrent -package data -package net -package posix -package text -package util -package lang -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -cpp -ddump-hi-diffs -H25M -recomp -fwarn-deprecations -Onot -DDEBUG -fvia-Cgcc: /usr/local/pub-bkb/ghc/ghc-5.02.1/lib/ghc-5.02.1/include: linker input file unused since linking not done Source file changed or recompilation check turned off INTERFACE UNCHANGED gcc: cannot specify -o with -c or -S and multiple compilations [falls over] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What isn't possible with Finite Maps, and should be.
Once again I find myself wanting something like the following function with finite maps: fmToListByRange :: Ord key = FiniteMap key elt - (key,key) - [(key,elt)] fmToListByRange map (k1,k2) is supposed to return all elements in the map with keys from k1 to k2 (inclusive). Although this isn't as common as looking up an element by a key, it nevertheless is sometimes useful, and shouldn't be too hard to implement, given that FiniteMaps are going to be implemented (given the Ord constraint) as some sort of tree-like query structure, so it's just a question of scanning down the tree splitting the interval as you go. Of course this can be generalised. A general range would have type (Maybe key,Maybe key,Bool) where Nothing instead of a key would mean starting at one of the ends, and the Bool would indicate whether you gave the elements in increasing or decreasing order of key. In any case it looks fairly simple to write. If only I were set up to be able to compile GHC I could write the necessary code myself . . . ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Existential Typing (was Multi-parameter OOP)
Leon Smith wrote: [snip] If GHC had true existential typing, as opposed to just existential datatypes, you could reasonably code what I think you want like this: class A a where basicA :: Bool nextA :: a - (EX a'. A a' = a') basicA = True nextA = id data WrappedA = forall a. A a = WrappedA a instance A WrappedA where basicA = False nextA (WrappedA a) = a data A1 = A1 instance A A1 --... similarly for B ... class AB a b where toBool :: a - b - Bool instance (A a, B b) = AB a b where toBool a b | (basicA :: a) (basicB :: b) = True | (basicA :: a) || (basicB :: b) = False | otherwise = toBool (nextA a) (nextB b) [snip] Either I've missed something, or this isn't what I wanted. The problem I have is that AB is not extensible. If you want to add a new instances A2,B2 of A,B and a new definition of toBool which just works for A2 and B2, you can't do it, without changing the definition of toBool in the above instance. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Multi-parameter OOP
Recently I've been experimenting with a sort of OOP with GHC, using existential types and (overlapping, undecidable) multi-parameter type classes, but it doesn't seem to work as you might expect because of the way GHC resolves overloaded functions at compile-time. For example, given class A a data WrappedA = forall a . A a = WrappedA a data A1 = A1 instance A A1 class B b data WrappedB = forall b . B b = WrappedB b data B1 = B1 instance B B1 class AB a b where toBool :: a - b - Bool instance (A a,B b) = AB a b where toBool _ _ = False instance AB A1 B1 where toBool _ _ = True instance AB WrappedA WrappedB where toBool (WrappedA a) (WrappedB b) = toBool a b a naive user (like me a month ago) might expect that this to work, so that toBool (WrappedA a) (WrappedB b) will return False unless a is an A1, and b a B1, in which case it returns True. In fact ghc5.02 (rightly) gives an error message with the second instance declaration: Could not unambiguously deduce (AB a b) from the context (A a, B b) The choice of (overlapping) instance declaration depends on the instantiation of `a, b' So is there any other way of doing this sort of dynamic lookup at runtime, in a reasonably neat way? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Telling ghc where to start
There are various reasons why one might have a Haskell file which doesn't have the expected Module.hs filename, in particular when putting ghc into some larger system which does its own thing with files. I may well want this as part of UniForM in the next few months. However ghc doesn't provide anyway support for this, and while you could create a symbolic link with a name ghc approves of to the real file, that seems somewhat messy. gcc has an option which allows you to specify that the input is, say, a C program (even though it's called hello.txt) but it's rather messy and might take too long to implement. I suggest instead a new option called -virtual-name or something similar, so that ghc -virtual-name Module.hs /blah/horrible932 will compile the contents of /blah/horrible932, but treat it as if it were called Module.hs. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why have file names with 3 components?
This looks like a bug, but please don't change it! If you have a file A.blah.hs containing a module A, ghc5.02 compiles it, producing A.hi and A.blah.o. I have an application for this, since I have just, for the first time, been reluctantly compelled to introduce recursive modules. Rather than writing .hi-boot files (which might have to be rewritten for ghc5.03) I have instead written .boot.hs files, which yield .hi files, which then get moved to .hi-boot. Thus a module A has two sources, the real source A.hs, but also the source for the .hi-boot file, A.boot.hs. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unterminated {-
Seems to me it would make more sense for the message
.hs:214: unterminated `{-'
message to tell me where the {- is, rather than where the EOF is.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
wait(2)
Is there a way in Glasgow Haskell to get a thread to wait on a child process in the same way as the Posix function wait(), and get the termination status of the child? If so, how? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
do's and error messages
If you have a type error message at the very start of a do statement, the result can be rather confusing, because the typechecker doesn't know that do's are almost always have type (IO (something)) and so tries to shoehorn the monad to fit the type. This has actually happened to me several times; the worst case is when the result is (for example) a list, which allows the error to propagate further. Is there some way of doing something about this? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHCi turned upside down?
GHCi allows us to mix fixed compiled and dynamic interpreted code to be run from what I presume is dynamic interpreted code - the command prompt. Would it be possible to run dynamic interpreted code from a compiled program? I'm hoping the answer is Yes, because this is what GHCi does, the only problem being to clean up the syntax and document it. I'm afraid I haven't been following the FFI debate lately but perhaps we could steal some of the FFI's syntax for declaring types of imported entities. The difference (I'm not sure if this is a difference with the latest with the latest FFI version) would be that the source file/string (and perhaps function name) need to vary dynamically, which means also that of course it needs to be done below top level, and invoke an IO action. So we might try something like runMain :: FilePath - IO () runMain sourcePath = do source - readFile sourcePath foreign import ghci source main main :: IO () main which would read the file sourcePath, interpret it as Haskell, and run the main action therein. This isn't meant to be a polished proposal, just an idea for something which might be nice to have around in the future. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why does --make only allow one module?
ghc --make would be wonderful for UniForM, which at the moment consists of a large selection of libraries, were it not for the restriction that ghc --make insists on only having one module as an argument. Er why? At this rate I shall be driven to writing an otherwise useless module which imports all the modules in each directory, since ghc --make does indeed look a lot faster than compiling each module individually. (In particular, we win big here, I think because the NFS system is very inefficient and makes reading all the .hi files very expensive.) Actually I'd like to just give ghc --make a list of ALL the source files and let it figure out the dependencies. This could also include object files (compiled from C) which were to be linked in, for example. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc5.00 binary on Sparc?
GHC 5.00 looks wonderful. Would it be possible to make a binary distribution available for Sparc? As you may remember, I've had difficulty compiling it myself for Sparc, for some reason I don't know, and even if I find a way of hacking things to compile it, I'd rather users (= students) didn't have to . . . ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fail: thread killed
Marcin 'Qrczak' Kowalczyk wrote: [snip] Since the very purpose of killThread is to kill the damn thread, I find it inconvenient to have to wrap any thread which is supposed to be killable with Exception.catch to avoid the message. Worse: it should use block and unblock, otherwise there is a small window where killing the thread will still display the message. [snip] I agree with this. I also find it mildly irritating having to catch exceptions to stop GHC informing me that it's just garbage collected a thread which is permanently deadlocked. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
runProcess/ createPipe
If Posix.runProcess really is supposed "our candidate for the high-level OS-independent primitive" (see documentation), it would help if there was a documented way of using it with pipes. The problem is that runProcess takes handles as arguments, while the obvious function, createPipe, returns two Fds. There seems to be no _documented_ way of converting an Fd to a Handle. I suggest therefore that either there be a createPipeHandle :: IO (Handle,Handle) (which would be nice, because it might avoid bothering the operating system completely, and would makes sense on non-Posix systems). Or else, the existing Posix.fdToHandle fdToHandle :: Fd - IO Handle should be documented. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Semi-applied datatypes in instance declarations
I apologise if this has been raised before, but the code I am writing now would look rather nicer if "partially applied type constructors" were permitted in instances. For example: class Event e where sync :: e a - IO a data Event extraData a = blah blah . . . instance (context on extradata) = Event extradata where blah blah . . . Any chance of this? Or are there reasons why this would be wholly ridiculous? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 4.08.2
Sven Panne wrote: [snip] The current branch-o-mania is a little confusing, but the CVS branch called "ghc-4-07-branch" (yes, "7", not "8") should contain what you are looking for. At least I think so... :-} Any bootstrapping problems? Yes, I get a segmentation fault when the compilation process first comes to use the resulting hsc executable. I have tried several times to avoid this (by changing gcc or ghc versions) but without success. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
instance Bits Int
Why isn't Int an instance of Bits? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Command Line Help
"Steinitz, Dominic J" wrote: I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly? [dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 - lHSlang -lHSdata /usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap': FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts' collect2: ld returned 1 exit status I suggest using /usr/bin/ghc -o main test.o -package data -package lang -fglasgow-exts or something similar (rather than trying to name the libraries directly). ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The Set type
A minor quibble I know, but every time I use sets I want to add/subtract single elements to/from them. There is no function provided for doing this, so instead you have to do union/delete with a singleton set constructed from the element. I appreciate the zeal of the designer of this module to construct the smallest possible interface (I wish the same person had designed the standard Prelude) but I think this zeal is overdone. You do often need to operate with single elements. After all, if you wanted real hair-shirt minimalism you should get rid of "elementOf" (replace it by \el set - isEmptySet (intersect set (singletonSet el)), but no-one would seriously suggest that - I hope. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Or-patterns
Why not steal a good idea from Standard ML/New Jersey now and again? This has "Or-patterns" which allow you to match against a disjunction of patterns, EG fun sleepIn (Date.Sat | Date.Sun) = true | sleepIn _ = false Where you have variables in the patterns, you bind only the variables which appear in all the patterns, and you unify the types accordingly. Of course you can do without this feature, but I feel it shouldn't be too hard to implement and for me at least it would be occasionally useful. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Instant readFile
The readFile :: FilePath - IO String action returns the contents of the associated file. This is almost what I want, but not quite, because readFile is lazy. Hence if the string is only partly read, the file is still open. What I want instead is a function which (a) opens the file; (b) slurps the complete contents compactly into an array; (c) closes the file; (d) makes the contents of the array available as a String. So instead I wrote the following: copyFileToString :: FilePath - IO String copyFileToString file = do (addr,len) - IOExts.slurpFile file CString.unpackCStringLenIO addr len However on further consideration this also seems to me to be unsatisfactory, because although I don't understand this issue very well, I don't think the (addr) address containing the complete file contents will ever get deallocated, because there's no way the GC can know that this particular Addr can be free'd. (Is that correct?) So please, how _should_ I write this function? For example, I could try and wrap the addr into a ForeignObj, but then how would I ensure that when the String gets gc'd, the ForeignObj does too? It all is a bit of a mystery to me how you are supposed to use Addr like things without space leaks. A little more explanation in the documentation would not perhaps be amiss . . . ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
getContents
I don't really understand getContents. (Does anyone?) I have some code here (far too large to submit). If I do (on Linux, ghc4.08.1, both with and without optimisation) -- contents - hGetContents handle seq (last contents) (hClose handle) -- the code works. However I looked at the manual and it seems that hClose should force the whole of contents to be read anyway. So I changed it to -- contents - hGetContents handle hClose handle -- and then the code doesn't work. If these are meant to be the same, then we have a GHC bug. If not, could someone explain in words of one syllable why not? PS - if you want the source code you'll have to download and compile the whole of UniForM!! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getContents
Simon Marlow wrote: [snip] "Once a semi-closed handle becomes closed, the contents of the associated stream becomes fixed, and is the list of those items which were succesfully read from that handle". [snip] Ah, now I see. I had assumed that hClose'ing a semi-closed handle would result in the entire file being read till EOF, after which the file would be closed. Thanks. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC RPMs for RedHat 7
On this subject, where am I to get the libgmp2.a required by 4.08.1 (on Linux anyway). I tried compiling the very latest version of GMP but it only produced a libgmp.a file. Is that the same? NB that RPMs aren't a lot of good to me unless they come with a hefty bribe for the hard-nosed system administrators around here. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC RPMs for RedHat 7
Keith Wansbrough wrote: On this subject, where am I to get the libgmp2.a required by 4.08.1 (on Linux anyway). I tried compiling the very latest version of GMP but it only produced a libgmp.a file. Is that the same? Same happened to me. ln -s libgmp.a libgmp2.a worked for me. I satisfied myself I was doing the right thing by noticing all the 2.x.x version numbers on the libgmp source I'd compiled. Yes, that's what I did. Probably everyone has . . . Er, isn't this the sort of thing ./configure scripts are for? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to add libgmp.a to lds search path
"Manuel M. T. Chakravarty" wrote: Is it possible that you are using a Linux box on which the gmp devel libraries are not (properly) installed? Very likely. Our local sysadmins do not appear to consider integers a sufficiently common concept in computer science to justify a MB or so installing gmp. So I (like about 7 others no doubt) compiled my own copy of gmp and copied libgmp.a to where GHC puts its libraries: [installation directory]/lib/ghc-4.08/
Re: numericEnumFromThenTo strangeness
Lennart Augustsson wrote: By definition, if you follow the standard you can't be wrong. :) But the standard can be wrong. Perhaps this is a typo in the report? I think I looked at this a while back. The standard is kaput. It gets even worse if you try to make sense of the definitions of succ and pred as applied to floating-point number. My suggestion: get rid of Enum on floating-point numbers. Maybe it'll make floating point loops a little lengthier to code, but at least it will be clear what exactly is being coded.
More PackedStrings please
It would probably speed up my code somewhat if the GHC libraries provided more support for PackedStrings. For example, some code I have reads in stuff from a Posix fd (using Posix.fdRead) and then feeds it to the GHC regular expression interface (using RegexString.matchRegex). It is frustrating that although I am getting no benefit from all the boxing and thunks contained in the String type, I am still having to use it to get from fdRead to matchRegex. Therefore my suggestion is that such functions come in two flavours; one primitive version which uses PackedStrings, and one higher-level one which uses Strings. (The transformation from one to the other is hopefully trivial . . .) Of course I could just use the new foreign interface to call the relevant functions, but that's still comparatively yucky even with all the new improvements.
Re: Unicode
Marcin 'Qrczak' Kowalczyk wrote: As for the language standard: I hope that Char will be allowed or required to have =30 bits instead of current 16; but never more than Int, to be able to use ord and chr safely. Er does it have to? The Java Virtual Machine implements Unicode with 16 bits. (OK, so I suppose that means it can't cope with Korean or Chinese.) So requiring Char to be =30 bits would stop anyone implementing a conformant Haskell on the JVM. (I feel strongly about this having been involved with MLj, which compiles ML to JVM; Standard ML requires 8-bit chars, a requirement we decided to ignore.)
net library port numbers
Socket.accept function returns a PortNumber as its third argument. (This is not what the interface comment says, but the comment is wrong.) However I can't find any way of extracting the contents of the PortNumber to an integer.
Re: What's in an interface? Unnecessary recompilation again
Simon Peyton-Jones wrote: Fair enough. But would you like to suggest an algorithm GHC could use to decide what to put in the .hi file? Well that's a big question. As I understand it, the errant value, lvl20, is a string representing an error message (which I suppose is to be thrown in the event of a matching failure). Since it should only be used on error, surely there is no speed benefit to inlining it, and probably there is a space penalty (since you store the string multiple times). In this case there is a very real disadvantage, since inlining forces everything that imports that module to recompile. So my suggestion would be that values required only for errors should never be inlined or put in a .hi file.
Re: putMVar on full MVar
Simon Marlow wrote: Let me see if I've got the semantics right: takeMVarMulti makes a non-deterministic choice between the full MVars to return the value, and if there are no full MVars it waits for the first one to become full? Yes that's precisely right. putMVarMulti is the converse. (So it only writes to one location, which will confuse some people.) Defining this in Haskell is pretty hard. I managed to do it for two MVars (code at the end of this message). There might be an easier way to do it using special code in the scheduler, but I need to think about that some more. It's _because_ defining it in Haskell is pretty hard that I was thinking maybe it should be added to the concurrency primitives. Unless I'm missing something, with the current concurrency primitives you cannot make a non-deterministic choice between N MVars with less than N threads, unless you do it by polling at intervals Actually even takeMVarMulti and putMVarMulti could be generalised. A more general non-deterministic MVar operation function might be multi :: [Multi a] - IO a data Multi a = forall b . PutMVar (MVar b) b IO a forall b . TakeMVar (MVar b) (b - IO a) This would wait for the first doable PutMVar or TakeMVar and then execute the corresponding continuation.
Re: putMVar on full MVar
Claus Reinke wrote: Right. I am relieved to read that your application source is not full of calls to putMVar, but rather uses safe abstractions built on top of MVars (it might be interesting to isolate them out of your current application and migrate them to a CH library?). Not a bad idea. Public implementations of channels are already available (I believe there is already code provided with GHC.) I think Einar Karlsen's composable events are an even neater idea and I should like to publicise and extend them some more later on, maybe by writing a paper about them. I don't understand the "tryButDoNotSuspend" operation. What does it mean, "would lead to an immediate suspension of the current thread"? It would incidentally be fairly trivial to implement tryForAWhileButDoNotBlockForever using Einar Karlsen's events. (Except of course that delays are always going to be approximate; GHC might not be able to run the thread bang on time because it could be in the middle of some C function.) I think the rest of Claus's discussion is a very good illustration of what I said before that you can think of other primitives that could arguably be provided for MVars and perhaps we should think the whole issue through carefully. Another thing which MVars can't do very well at the moment is multiple access. Perhaps there should be a function takeMVarList :: [MVar a] - IO a which waits for the first MVar to come along. (Again, you could easily implement such a thing using MVars defined in terms of Einar's events.) Well I have no quarrel with orthogonal extensions to MVars PROVIDED THAT THEY DO NOT GET SLOWER. So what do the wizards of GHC say can be done for free?
Re: tryTakeMVar :: MVar a - IO (Maybe a)
Simon Marlow wrote: The only way I can see to do this is to add a lock field to the MVar. And since this lock would look very much like another MVar, you may as well just use another MVar to lock it (after all, that adds exactly zero extra complication to the system :-). Absolutely. There's still some discussion to be had on what putMVar should do when presented with a full MVar. The options are The logical dual to tryTakeMVar would be tryPutMVar :: MVar a - a - IO Bool Or even tryPutMVar :: MVar a - IO a - IO (Maybe a) (the latter only if you can keep the MVar empty while you run the action.) I have absolutely no need for either of these functions, but would either of them be implementable without extra expense?
Re: tryTakeMVar :: MVar a - IO (Maybe a)
Would it be possible to implement an operation to lock an MVar without any extra expense? So that the thread owning the MVar can do things to it, but no other thread can. If it is possible, I suggest that it be added and it would solve Marcin's problem (isEmptyMVar would then suffice).
Re: Provenances of imported identifiers
Simon Peyton-Jones wrote: Try it now with -fddump-minimal-imports I don't promise it'll work, but it does in simple cases. It produces a file M.imports Brilliant, thanks. I'll try it out (indeed probably use it) when I next manage to compile GHC from CVS.
Re: improving error messages
(Sent to glasgow-haskell-users rather than haskell, as it is GHC-specific.) If we were writing a C library rather than a Haskell library, we could make "head" a macro which included an appropriate message referring to __FILE__ and __LINE__. The equivalent in Glasgow Haskell would be to make head inline, and include a primHaskellFile (and if possible, though I doubt it, primHaskellLine) which got replaced at a late stage by the actual name of the current module. This would be useful for locating other error messages as well. For example I have a debug action which (if debugging is turned on) prints out messages to a file; if we had a primHaskellFile I could make this debug message automatically refer to the calling module, which would be nice.
Re: Readline library
When I asked on the mailing list about this a year ago, I think I was told that it wasn't exactly supported any longer. So rather than trying to get GHC to compile ReadLine in, I used green-card instead. The attached file gives you the very simplest readline function. If you want to try to get GHC to include it, you could start by adding GhcLibsWithReadline = YES readlineIncludePath = -- where readline is HAVE_READLINE = YES to your build.mk file. "Wojciech Moczydlowski, Jr" wrote: I've been just writing some program using Readline library and I've noticed that I haven't got Readline.hi in /usr/local/lib/ghc/imports/util. Moreover, as I checked my source, I've found that it hasn't been built at all - it's not even in fptools/hslibs/util/.depend. What could have caused it and, more important :), how to build it now? Khaliff TM [EMAIL PROTECTED] http://www2.ids.pl/~khaliff ReadLine.gc
Re: Importing instances without pangling Make
Simon Peyton-Jones wrote: | At the time of writing, I am waiting for yet another long | Haskell re-make of | lots of modules to complete. The frustrating thing is, that | at least 90% of these | remakes are actually completely unnecessary. OK, I have heard your cries, and have fixed GHC. Try it. Many thanks. I will, tomorrow . . .
Re: Which regular expression library?
Two further comments on RegexString: (1) I actually have to use Ian Jackson's excellent matchRegexAll function to do what I want. If this were documented and supported I would appreciate it. (2) While I can live without the facility (I think) it would nevertheless be nice to be able to toggle at least case sensitivity and line mode, as Regex allows you to do. Something like the attached modified version of RegexString should do the trick, without breaking anything. Simon Marlow wrote: I'm worried that Regex might be obsolescent. If I change to RegexString, can I be sure that it's going to stay and be supported for the next two years? Sure. We might change the name though - I'd like to rename RegexString to Regex if/when we replace Regex with a PCRE version. Cheers, Simon RegexString.lhs
Re: Recent Sparc breakage
Simon Marlow wrote: Sparc users in particular: I've identified some recent breakage in the Sparc port of GHC. If you've been experiencing crashes in binaries generated by a compiler built from recent (at least February) sources, then I've checked in a fix which might help. George, Marc: this probably fixes to the bugs you've both reported. The anon cvs repository should be updated around 1700 GMT today with the fix included (look for an update to fptools/ghc/rts/StgCRun.c). Cheers, Simon
Re: Recent Sparc breakage
Simon Marlow wrote: Sparc users in particular: I've identified some recent breakage in the Sparc port of GHC. If you've been experiencing crashes in binaries generated by a compiler built from recent (at least February) sources, then I've checked in a fix which might help. George, Marc: this probably fixes to the bugs you've both reported. The anon cvs repository should be updated around 1700 GMT today with the fix included (look for an update to fptools/ghc/rts/StgCRun.c). Hurrah. Many thanks to Simon Marlow for tracking down a particularly tiresome bug . . . Assuming he has, that is; if not I'll be complaining this time tomorrow . . .
Re: GHC include files
"Manuel M. T. Chakravarty" wrote: This is exactly what the `...-config' script that I was talking about is supposed to do. Now we can argue whether that should be part of `ghc' proper or an extra script. An extra script at least has the advantage that it is easier to maintain manual in case somebody moves a tree or so. On the other hand, wrapping it into the ghc command will make a version mismatch when someone moves files around slightly less likely.
Re: cvs update - patch: invalid options
Marc van Dongen wrote: Hello there, When doing cvs updates I get a lot of errors of the form patch: Invalid options. patch: Usage: patch [-blNR] [-c|-e|-n] [-d dir] [-D define] [-i patchfile]\ [-o outfile] [-p num] [-r rejectfile] [file] cvs update: could not patch ParseIface.y; will refetch Should I ignore these or look for a different patch? My first reaction would be to look for a different CVS, like GNU CVS 1.10. If you're already using that, get the GNU patch as well (which has many more options than most patches).
Re: GHC include files
"Manuel M. T. Chakravarty" wrote: Malcolm Wallace [EMAIL PROTECTED] wrote, Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I don't think this scheme would solve my problem at all. As has been pointed out before, I can already get the GHC include files appended by calling "ghc" and not "gcc". It's a good suggestion and one I shall probably follow. BUT it is not ideal because (a) ghc seems to munge up its arguments rather a lot - for example, it rearranges libraries which is a problem for Solaris when you are using the system linker; (b) if you had a huge C program to which you wanted to link a little Haskell, it would be silly to compile all the code in the C program with ghc, and it would also be silly to compile some C code with gcc and some with gcc. I'm not sure what would be best; perhaps what I want is ghc options which won't do any compiling, but just tell me where the include files and libraries are. So then I can type GHC_INCLUDES = `$(GHC) -display-includes` or something like that . . .
Re: GHC include files
I must admit I'm surprised by the reaction to my suggestion. Here /usr is shared between lots of machines and there is no question of my installing GHC in /usr/bin or anything like it. (The few system adminstrators here are all honest, overworked, and sadly incorruptible.) My original problem was that GHC installs the include files in prefix/lib/ghc-4.06/includes meaning you have to know the version number as well as the prefix. I suppose this makes sense where prefix is in fact /usr, but I actually make prefix depend on the version, so having to specify the version twice is redundant. At least my scheme means that (on the rare times when I can build from source . . .) I can store multiple CVS releases.
GHC include files
The latest binary distribution puts the GHC include files in "lib/ghc-4.06/includes", not "lib/includes" as older versions used to. This is a nuisance, because it means that there isn't any way a Makefile can refer to the includes without coding in the GHC version. Or is there? One needs access to the include files to get at, for example, Stg.h
Re: Importing instances without pangling Make
Part of the problem right now seems to be that GHC is wrongly rewriting (or perhaps touching) the .hi file even though nothing in it is altered. (This is clear because -hi-diffs is also on and not reporting anything). Thus even though I'm using -Onot -recomp it's still recompiling everything.
Floating-point nitpicking: floor(Inf) and floor(NaN)
floor(Inf) and floor(NaN) do not appear to be defined in Standard Haskell. (They both come down to "properFraction" which is only defined for Ratio.) This differs from (for example) the Standard ML Basis Library, where it is specified that floor(Int) should raise Overflow and floor(NaN) should raise Domain. Hence Hugs and GHC do different things. Hugs returns floor(Inf) = 0 and floor(NaN) = 0 GHC returns floor(Inf) = very very large integer and floor(NaN) = even larger integer. (This is because the GHC implementation of properFraction simply ignores the case of Inf/NaN and treats the artificially high exponent encoded in those floating-point numbers as if it were a real one.) My own opinion is that Standard ML is right here and that floor(x) should raise an exception (In Haskell terms, fail) when x does not correspond to a real number.
Re: Importing instances without pangling Make
George Russell wrote: This scheme is not the cleverest that could be devised. For example it is still necessary to recompile whole chains of modules if you add an import declaration. (Not to a system library, imports from those are counted as "stable" in GHCs and my system.) To fix this you would need to keep more information in the .hi file. Actually we can catch most of these cases too. Alter algorithm A so that if we have no changes to instances declarations in this file, the version numbers in directly imported modules are all the same, and the only change is that we import some modules we didn't import before, then only bump the version number if the import leads to new modules being imported which contain instance declarations. I think you can compute this at very close to zero cost at the start of compilation, when you are doing the imports.
Re: Importing instances without pangling Make
Malcolm Wallace wrote: Wrong. If B imports C and has no export list, nothing from C is re-exported, only definitions from B itself, with the single exception of C's instance decls. OK, but this has no influence at all on my suggestions except to make them work slightly better.
Re: Importing instances without pangling Make
Jon Fairbairn wrote: I'm afraid I've not gone through your detailed suggestions, but in the short term, would a crude hack that I used to use with Algol68C help? No, fraid not. GHC already does this hack anyway. Algol68C didn't have interface declarations. Still, nice to find someone else who remembers it.
Re: Importing instances without pangling Make
Sigbjorn Finne wrote: Seems like you're not using -recomp. No I'm not. What about documenting it somewhere?
Re: Importing instances without pangling Make
George Russell wrote: Sigbjorn Finne wrote: Seems like you're not using -recomp. No I'm not. What about documenting it somewhere? I take that back. I AM using it in the big program I mentioned, but I still get huge swathes of unnecessary compilations. Maybe it needs to be still cleverer.
Re: Trivial Haskell Concurrency problem
George Russell wrote: George Russell wrote: Exactly the same happens at the same time to Processor 2. Now somehow you have to distinguish between Processor 1 and Processor 2, because only one is going to get to lower the flags. But I don't think with the existing Concurrency extensions plus standard Haskell you can. I take that back. There's a fundamental error in this analysis. Concurrent Haskell allows you to get the ThreadId of the current thread, and ThreadId DOES implement Ord. I thought of this last night and tried to work out a way of making the thread with the least ThreadId win, but couldn't quite do it. But it may still be possible. I think I now have a solution to my original problem. As said before, if we had a Unique type which implements ordering, it is easy, since we can attach one to each Flag, and make sure we take from the Flag with the lowest Uniq value first. I attach a file which implements Unique with NO global variables or unsafePerformIO, with comparison done in (at most) a logarithmic number of steps. The only fly in the ointment is that comparison itself has to construct the ordering on the fly, and so is an action and not a function. Also of course Marcin's suggested restrictions (Unique values must increase through the thread) cannot be implemented by this approach, since without global variables you can't know what order actions are called in. Unique.hs
Re: Trivial Haskell Concurrency problem
Tom Pledger wrote: For two threads to have access to the same MVar, they must have a common ancestor, right? Could a common ancestor spawn a transaction broker thread? That would be similar to what database management systems do. It'd still be centralised, but wouldn't need to do unsafe IO. Well, all threads trivially have a common ancestor. But I don't see how you can pick a particular ancestor. The flags could easily have been passed around in a fairly general fashion along polymorphic channels.
Re: Trivial Haskell Concurrency problem
Marcin 'Qrczak' Kowalczyk wrote: ...relative time of IO events that occured in a single thread. (=) imposes the sequencing. Yes OK. I see no problem with required elements of the Unique type to increase in a single thread. But I suspect anything stronger than this could slow things down and/or cause difficulties. BTW: The random generator from the IO monad seems to be not thread-safe. Oops. I think it should be either fixed or documented. Haha. That'll teach them to write global variables into the standard, won't it? That's why I said Integer, not Int :-) It's important in the application I have in mind (the Two-Flags problem is a real one in UniForM) that the Unique type be as fast as possible. So I really do not want it to be tied to any particular thing. For example I suggest that for GHC the most efficient implementation might be an Int64 or a 64-bit pointer (to nothing) on machines which support that, or when not a Double with incrementing done by the nextAfter function. Integer is just too slow. (You have to allocate two blocks of memory for it I think.)
Re: Trivial Haskell Concurrency problem
Marcin 'Qrczak' Kowalczyk wrote: If the IO monad can maintain a random number generator, it can as well mainain unique Integer supply. The interface is clean. It can, but according to the current specification, it doesn't. Maybe it should. I think Integer is a little too specific - how about type Unique implements (Ord,Eq) newUnique :: IO Unique ? And what about having unsafePtrCompare in addition to IOExts.unsafePtrEq? I don't think unsafePtrCompare will get us out of jail here. Compacting garbage collection might change the order of the pointers around inbetween one thread comparing them and the other.
Trivial Haskell Concurrency problem
Sorry if you don't want to be bothered with my problems, but I think this problem which I've just encountered is rather amusing. Is there a neat solution? I confess to finding concurrency problems difficult so there might be. I want to implement a type Flag. Each flag is either Up or Down. When you create a flag (there is a newFlag :: IO Flag operation) it is Up. The only operation permitted on Flags is lowerFlags :: Flag - Flag - IO Bool If both arguments are Up, lowerFlags should lower them both and return True, otherwise it should leave them as they are and return False. The problem is that lowerFlags should appear to be atomic, so that if lowerFlags is called simultaneously in different threads, the result should be the same as if one of the calls completed before the other started. So for example the following code type Flag = MVar Bool -- True means Up newFlag = newMVar True lowerFlags flag1 flag2 = if (flag1 == flag2) then error "Illegal call to lowerFlags" -- this is not allowed else do val1 - takeMVar flag1 -- point A val2 - takeMVar flag2 let success = (val1 val2) putMVar flag2 (not success val2) putMVar flag1 (not success val1) won't work, because if lowerFlags is called simultaneously with the same arguments but in a different order, and both calls reach point A simultanously, then both threads will block when they attempt the takeMVar in the next line. What is the neatest solution? There is an obvious solution, which is to crudely sequence all calls to lowerFlags by making them lock a single global variable (created using, sigh, unsafePerformIO) but this doesn't seem very elegant. If MVar's were instances of Ord as well as Eq, a neat solution would be to always get the least MVar first, but they aren't. So what should one do?
Re: glasgow-haskell-docs.html.tar.gz please
Simon Marlow wrote: The binary dists all have pre-formatted HTML and PS docs, so you could just download one of those (except it seems the link to the Linux binary dist is currently broken; I'll fix that shortly, in the meantime there's the solaris binary dist). I think perhaps you are mistaken. There are ps versions of the documents but not HTML ones in the Solaris distribution. tar -tzf ghc-4.06-sparc-sun-solaris2.tar.gz | grep html fptools/html/ (and nothing else)
./configure quibble
Why doesn't the configure script have a --with-happy option? There are --with-gcc and --with-hc to tell configure where to find gcc and GHC.
