From simonpj@microsoft.com Wed Nov 1 10:34:37 2000
Date: Wed, 1 Nov 2000 02:34:37 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: ppr for Haskell Abstract Syntax
GHC has a pretty printer for Haskell. It's in ghc/compiler/hsSyn/*.lhs,
along with the (numerous) data type declarations that define the
full Haskell syntax. It would take a little work to rip it out
of GHC, mind you
Simon
| -----Original Message-----
| From: Kate S. Golder [mailto:kgolder@wellesley.edu]
| Sent: 31 October 2000 21:07
| To: glasgow-haskell-users@haskell.org
| Subject: ppr for Haskell Abstract Syntax
|
|
| Hi -
| I was wondering if anyone knows if there is a pretty printer
| for Haskell
| Abstract Syntax anywhere? I've been asking around, but
| haven't located
| one yet. If you know of one that I could use, it would be
| really helpful!
| Thanks in advance,
| *Kate
|
| **********************
| Kate S. Golder
| Wellesley College
| Class of 2002
|
| Freeman Hall
| Wellesley College
| Wellesley, Ma 02481
|
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simonmar@microsoft.com Wed Nov 1 12:16:50 2000
Date: Wed, 1 Nov 2000 04:16:50 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: ppr for Haskell Abstract Syntax
> Hi -
> I was wondering if anyone knows if there is a pretty printer
> for Haskell
> Abstract Syntax anywhere? I've been asking around, but
> haven't located
> one yet. If you know of one that I could use, it would be
> really helpful!
> Thanks in advance,
> *Kate
We have one in GHC's CVS source tree now. hslibs/hssource contains a
Haskell abstract syntax, parser, and a pretty printer. It should compile on
pretty much any version of GHC, but you'll probably need a recent version of
Happy (1.8) for the parser.
Cheers,
Simon
From chak@cse.unsw.edu.au Thu Nov 2 08:08:25 2000
Date: Thu, 02 Nov 2000 19:08:25 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Quick question re RULES
PrelBase contains the appended code. Am I correct in
assuming that the stuff is structured as it is, because the
"map" rule first `breaks' the map `open', which exposes it
to the various foldr/build rules, and if no foldr/build rule
matches, the "mapList" rule `closes' it again in a later
phase of optimisation - after build was inlined? If so, it
seems like the whole thing depends a bit on the timing of
the various optimsations (the map might be closed again
before any of the foldr/build rules fires). Is this maybe
the reason that build has an INLINE 2 pragma, which delays
its inlining, and thus, the closing of the map?
All very cunning, it seems ;-)
Cheers,
Manuel
-=-
map :: (a -> b) -> [a] -> [b]
map = mapList
-- Note eta expanded
mapFB :: (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst
mapFB c f x ys = c (f x) ys
mapList :: (a -> b) -> [a] -> [b]
mapList _ [] = []
mapList f (x:xs) = f x : mapList f xs
{-# RULES
"map" forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs)
"mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f.g)
"mapList" forall f. foldr (mapFB (:) f) [] = mapList f
#-}
From simonpj@microsoft.com Thu Nov 2 08:18:45 2000
Date: Thu, 2 Nov 2000 00:18:45 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Quick question re RULES
| PrelBase contains the appended code. Am I correct in
| assuming that the stuff is structured as it is, because the
| "map" rule first `breaks' the map `open', which exposes it
| to the various foldr/build rules, and if no foldr/build rule
| matches, the "mapList" rule `closes' it again in a later
| phase of optimisation - after build was inlined? If so, it
| seems like the whole thing depends a bit on the timing of
| the various optimsations (the map might be closed again
| before any of the foldr/build rules fires). Is this maybe
| the reason that build has an INLINE 2 pragma, which delays
| its inlining, and thus, the closing of the map?
That's exactly it.
| All very cunning, it seems ;-)
A bit too cunning for comfort. I wish I could think of a better
way to expose map's impl using build without paying a price
for doing so if it turns out not to fuse with anything. But so
far I've failed to do so.
Is this a propos of your new transformations for parallelism?
Simon
From chak@cse.unsw.edu.au Thu Nov 2 10:27:32 2000
Date: Thu, 02 Nov 2000 21:27:32 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Fun with GHC's optimiser
----Next_Part(Thu_Nov__2_21:27:30_2000_507)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Questions over questions arise in my quest to understand
GHC's code generator. In this nice little piece of STG
$w$snewPArray =
NO_CCS[] \r[ww w]
case newIntArray# [ww realWorld#] of wild {
(#,#) s2# mba# ->
case -# [ww 1] of y {
DEFAULT ->
let { wild1 = NO_CCS I#! [ww];
} in
case ># [0 y] of wild2 {
True -> PArray [wild1 mba#];
False ->
let {
$wgo2 =
NO_CCS[] \r[y1 y2]
let { a = NO_CCS PArray! [wild1 mba#];
} in
case w of wild3 {
I# e# ->
case writeIntArray# [mba# y1 e# y2] of s2#1 {
DEFAULT ->
case ==# [y1 y] of wild11 {
True -> (#,#) [s2#1 a];
False ->
case +# [y1 1] of stg_c2aL {
DEFAULT -> $wgo2 stg_c2aL s2#1
};
}
};
};
} in case $wgo2 0 s2# of wild3 { (#,#) ds r -> r; };
}
};
};
I am wondering whether there is a particular reason why the
optimiser doesn't pull the
(1) a = NO_CCS PArray! [wild1 mba#];
and the
(2) case w of wild3 {
I# e# ->
out off the $wgo2 loop - or at least push (1) down into the
True branch of `case ==# [y1 y] of'. I would say that (1)
in this form pointlessly allocates heap like mad, but is
only using one of the many copies of `a', namely the one
allocated in the final iteration and returned to the caller.
As for (2), the loop would be nice and straight if that
unboxing where outside of the loop - as it is, we break the
pipeline once per iteration it seems (if the branch
prediction isn't very clever).
Or do I misunderstand something here, or is there maybe some
magic after STG that gets rid of the stuff?
I attach the Haskell source, which I compiled with
ghc -O -c PArrays.hs -fglasgow-exts -ddump-stg
(This is 4.08.1 of course.)
Also if somebody is looking at the attached source, I was
wondering why, when I use the commented out code in
`newPArray', I get a lot worse code (the STG code is in a
comment at the end of the file). In particular, the lambda
abstraction is not inlined, whereas `fill' gets inlined into
the code of which the dump is above. Is it because the
compiler has a lot harder time with explicit recursion than
with fold/build? If so, the right RULES magic should allow
me to do the same for my own recursively defined
combinators, shouldn't it?
Cheers,
Manuel
PS: Otherwise, it is quite impressive what the RULES and
inliner do to the foldr that produced the above code.
----Next_Part(Thu_Nov__2_21:27:30_2000_507)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="PArrays.hs"
-- Parallel Arrays: Sequential prototype
--
-- Authors: Manuel M. T. Chakravarty
-- Gabriele Keller
-- Created: 26 October 2000
--
-- Version $Revision$ from $Date$
--
-- Copyright (c) 2000 Chakravarty & Keller
--
-- This file is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This file is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
--- DESCRIPTION ---------------------------------------------------------------
--
-- This module provides unboxed arrays of primitive types as a sequential
-- prototype for the parallel arrays of Gabi's SCL. They come with all the
-- necessary operations to support flattened Haskell generated from lambdaPA.
--
--- DOCU ----------------------------------------------------------------------
--
-- language: Haskell 98 + GHC extensions (unboxed types and byte arrays)
--
-- We export the immutable `PArray' only; however, we internally also use a
-- mutable variant `MPArray', which allows us an efficient incremental
-- definition of the collective structure.
--
-- The class `PAE' is quite peculiar. It essentially serves to overload
-- array access (which depends on the size of the unboxed value stored in the
-- parallel array); however, the actual operations in the class are only to
-- be used internally in this module - and therefore, the class `PAE' is
-- exported *abstractly*. In fact, most operations work on mutable parallel
-- arrays for efficiency.
--
-- We shamelessly steal coding tricks from GHC's `ArrayBase', `IArray' &
-- friends, but without most of that overloading mess.
--
--- TODO ----------------------------------------------------------------------
--
module PArrays (
PAE, PArray, newPArray, (!|), loop, gen
) where
-- infixl 9 !|
import PrelGHC
import PrelBase
import PrelST
import ST
-- data structures
-- ---------------
-- * although all `PArray's are represented by the same structure, the
-- functions operating on them differ with the element type; hence, we have
-- to overload these functions
-- integer indexed array (EXPORTED ABSTRACTLY)
--
data PArray e = PArray Int ByteArray#
-- mutable integer indexed array
--
data MPArray s e = MPArray Int (MutableByteArray# s)
-- the class of "Parallel Array Element"s (EXPORTED ABSTRACTLY)
--
class PAE a where
newMPArray :: Int -> ST s (MPArray s a)
readMPArray :: MPArray s a -> Int -> ST s a
writeMPArray :: MPArray s a -> Int -> a -> ST s ()
indexPArray :: PArray a -> Int -> a
-- exported functions
-- ------------------
-- create new parallel array, where all elements are initialised to the given
-- values (EXPORTED)
--
newPArray :: PAE e => Int -> e -> PArray e
newPArray n e = runST (do
mpa <- newMPArray n
-- simpleGen n $
-- \i -> writeMPArray mpa i e
-- return $ unsafeFreezeMPArray mpa)
foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1]) -- a la ArrayBase
{-# SPECIALIZE newPArray :: Int -> Int -> PArray Int #-}
fill mpa e i next = writeMPArray mpa i e >> next
-- indexing of a parallel array (EXPORTED)
--
(!|) :: PAE e => PArray e -> Int -> e
(!|) = indexPArray
-- Gabi's loop (EXPORTED)
--
loop :: () -- ??
loop = error "loop?"
-- Gabi's gen (EXPORTED)
--
gen :: () -- ??
gen = error "gen??"
-- instances of `PAE'
-- ------------------
instance PAE Int where
newMPArray = newMPArrayInt
readMPArray = readMPArrayInt
writeMPArray = writeMPArrayInt
indexPArray = indexPArrayInt
newMPArrayInt :: Int -> ST s (MPArray s Int)
newMPArrayInt n@(I# n#) = ST $ \s# ->
case (newIntArray# n# s#) of {(# s2#, mba# #) ->
(# s2#, MPArray n mba# #)}
readMPArrayInt :: MPArray s Int -> Int -> ST s Int
{-# INLINE readMPArrayInt #-}
readMPArrayInt (MPArray _ mba#) (I# i#) = ST $ \s# ->
case readIntArray# mba# i# s# of {(# s2#, r# #) ->
(# s2#, I# r# #)}
writeMPArrayInt :: MPArray s Int -> Int -> Int -> ST s ()
{-# INLINE writeMPArrayInt #-}
writeMPArrayInt (MPArray _ mba#) (I# i#) (I# e#) = ST $ \s# ->
case writeIntArray# mba# i# e# s# of {s2# ->
(# s2#, () #)}
indexPArrayInt :: PArray Int -> Int -> Int
{-# INLINE indexPArrayInt #-}
indexPArrayInt (PArray _ ba#) (I# i#) =
case indexIntArray# ba# i# of {r# ->
(I# r#)}
-- auxilliary functions
-- --------------------
-- unsafely convert a mutable into an immutable array
--
unsafeFreezeMPArray :: MPArray s e -> PArray e
unsafeFreezeMPArray (MPArray n mba#) = PArray n (unsafeCoerce# mba#)
-- simple generator abstraction
--
simpleGen :: Monad m => Int -> (Int -> m ()) -> m ()
simpleGen 0 p = return ()
simpleGen n p = p (n - 1) >> simpleGen (n - 1) p
{-
-- That's what we get for a newPArray specialised for Int and using the
-- explicitly recursive simpleGen.
$wsimpleGen =
NO_CCS srt: (0,2)[] \r[ww w]
case ww of ds {
0 -> $wlvl1;
DEFAULT ->
let {
stg_c1Qg =
NO_CCS srt: (0,1)[] \r[s1]
case -# [ds 1] of a {
DEFAULT ->
let { stg_c1Lg = NO_CCS I#! [a];
} in
case w stg_c1Lg s1 of wild {
(#,#) new_s r -> $wsimpleGen a w new_s;
}
};
} in stg_c1Qg
};
SRT: [$wsimpleGen, $wlvl1]
$w$snewPArray =
NO_CCS srt: (0,1)[] \r[ww w]
case newIntArray# [ww realWorld#] of wild {
(#,#) s2# mba# ->
let {
stg_c1M1 =
NO_CCS[] \r[i]
case i of wild1 {
I# i# ->
case w of wild2 {
I# e# ->
let {
stg_c1Q7 =
NO_CCS[] \r[s#]
case writeIntArray# [mba# i# e# s#] of s2#1 {
DEFAULT -> (#,#) [s2#1 ()]
};
} in stg_c1Q7;
};
};
} in
case $wsimpleGen ww stg_c1M1 s2# of wild1 {
(#,#) new_s r -> let { a = NO_CCS I#! [ww]; } in (#,#) [a mba#];
};
};
SRT: [$wsimpleGen]
-- the `case w of' could be pulled out of the loop
-- stg_c1Q7 builds a superfluous closure (which is immediately entered)
-- could we somehow get a specialised version of simpleGen?
-}
----Next_Part(Thu_Nov__2_21:27:30_2000_507)----
From simonmar@microsoft.com Thu Nov 2 12:18:51 2000
Date: Thu, 2 Nov 2000 04:18:51 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: Fun with GHC's optimiser
> I am wondering whether there is a particular reason why the
> optimiser doesn't pull the
>
> (1) a = NO_CCS PArray! [wild1 mba#];
>
> and the
>
> (2) case w of wild3 {
> I# e# ->
I checked with the before-ghci-branch compiler, and it pulls out (1) but not
(2). Simon did a fair amount of work on improving the compilation of IO-ish
code and code with lots of newtypes in it after we noticed some problems
like the ones you point out above. We'll need to investigate whether the
case can be pulled out of the loop too, though.
Cheers,
Simon
From simonpj@microsoft.com Thu Nov 2 12:46:41 2000
Date: Thu, 2 Nov 2000 04:46:41 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Fun with GHC's optimiser
I can never resist messages like these, even when I'm meant
to be doing other things. It's very helpful when people offer
fairly precise performance-bug reports. Thanks!
| I am wondering whether there is a particular reason why the
| optimiser doesn't pull the
|
| (1) a = NO_CCS PArray! [wild1 mba#];
This one is a definite bug. It turns out that the head of the
before-ghci-branch doesn't have this bug, so I'm disinclined
to investigate it further.
| (2) case w of wild3 {
| I# e# ->
|
| As for (2), the loop would be nice and straight if that
| unboxing where outside of the loop - as it is, we break the
| pipeline once per iteration it seems
This one is a bit harder. Basically we want to make a wrapper
for a recursive function if it's sure to evaluate its free variables.
In fact the 'liberate-case' pass (which isn't switched on in 4.08)
is meant to do just this. It's in simplCore/LiberateCase.lhs,
and it's not very complicated. I've just tried it and it doesn't seem
to have the desired effect, but I'm sure that's for a boring reason.
If anyone would like to fix it, go ahead!
(You can't just say '-fliberate-case' on the command line to make
it go; you have to add -fliberate-case at a sensible point to the
minusOflags in driver/Main.hs.)
Incidentally, you'll find that -ddump-simpl gives you a dump that
is pretty close to STG and usually much more readable. Most
performance bugs show up there. -dverbose-simpl gives you more
clues about what is happening where.
| Also if somebody is looking at the attached source, I was
| wondering why, when I use the commented out code in
| `newPArray', I get a lot worse code (the STG code is in a
| comment at the end of the file). In particular, the lambda
| abstraction is not inlined, whereas `fill' gets inlined into
| the code of which the dump is above. Is it because the
| compiler has a lot harder time with explicit recursion than
| with fold/build? If so, the right RULES magic should allow
| me to do the same for my own recursively defined
| combinators, shouldn't it?
I couldn't figure out exactly what you meant. The only commented
out code is STG code. Maybe send a module with the actual
source you are bothered about.
S
From chak@cse.unsw.edu.au Thu Nov 2 12:15:02 2000
Date: Thu, 02 Nov 2000 23:15:02 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Quick question re RULES
Simon Peyton-Jones <simonpj@microsoft.com> wrote,
> Is this a propos of your new transformations for parallelism?
Precisely! Trying to figure out how to generate the fastest
possible array code with GHC.
Manuel
From lizard@Xterminator.STUDFB.UniBw-Muenchen.de Thu Nov 2 13:39:22 2000
Date: Thu, 2 Nov 2000 14:39:22 +0100
From: Oliver Braun lizard@Xterminator.STUDFB.UniBw-Muenchen.de
Subject: fatal error: heapCensus
Dear GHC-Users,
I am currently developing part of the EdComb library
(http://ist.unibw-muenchen.de/EdComb/).
I have compiled all files with the -prof and the -auto-all flag.
When starting the program
* without any RTS options -> everything is OK
* with +RTS -p -> everything is OK
* with +RTS -h -> fatal error: heapCensus
I am using GHC version 4.08.1 on a Debian/GNU Linux Box,
installed with the newest Debian packages from
http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian.
Olli
--
Federal Armed Forces University Munich Tel. 089 - 60190686
Werner-Heisenberg-Weg 102/128 Fax. 089 - 244333158
85577 Neubiberg mobil 0170 - 9317618
From chak@cse.unsw.edu.au Thu Nov 2 13:54:25 2000
Date: Fri, 03 Nov 2000 00:54:25 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Fun with GHC's optimiser
----Next_Part(Fri_Nov__3_00:54:22_2000_559)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Simon Peyton-Jones <simonpj@microsoft.com> wrote,
> I can never resist messages like these, even when I'm meant
> to be doing other things.
That's good to know ;-)
> It's very helpful when people offer
> fairly precise performance-bug reports. Thanks!
Thanks for the prompt reply! To SimonM, too.
> | I am wondering whether there is a particular reason why the
> | optimiser doesn't pull the
> |
> | (1) a = NO_CCS PArray! [wild1 mba#];
>
> This one is a definite bug. It turns out that the head of the
> before-ghci-branch doesn't have this bug, so I'm disinclined
> to investigate it further.
No problem, I can always build a new ghc from CVS.
> | (2) case w of wild3 {
> | I# e# ->
> |
> | As for (2), the loop would be nice and straight if that
> | unboxing where outside of the loop - as it is, we break the
> | pipeline once per iteration it seems
>
> This one is a bit harder. Basically we want to make a wrapper
> for a recursive function if it's sure to evaluate its free variables.
>
> In fact the 'liberate-case' pass (which isn't switched on in 4.08)
> is meant to do just this. It's in simplCore/LiberateCase.lhs,
> and it's not very complicated. I've just tried it and it doesn't seem
> to have the desired effect, but I'm sure that's for a boring reason.
> If anyone would like to fix it, go ahead!
Ok - something for a rainy weekend, I guess...
> Incidentally, you'll find that -ddump-simpl gives you a dump that
> is pretty close to STG and usually much more readable. Most
> performance bugs show up there. -dverbose-simpl gives you more
> clues about what is happening where.
Good to know. I just wasn't sure whether I wouldn't miss
out on some optimisations.
> | Also if somebody is looking at the attached source, I was
> | wondering why, when I use the commented out code in
> | `newPArray', I get a lot worse code (the STG code is in a
> | comment at the end of the file). In particular, the lambda
> | abstraction is not inlined, whereas `fill' gets inlined into
> | the code of which the dump is above. Is it because the
> | compiler has a lot harder time with explicit recursion than
> | with fold/build? If so, the right RULES magic should allow
> | me to do the same for my own recursively defined
> | combinators, shouldn't it?
>
> I couldn't figure out exactly what you meant. The only commented
> out code is STG code. Maybe send a module with the actual
> source you are bothered about.
Appended the version of the module where the code is
activated (it was commented out with --) - you'll find the
problematic code by searching for (**) in the code. It
generates
$w$snewPArray
= \ ww :: Int# w :: Int ->
case newIntArray# @ RealWorld ww realWorld#
of wild { (# s2#, mba# #) ->
case $wsimpleGen
ww
(\ i :: Int ->
case i of wild1 { I# i# ->
case w of wild2 { I# e# ->
__coerce (ST RealWorld ())
(\ s# :: (State# RealWorld) ->
case writeIntArray# @ RealWorld mba# i# e# s#
of s2#1 { __DEFAULT ->
(# s2#1, () #)
})
}
})
s2#
of wild1 { (# new_s, r #) ->
let {
a :: Int
a = $wI# ww
} in (# a, (__coerce ByteArray# mba#) #)
}
}
One thing that is not nice is in the lambda abstraction
based to $wsimpleGen. There is one lambda, then two
unboxing operations and another lambda for the state
variables s#. These two nested lambda's become in STG
stg_c1Op =
NO_CCS[] \r[i]
case i of wild1 {
I# i# ->
case w of wild2 {
I# e# ->
let {
stg_c1Sv =
NO_CCS[] \r[s#]
case writeIntArray# [mba# i# e# s#] of s2#1 {
DEFAULT -> (#,#) [s2#1 ()]
};
} in stg_c1Sv;
};
};
So, stg_c1Sv is allocated and immediately entered. I would
have hoped that the two lambda abstractions are merged into
something like this:
(\ i :: Int s# :: (State# RealWorld) ->
case i of wild1 { I# i# ->
case w of wild2 { I# e# ->
case writeIntArray# @ RealWorld mba# i# e# s#
of s2#1 { __DEFAULT -> (# s2#1, () #)
})
}
})
Maybe it is the __coerce, which prevents this from
happening?
Also, I am wondering why in the case of the
foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1])
the function `fill' gets inlined into the foldr loop, but in
the above, the lambda abstraction gets not inlined into
$wsimpleGen. Maybe it is because $wsimpleGen itself gets
not inlined...
Cheers,
Manuel
----Next_Part(Fri_Nov__3_00:54:22_2000_559)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="PArrays.hs"
-- Parallel Arrays: Sequential prototype
--
-- Authors: Manuel M. T. Chakravarty
-- Gabriele Keller
-- Created: 26 October 2000
--
-- Version $Revision$ from $Date$
--
-- Copyright (c) 2000 Chakravarty & Keller
--
-- This file is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This file is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
--- DESCRIPTION ---------------------------------------------------------------
--
-- This module provides unboxed arrays of primitive types as a sequential
-- prototype for the parallel arrays of Gabi's SCL. They come with all the
-- necessary operations to support flattened Haskell generated from lambdaPA.
--
--- DOCU ----------------------------------------------------------------------
--
-- language: Haskell 98 + GHC extensions (unboxed types and byte arrays)
--
-- We export the immutable `PArray' only; however, we internally also use a
-- mutable variant `MPArray', which allows us an efficient incremental
-- definition of the collective structure.
--
-- The class `PAE' is quite peculiar. It essentially serves to overload
-- array access (which depends on the size of the unboxed value stored in the
-- parallel array); however, the actual operations in the class are only to
-- be used internally in this module - and therefore, the class `PAE' is
-- exported *abstractly*. In fact, most operations work on mutable parallel
-- arrays for efficiency.
--
-- We shamelessly steal coding tricks from GHC's `ArrayBase', `IArray' &
-- friends, but without most of that overloading mess.
--
--- TODO ----------------------------------------------------------------------
--
module PArrays (
PAE, PArray, newPArray, (!|), loop, gen
) where
import PrelGHC
import PrelBase
import PrelST
import ST
infixl 9 !|
-- data structures
-- ---------------
-- * although all `PArray's are represented by the same structure, the
-- functions operating on them differ with the element type; hence, we have
-- to overload these functions
-- integer indexed array (EXPORTED ABSTRACTLY)
--
data PArray e = PArray Int ByteArray#
-- mutable integer indexed array
--
data MPArray s e = MPArray Int (MutableByteArray# s)
-- the class of "Parallel Array Element"s (EXPORTED ABSTRACTLY)
--
class PAE a where
newMPArray :: Int -> ST s (MPArray s a)
readMPArray :: MPArray s a -> Int -> ST s a
writeMPArray :: MPArray s a -> Int -> a -> ST s ()
indexPArray :: PArray a -> Int -> a
-- exported functions
-- ------------------
-- create new parallel array, where all elements are initialised to the given
-- values (EXPORTED)
--
newPArray :: PAE e => Int -> e -> PArray e
newPArray n e = runST (do
mpa <- newMPArray n
simpleGen n $ -- (**) These three lines instead
\i -> writeMPArray mpa i e -- of the following commented
return $ unsafeFreezeMPArray mpa) -- out line gives worse code.
-- foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1]) -- a la ArrayBase
{-# SPECIALIZE newPArray :: Int -> Int -> PArray Int #-}
fill mpa e i next = writeMPArray mpa i e >> next
-- indexing of a parallel array (EXPORTED)
--
(!|) :: PAE e => PArray e -> Int -> e
(!|) = indexPArray
-- Gabi's loop (EXPORTED)
--
loop :: () -- ??
loop = error "loop?"
-- Gabi's gen (EXPORTED)
--
gen :: () -- ??
gen = error "gen??"
-- instances of `PAE'
-- ------------------
instance PAE Int where
newMPArray = newMPArrayInt
readMPArray = readMPArrayInt
writeMPArray = writeMPArrayInt
indexPArray = indexPArrayInt
newMPArrayInt :: Int -> ST s (MPArray s Int)
newMPArrayInt n@(I# n#) = ST $ \s# ->
case (newIntArray# n# s#) of {(# s2#, mba# #) ->
(# s2#, MPArray n mba# #)}
readMPArrayInt :: MPArray s Int -> Int -> ST s Int
{-# INLINE readMPArrayInt #-}
readMPArrayInt (MPArray _ mba#) (I# i#) = ST $ \s# ->
case readIntArray# mba# i# s# of {(# s2#, r# #) ->
(# s2#, I# r# #)}
writeMPArrayInt :: MPArray s Int -> Int -> Int -> ST s ()
{-# INLINE writeMPArrayInt #-}
writeMPArrayInt (MPArray _ mba#) (I# i#) (I# e#) = ST $ \s# ->
case writeIntArray# mba# i# e# s# of {s2# ->
(# s2#, () #)}
indexPArrayInt :: PArray Int -> Int -> Int
{-# INLINE indexPArrayInt #-}
indexPArrayInt (PArray _ ba#) (I# i#) =
case indexIntArray# ba# i# of {r# ->
(I# r#)}
-- auxilliary functions
-- --------------------
-- unsafely convert a mutable into an immutable array
--
unsafeFreezeMPArray :: MPArray s e -> PArray e
unsafeFreezeMPArray (MPArray n mba#) = PArray n (unsafeCoerce# mba#)
-- simple generator abstraction
--
simpleGen :: Monad m => Int -> (Int -> m ()) -> m ()
{-# INLINE simpleGen #-}
simpleGen 0 p = return ()
simpleGen n p = p (n - 1) >> simpleGen (n - 1) p
{-
-- That's what we get for a newPArray specialised for Int and using the
-- explicitly recursive simpleGen.
$wsimpleGen =
NO_CCS srt: (0,2)[] \r[ww w]
case ww of ds {
0 -> $wlvl1;
DEFAULT ->
let {
stg_c1Qg =
NO_CCS srt: (0,1)[] \r[s1]
case -# [ds 1] of a {
DEFAULT ->
let { stg_c1Lg = NO_CCS I#! [a];
} in
case w stg_c1Lg s1 of wild {
(#,#) new_s r -> $wsimpleGen a w new_s;
}
};
} in stg_c1Qg
};
SRT: [$wsimpleGen, $wlvl1]
$w$snewPArray =
NO_CCS srt: (0,1)[] \r[ww w]
case newIntArray# [ww realWorld#] of wild {
(#,#) s2# mba# ->
let {
stg_c1M1 =
NO_CCS[] \r[i]
case i of wild1 {
I# i# ->
case w of wild2 {
I# e# ->
let {
stg_c1Q7 =
NO_CCS[] \r[s#]
case writeIntArray# [mba# i# e# s#] of s2#1 {
DEFAULT -> (#,#) [s2#1 ()]
};
} in stg_c1Q7;
};
};
} in
case $wsimpleGen ww stg_c1M1 s2# of wild1 {
(#,#) new_s r -> let { a = NO_CCS I#! [ww]; } in (#,#) [a mba#];
};
};
SRT: [$wsimpleGen]
-- the `case w of' could be pulled out of the loop
-- stg_c1Q7 builds a superfluous closure (which is immediately entered)
-- could we somehow get a specialised version of simpleGen?
-}
----Next_Part(Fri_Nov__3_00:54:22_2000_559)----
From lizard@Xterminator.STUDFB.UniBw-Muenchen.de Thu Nov 2 14:56:24 2000
Date: Thu, 2 Nov 2000 15:56:24 +0100
From: Oliver Braun lizard@Xterminator.STUDFB.UniBw-Muenchen.de
Subject: fatal error: heapCensus
Hi again,
unfortunately I forgot to ask my questions ;o)
What does heapCensus mean ?
What can I do to avoid this error ?
> I have compiled all files with the -prof and the -auto-all flag.
>
> When starting the program
>
> * without any RTS options -> everything is OK
> * with +RTS -p -> everything is OK
> * with +RTS -h -> fatal error: heapCensus
>
> I am using GHC version 4.08.1 on a Debian/GNU Linux Box,
> installed with the newest Debian packages from
> http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian.
Olli
--
Federal Armed Forces University Munich Tel. 089 - 60190686
Werner-Heisenberg-Weg 102/128 Fax. 089 - 244333158
85577 Neubiberg mobil 0170 - 9317618
From simonpj@microsoft.com Thu Nov 2 17:11:47 2000
Date: Thu, 2 Nov 2000 09:11:47 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: My mistake is harder to diagnose than it could be
In the new GHCi system we plan to make it *required* that the module name
and the file name
match, EXCEPT for module Main.
This seems to remove a whole class of errors.
Yell if that'll be problematic for you
Simon
| -----Original Message-----
| From: qrczak@knm.org.pl [mailto:qrczak@knm.org.pl]
| Sent: 18 August 2000 19:45
| To: glasgow-haskell-users@haskell.org
| Subject: My mistake is harder to diagnose than it could be
|
|
| I've just done the same mistake a third time: took a module A, moved
| part of it to a new module B, imported A from B, but forgot to change
| the module header in B which still said "module A".
|
| The GHC's answer to that when compiling B.hs is that the module A
| does not export a bunch of things (if listed explicitly in import),
| or that they are not found at all (if imported the whole A). Things
| that are easily seen exported from A.hs - strange that I was wondering
| again what's going on.
|
| GHC should warn when a module imports itself. Or warn about mismatches
| between the module and file name except Main. Or whatever -
| the current
| error message is not very helpful.
|
| --
| __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
| \__/
| ^^ SYGNATURA ZASTEPCZA
| QRCZAK
|
|
From simonmar@microsoft.com Fri Nov 3 10:02:25 2000
Date: Fri, 3 Nov 2000 02:02:25 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: fatal error: heapCensus
> unfortunately I forgot to ask my questions ;o)
>
> What does heapCensus mean ?
It's an internal error in GHC's heap profiler, and indicates a bug
somewhere. Could you send us the code?
Cheers,
Simon
From rrt1001@cam.ac.uk Mon Nov 6 12:21:40 2000
Date: Mon, 6 Nov 2000 12:21:40 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: New InstallShield
Yet another improvement to the GHC 4.08.1 InstallShield. Thanks to Christian
Lescher and Sigbjorn Finne, various bugs have been fixed to do with DLL
building, so both static DLLs (where all the haskell stuff is linked in) and
dynamic DLLs (where the DLL you build is dependent on the GHC DLLs) work
rather better.
Also, thanks to Martijn Schrage for pointing out that I'd omitted the net
hslib from the InstallShield. It's there now.
--
http://sc3d.org/rrt/ | certain, a. insufficiently analysed
From stolz@I2.Informatik.RWTH-Aachen.DE Tue Nov 7 13:56:28 2000
Date: Tue, 7 Nov 2000 14:56:28 +0100
From: Volker Stolz stolz@I2.Informatik.RWTH-Aachen.DE
Subject: Select.hSelect & Threads
Will Select.hSelect block all running Haskell threads? I assume it does. However,
the small explanation at the bottom of the documentation seems too convoluted to
me to convey it's meaning. How about adding "Remember that this will *block* *all*
*your* *threads*" to it?
--
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From bjpop@cs.mu.OZ.AU Fri Nov 10 05:56:15 2000
Date: Fri, 10 Nov 2000 16:56:15 +1100 (EST)
From: Bernard James POPE bjpop@cs.mu.OZ.AU
Subject: getting type information about local bindings
Hi all,
In GHC 4.09 the flag "-ddump-types" causes the type signatures of
top-level bound identifiers to be printed.
I would really like to make use of the type-checker in GHC, however, I would
also like to obtain the types of locally bound identifiers
(things in let expressions and where clauses). Obviously there is going to
be some trickery regarding type variables from enclosing scopes.
I looked in the TcModule.lhs module and noticed that the TcResults
value returned by typecheckModule contains a value environment that only
specifies the types of top bound identifiers.
Further investigation of the code led me to the TcBinds.lhs module
and the tcBindsAndThen function. I can see that local type environments
are not passed upwards during type checking/inference.
At some point I got lost in the code. Does anyone know of a reasonable means
for obtaining this type information? I don't mind doing some hacking, but
I wanted to get advise from the experts as to whether I might be wasting
my time.
Perhaps such a thing is done somewhere when generating Core code?
As an aside I dare say that such an extension would be useful to other
people, particularly those writing source transformation code.
Regards,
Bernie.
From simonpj@microsoft.com Fri Nov 10 09:23:28 2000
Date: Fri, 10 Nov 2000 01:23:28 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: getting type information about local bindings
Don't try to get the type environment out. Instead, look at the
syntax tree produced by the type checker. Each binder is an Id.
There's a function
idType :: Id -> Type
that tells you the type of each binder. Quite how you present it
to the user in a good way isn't clear to me,
Simon
| -----Original Message-----
| From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU]
| Sent: 10 November 2000 05:56
| To: glasgow-haskell-users@haskell.org
| Cc: bjpop@cs.mu.OZ.AU
| Subject: getting type information about local bindings
|
|
| Hi all,
|
| In GHC 4.09 the flag "-ddump-types" causes the type signatures of
| top-level bound identifiers to be printed.
|
| I would really like to make use of the type-checker in GHC,
| however, I would
| also like to obtain the types of locally bound identifiers
| (things in let expressions and where clauses). Obviously
| there is going to
| be some trickery regarding type variables from enclosing scopes.
|
| I looked in the TcModule.lhs module and noticed that the TcResults
| value returned by typecheckModule contains a value
| environment that only
| specifies the types of top bound identifiers.
|
| Further investigation of the code led me to the TcBinds.lhs module
| and the tcBindsAndThen function. I can see that local type
| environments
| are not passed upwards during type checking/inference.
|
| At some point I got lost in the code. Does anyone know of a
| reasonable means
| for obtaining this type information? I don't mind doing some
| hacking, but
| I wanted to get advise from the experts as to whether I might
| be wasting
| my time.
|
| Perhaps such a thing is done somewhere when generating Core code?
|
| As an aside I dare say that such an extension would be useful
| to other
| people, particularly those writing source transformation code.
|
| Regards,
| Bernie.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simonmar@microsoft.com Mon Nov 13 15:41:53 2000
Date: Mon, 13 Nov 2000 07:41:53 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: Select.hSelect & Threads
> Will Select.hSelect block all running Haskell threads? I
> assume it does. However,
> the small explanation at the bottom of the documentation
> seems too convoluted to
> me to convey it's meaning. How about adding "Remember that
> this will *block* *all*
> *your* *threads*" to it?
Thanks. I've rewritten this section to be clearer. It does indeed block
all Haskell threads.
Cheers,
Simon
From christian@lescher.de Mon Nov 13 18:24:14 2000
Date: Mon, 13 Nov 2000 19:24:14 +0100
From: Christian Lescher christian@lescher.de
Subject: Bug in GHC's Garbage Collection? (fwd) - C Strings
Hi Simon,
> > 1) How to convert the Haskell string to a C string? - There's
> > a function
> >
> > packCString# :: [Char] -> ByteArray#
> > packCString# str = case (packString str) of { ByteArray _ _ bytes ->
> > bytes }
> >
> > in CStrings.lhs / PrelPack.lhs, which I probably have to use.
>
> Yes (but use packString rather than packString#).
Okay, so I have use: packString :: [Char] -> ByteArray Int
btw: what's the difference between packString and packCString then?
> > 2) How to pass a pointer (Addr) of the converted string back
> > to the outside
> > world?
>
> You can pass the ByteArray directly to a foreign imported function (which
> *must* be declared unsafe - you can't pass ByteArrays to safe ccalls).
I think, here the context got lost: I want to expose a Haskell function with
a string result rather than calling a C function from Haskell.
> > 3) Who is responsible for freeing the memory of the string result? I
> > suppose this should be done outside. But what to do that GHC's garbage
> > collection doesn't free it automatically?
>
> The ByteArray is freed automatically by GHC's garbage collector. If you
> need something more permanent, use malloc/free and the functions from
> Storable to do the marshalling.
For instance, how would you define a function like
revstr :: String -> String
revstr s = reverse s
for foreign export?
(The conversion of the string argument I handled like this:)
strlength :: Addr -> IO Int
strlength cstr = do
s <- unpackCStringIO cstr
return (length s)
foreign export stdcall strlength :: Addr -> IO Int
Cheers, Christian
P.S. I think, some information on the handling of typical string conversion
problems would be an interesting topic for GHC's user's manual, too.
From marte@pms.informatik.uni-muenchen.de Tue Nov 14 17:58:28 2000
Date: Tue, 14 Nov 2000 18:58:28 +0100 (CET)
From: Michael Marte marte@pms.informatik.uni-muenchen.de
Subject: Problems with libgmp
Hello,
I am maintaining the Haskell stuff at informatik.uni-muenchen.de.
(I took over the job from Sven Panne.)
As a first exercise, I try to compile ghc-4.08.1 from scratch.
But I always run into trouble with the libgmp stuff.
IMHO, my problems are caused by several factors:
1. We use Suse Linux 7.0 (that provides libgmp-3.0.x).
2. The ghc-4.08-1 distribution includes libgmp-2.x.x.
3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names
are generated only if the header file is included.
4. The configure script does not recognize that libgmp is
installed (because it does not include the header file.)
5. When linking, the linker cannot resolve symbols prefixed by mpz_
(because the 2.x.x header file was used in compilation but the
linker uses the shared library provided by Suse Linux.)
5. Even if informed about the local installation of libgmp (by manually
changing config.cache), the 2.x.x header file will be used (again
resulting in unresolved bindings when linking).
The same problems occur when bootstrapping from .hc files.
What to do? Should I hack the Makefiles? Should I replace the libgmp
distribution included in the ghc distribution by some new 3.x.x
distribution?
Thank you,
Michael Marte
From romildo@urano.iceb.ufop.br Wed Nov 15 05:15:53 2000
Date: Wed, 15 Nov 2000 03:15:53 -0200
From: =?iso-8859-1?Q?Jos=E9_Romildo_Malaquias?= romildo@urano.iceb.ufop.br
Subject: The Parsec library distributed with GHC
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Hello.
The Parsec library (in package text from hslibs)
distributed with GHC 4.08.1 and from CVS does not
work as expected. When I try the attached
program, ghc gives me error messages:
=================================
test.hs:6:
Couldn't match `TokenParser' against `[Char]'
Expected type: TokenParser
Inferred type: [Char]
In the first argument of `symbol', namely `"let"'
In a do statement: symbol "let"
test.hs:12:
Ambiguous type variable(s) `a' in the constraint `Show a'
arising from use of `print' at test.hs:12
In the right-hand side of an equation for `main':
print (parse pLet "" "let a = 232")
Compilation had errors
=================================
This same program works if I use the Parsec library
downloaded from the author page <http://www.cs.uu.nl/~daan>
(after correcting a small bug relative to using some
names from the Char module without importing them).
I hope the library gets updated in the GHC CVS repository
and the next GHC release corrects this problem.
Regards,
Romildo
--
Prof. José Romildo Malaquias <romildo@iceb.ufop.br>
Departamento de Computação
Universidade Federal de Ouro Preto
Brasil
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test.hs"
module Main where
import Parsec
import ParsecToken
pLet = do symbol "let"
id <- identifier
symbol "="
x <- integer
return (id,x)
main = print (parse pLet "" "let a = 232")
--VS++wcV0S1rZb1Fb--
From simonmar@microsoft.com Wed Nov 15 09:50:04 2000
Date: Wed, 15 Nov 2000 01:50:04 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: Problems with libgmp
> I am maintaining the Haskell stuff at informatik.uni-muenchen.de.
> (I took over the job from Sven Panne.)
>
> As a first exercise, I try to compile ghc-4.08.1 from scratch.
> But I always run into trouble with the libgmp stuff.
> IMHO, my problems are caused by several factors:
>
> 1. We use Suse Linux 7.0 (that provides libgmp-3.0.x).
> 2. The ghc-4.08-1 distribution includes libgmp-2.x.x.
> 3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names
> are generated only if the header file is included.
> 4. The configure script does not recognize that libgmp is
> installed (because it does not include the header file.)
> 5. When linking, the linker cannot resolve symbols prefixed by mpz_
> (because the 2.x.x header file was used in compilation but the
> linker uses the shared library provided by Suse Linux.)
> 5. Even if informed about the local installation of libgmp
> (by manually
> changing config.cache), the 2.x.x header file will be used (again
> resulting in unresolved bindings when linking).
>
> The same problems occur when bootstrapping from .hc files.
>
> What to do? Should I hack the Makefiles? Should I replace the libgmp
> distribution included in the ghc distribution by some new 3.x.x
> distribution?
I'll try to clarify the situation, since it's a bit confusing.
- GHC tries to detect GMP 2 on the host system during the
configuration process. If it detects it, the build will
go on to use the installed version.
- If GMP 2 was *not* found, then we fall back to the copy of
GMP in the source tree, which is build statically.
- the RPMs have a dependency on the gmp2 packages.
- GMP 3 is only source compatible with GMP 2, as you discovered.
Furthermore, using the GMP 2 headers with the GMP 3 library
aint gonna work. (if your system is set up like this, then
it's broken, just like ours :-)
- GHC versions post-4.08.X use GMP 3.
So, I can't quite work out what went wrong in your case. If the build
didn't detect GMP 2, then it should have just used the one in the tree.
BTW, you can't use GMP 3 with ghc-4.08.1 (the native code generator at
least will break).
Hope this helps :)
Cheers,
Simon
From marte@pms.informatik.uni-muenchen.de Wed Nov 15 16:47:08 2000
Date: Wed, 15 Nov 2000 17:47:08 +0100 (CET)
From: Michael Marte marte@pms.informatik.uni-muenchen.de
Subject: Problems with libgmp
Hello Simon,
> So, I can't quite work out what went wrong in your case. If the build
> didn't detect GMP 2, then it should have just used the one in the tree.
Obviously, when linking, it did not use the one in the tree :-(
Conclusion: The Linux linker does not behave like other linkers or
there is a bug in some Makefile.
> BTW, you can't use GMP 3 with ghc-4.08.1 (the native code generator at
> least will break).
Ok, I'll to try to get a snapshot from the CVS repository.
Thanks,
Michael
From ger@Informatik.Uni-Bremen.DE Wed Nov 15 17:42:29 2000
Date: Wed, 15 Nov 2000 18:42:29 +0100
From: George Russell ger@Informatik.Uni-Bremen.DE
Subject: 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 . . .
From simonmar@microsoft.com Thu Nov 16 09:57:00 2000
Date: Thu, 16 Nov 2000 01:57:00 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: Problems with libgmp
> > > So, I can't quite work out what went wrong in your case.
> If the build
> > > didn't detect GMP 2, then it should have just used the
> one in the tree.
> >
> > Obviously, when linking, it did not use the one in the tree :-(
> > Conclusion: The Linux linker does not behave like other linkers or
> > there is a bug in some Makefile.
>
> Of late I have had problems with libgmp2 and woody-debian. I
> solved the
> problem the first time around by adding a sym link
> /usr/lib/libgmp2.so ->
> /usr/lib/libgmp.so.2.0.2
>
> Yesterday I solved the problem by installing libgmp2-dev
> because ld was
> looking for libgmp.a for some reason when trying to compile hdirect.
>
> Hacks at best. Haven't really looked for whys and wherefores.
The binary distributions of 4.08.2 will come with a statically linked
libgmp.a.
It's up to the package maintainers (RedHat RPM, Debian etc.) to decide
the best approach for those systems, i.e. whether it's better to depend
on the system-supplied shared libgmp or supply one in the GHC package.
On FreeBSD for example I just use the system-supplied one since it's
part of the base system.
Cheers,
Simon
From simonmar@microsoft.com Thu Nov 16 10:24:36 2000
Date: Thu, 16 Nov 2000 02:24:36 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: Instant readFile
George Russell writes:
> 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?
Well, you could always free the address directly after unpacking it,
since unpackCStringLenIO generates the whole string in one go.
> 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 . . .
The alternative is to use a ByteArray to store the string. These live
in the heap and so get garbage collected automatically, and should be
quicker to allocate than using malloc.
Check out the hGetBuf family of functions in IOExts, there are versions
for reading into/out of ByteArrays, and there are variants of
unpackCString that work with ByteArrays (unpackNBytesBA, for example).
[ side note: ByteArrays and MutableByteArrays will eventually be
replaced by UArray and STUArray/IOUArray which are functionally
identical but have a nice overloaded interface in IArray/MArray. ]
Cheers,
Simon
From hul@progsoc.uts.edu.au Thu Nov 16 03:05:13 2000
Date: Thu, 16 Nov 2000 14:05:13 +1100 (EST)
From: Rahul Bhargava hul@progsoc.uts.edu.au
Subject: Problems with libgmp
> > So, I can't quite work out what went wrong in your case. If the build
> > didn't detect GMP 2, then it should have just used the one in the tree.
>
> Obviously, when linking, it did not use the one in the tree :-(
> Conclusion: The Linux linker does not behave like other linkers or
> there is a bug in some Makefile.
Of late I have had problems with libgmp2 and woody-debian. I solved the
problem the first time around by adding a sym link /usr/lib/libgmp2.so ->
/usr/lib/libgmp.so.2.0.2
Yesterday I solved the problem by installing libgmp2-dev because ld was
looking for libgmp.a for some reason when trying to compile hdirect.
Hacks at best. Haven't really looked for whys and wherefores.
Rahul
From qrczak@knm.org.pl Wed Nov 15 22:10:19 2000
Date: 15 Nov 2000 22:10:19 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Instant readFile
Wed, 15 Nov 2000 18:42:29 +0100, George Russell <ger@Informatik.Uni-Bremen.DE> pisze:
> 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.
Applying
foldr (\_ t -> t) (return ())
to the string (and executing this application as an IO action) will
force it to be read completely. If it came from readFile, the file
gets closed as soon as the string is evaluated up to its end.
> 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 . . .
Unfortunately the design of these areas (conversion between Haskell
strings and C strings) is not yet complete. And Unicode in Haskell
strings (already implemented in GHC development versions) will make
the library more complex.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From bjpop@cs.mu.OZ.AU Sun Nov 19 07:34:21 2000
Date: Sun, 19 Nov 2000 18:34:21 +1100 (EST)
From: Bernard James POPE bjpop@cs.mu.OZ.AU
Subject: types from ghc (another question)
Hi again,
Simon Peyton-Jones writes:
> Don't try to get the type environment out. Instead, look at the
> syntax tree produced by the type checker. Each binder is an Id.
> There's a function
> idType :: Id -> Type
> that tells you the type of each binder. Quite how you present it
> to the user in a good way isn't clear to me,
Thanks Simon.
In TcModule.lhs I added some code like this:
myDumpTc results
= myPprMonoBinds $ tc_binds results
where
myPprMonoBinds (AndMonoBinds b1 b2)
= myPprMonoBinds b1 $$ myPprMonoBinds b2
myPprMonoBinds (FunMonoBind id _ matches _)
= (ppr (toRdrName id)) <+>
dcolon <+>
(ppr $ idType id) $$
myPprMatches matches
{- etc, etc ... -}
For the following contrived example:
main = putStr $ show (fred 1 3)
where
fred a b = let myid x = x in myid (plus a b)
plus x y = x + y
My output is:
main :: IO ()
plus :: a -> a -> a
fred :: a -> a -> a
myid :: t_aMv -> t_aMv
Which is nearly exactly what I want, however, the class constraints are missing
from the signatures for plus and fred. The universal quantification of
the type variable t_aMv is also missing.
One curiosity is that the compiler has generated the variable 'a' in
the two circumstances where the variables are constrained, which makes me think
something special is happening here.
If you defined all the binders at the top-level and supplied the
-ddump-types flag to ghc (with a modification to the code to turn off the
conversion to HsType, so that the unique variable names do not get clobbered)
you get the proper polymorphic type signatures
for each of the identifiers (ie myid :: forall t_aMv . t_aMv -> t_aMv).
My question is: can I find out any information about the constraints on
variables from the types that I find in the tc_binds component of the type
checking results?
(apologies for my being long-winded).
Regards,
Bernie.
From simonpj@microsoft.com Mon Nov 20 09:50:31 2000
Date: Mon, 20 Nov 2000 01:50:31 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: types from ghc (another question)
Bernie
All (I think) the top level bindings come out of the type check
as an AbsBinds. This is where we generalise from a monomorphic
thing to a polymorphic thing.
An AbsBinds has four components, the third of which is a list of
triples (TyVar, Id, Id). You want to grab the first of these Ids (only).
You can then ignore the MonoBinds inside the fourth component of
the AbsBinds. So your code will get quite a bit simpler.
The two Ids in the triple are the polymorphic top-level binder and
the monomorphic (perhaps recursive) thing that it generalises.
It's a bit hard to explain in a short space. Look at the output of the
desugarer for a simple defn, to see what an AbsBinds translates to.
Anyway these polymorphic Ids will have exactly the for-alls and
constraints that you want
hope this gets you moving
Simon
| -----Original Message-----
| From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU]
| Sent: 19 November 2000 07:34
| To: glasgow-haskell-users@haskell.org
| Cc: bjpop@cs.mu.OZ.AU
| Subject: types from ghc (another question)
|
|
| Hi again,
|
| Simon Peyton-Jones writes:
|
| > Don't try to get the type environment out. Instead, look at the
| > syntax tree produced by the type checker. Each binder is an Id.
| > There's a function
| > idType :: Id -> Type
| > that tells you the type of each binder. Quite how you present it
| > to the user in a good way isn't clear to me,
|
| Thanks Simon.
|
| In TcModule.lhs I added some code like this:
|
| myDumpTc results
| = myPprMonoBinds $ tc_binds results
| where
| myPprMonoBinds (AndMonoBinds b1 b2)
| = myPprMonoBinds b1 $$ myPprMonoBinds b2
|
| myPprMonoBinds (FunMonoBind id _ matches _)
| = (ppr (toRdrName id)) <+>
| dcolon <+>
| (ppr $ idType id) $$
| myPprMatches matches
|
| {- etc, etc ... -}
|
|
| For the following contrived example:
|
| main = putStr $ show (fred 1 3)
| where
| fred a b = let myid x = x in myid (plus a b)
| plus x y = x + y
|
| My output is:
|
| main :: IO ()
| plus :: a -> a -> a
| fred :: a -> a -> a
| myid :: t_aMv -> t_aMv
|
| Which is nearly exactly what I want, however, the class
| constraints are missing
| from the signatures for plus and fred. The universal
| quantification of
| the type variable t_aMv is also missing.
|
| One curiosity is that the compiler has generated the variable 'a' in
| the two circumstances where the variables are constrained,
| which makes me think
| something special is happening here.
|
| If you defined all the binders at the top-level and supplied the
| -ddump-types flag to ghc (with a modification to the code to
| turn off the
| conversion to HsType, so that the unique variable names do
| not get clobbered)
| you get the proper polymorphic type signatures
| for each of the identifiers (ie myid :: forall t_aMv . t_aMv
| -> t_aMv).
|
| My question is: can I find out any information about the
| constraints on
| variables from the types that I find in the tc_binds
| component of the type
| checking results?
|
| (apologies for my being long-winded).
|
| Regards,
| Bernie.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From bjpop@cs.mu.OZ.AU Tue Nov 21 06:42:47 2000
Date: Tue, 21 Nov 2000 17:42:47 +1100 (EST)
From: Bernard James POPE bjpop@cs.mu.OZ.AU
Subject: types from ghc - got them!
Hi again,
For my previous example:
main = putStr $ show (fred 1 3)
where
fred a b = let myid x = x in myid (plus a b)
plus x y = x + y
I can now get the following output:
==================== Bernie: All Binder TypeSigs ====================
main :: IO ()
plus :: forall a. (Num a) => a -> a -> a
fred :: forall a. (Num a) => a -> a -> a
myid :: forall t_aMv. t_aMv -> t_aMv
Which is exactly what I want. Turned out to be quite simple in the end.
Thanks a lot for all your help Simon.
Just out of curiosity, do you think that this sort of output would be
useful for other people? I don't know what your plans are for GHCi, but you
may be considering a mode that prints types out, something like :t in
hugs. I always found it frustrating in hugs that I couldn't get the types
of locally defined values. My students also find this frustrating, and it
sometimes causes them to avoid local definitions. Obviously there are issues
with type variables which are quantified outside the local definition, but
careful naming of things should be able to fix this.
Regards,
Bernie.
Simon Peyton-Jones writes:
> Bernie
>
> All (I think) the top level bindings come out of the type check
> as an AbsBinds. This is where we generalise from a monomorphic
> thing to a polymorphic thing.
>
> An AbsBinds has four components, the third of which is a list of
> triples (TyVar, Id, Id). You want to grab the first of these Ids (only).
> You can then ignore the MonoBinds inside the fourth component of
> the AbsBinds. So your code will get quite a bit simpler.
>
> The two Ids in the triple are the polymorphic top-level binder and
> the monomorphic (perhaps recursive) thing that it generalises.
> It's a bit hard to explain in a short space. Look at the output of the
> desugarer for a simple defn, to see what an AbsBinds translates to.
>
> Anyway these polymorphic Ids will have exactly the for-alls and
> constraints that you want
>
> hope this gets you moving
From simonpj@microsoft.com Tue Nov 21 13:48:42 2000
Date: Tue, 21 Nov 2000 05:48:42 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: types from ghc - got them!
Well done.
We're blazing away on GHCI (an interactive version of GHC)
at the moment, including
a user interface. When it's usable, perhaps you'd like to look
at it with a view to adding this feature?
Simon
| -----Original Message-----
| From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU]
| Sent: 21 November 2000 06:43
| To: glasgow-haskell-users@haskell.org
| Cc: bjpop@cs.mu.OZ.AU
| Subject: types from ghc - got them!
|
|
| Hi again,
|
| For my previous example:
|
| main = putStr $ show (fred 1 3)
| where
| fred a b = let myid x = x in myid (plus a b)
| plus x y = x + y
|
| I can now get the following output:
|
| ==================== Bernie: All Binder TypeSigs
| ====================
| main :: IO ()
| plus :: forall a. (Num a) => a -> a -> a
| fred :: forall a. (Num a) => a -> a -> a
| myid :: forall t_aMv. t_aMv -> t_aMv
|
| Which is exactly what I want. Turned out to be quite simple
| in the end.
|
| Thanks a lot for all your help Simon.
|
| Just out of curiosity, do you think that this sort of output would be
| useful for other people? I don't know what your plans are for
| GHCi, but you
| may be considering a mode that prints types out, something like :t in
| hugs. I always found it frustrating in hugs that I couldn't
| get the types
| of locally defined values. My students also find this
| frustrating, and it
| sometimes causes them to avoid local definitions. Obviously
| there are issues
| with type variables which are quantified outside the local
| definition, but
| careful naming of things should be able to fix this.
|
| Regards,
| Bernie.
|
|
| Simon Peyton-Jones writes:
|
| > Bernie
| >
| > All (I think) the top level bindings come out of the type check
| > as an AbsBinds. This is where we generalise from a monomorphic
| > thing to a polymorphic thing.
| >
| > An AbsBinds has four components, the third of which is a list of
| > triples (TyVar, Id, Id). You want to grab the first of
| these Ids (only).
| > You can then ignore the MonoBinds inside the fourth component of
| > the AbsBinds. So your code will get quite a bit simpler.
| >
| > The two Ids in the triple are the polymorphic top-level binder and
| > the monomorphic (perhaps recursive) thing that it generalises.
| > It's a bit hard to explain in a short space. Look at the
| output of the
| > desugarer for a simple defn, to see what an AbsBinds translates to.
| >
| > Anyway these polymorphic Ids will have exactly the for-alls and
| > constraints that you want
| >
| > hope this gets you moving
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simona@I2.Informatik.RWTH-Aachen.DE Tue Nov 21 15:31:50 2000
Date: Tue, 21 Nov 2000 16:31:50 +0100 (CET)
From: Axel Simon simona@I2.Informatik.RWTH-Aachen.DE
Subject: types from ghc - got them!
On Tue, 21 Nov 2000, Bernard James POPE wrote:
> Obviously there are issues
> with type variables which are quantified outside the local definition, but
> careful naming of things should be able to fix this.
Hi,
For my master thesis I wrote a tool called Typeview (presented at IFL'00)
that can display the types of arbitrary expressions (even in programs that
are not typecorrect). We chose to append an underscore to every type
variable that is not quantified at the examined expression:
f :: a -> (a, Int)
f x = let g y = (x,y) in g 3
In this program the type of the local expression is g:: b -> (_a,b). This
approach could be used for local type annotations (and thereby replacing
the pattern annotations), the :t command and error messages. Of course
you have to make sure that _a is not ambiguous.
Cheers,
Axel.
From phoenix@esther.donga.ac.kr Sat Nov 25 12:03:21 2000
Date: Sat, 25 Nov 2000 21:03:21 +0900
From: Wooseok Yang phoenix@esther.donga.ac.kr
Subject: unsubscribe glasgow-haskell-users
dW5zdWJzY3JpYmUgZ2xhc2dvdy1oYXNrZWxsLXVzZXJzDQo=
From rrt1001@cam.ac.uk Mon Nov 27 10:45:23 2000
Date: Mon, 27 Nov 2000 10:45:23 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: New InstallShield: no more DLLs
I've put up a new InstallShield for GHC 4.08.1 (Windows edition). This no
longer contains DLLs and import libraries for the libraries, so you have to
use the compiler with -static.
I intend to stick to this scheme in future releases (probably replacing
-static with -dynamic), as GHC derives few benefits from DLLized libraries,
and a lot of disadvantages. Also, there is at present an unresolved and
deep-seated bug (possibly not even in GHC) that prevents some very simple
DLLized programs from working.
Users of DLLs need not despair: one important (and, to the best of my
knowledge, fully working) version of DLL building remains: you can still
build static DLLs, that is, DLLs in which all the code has been compiled
statically, so that all the necessary library code is linked into the DLL.
Hence, you can still build DLLs to be called from other languages, or to be
wrapped up as COM components, or whatever.
Finally, one nice side effect is that the size of the distribution is nearly
halved: it now weighs in at a little over 12Mb.
--
http://sc3d.org/rrt/ | violence, n. bravery for cowards
From christian@lescher.de Mon Nov 27 18:37:23 2000
Date: Mon, 27 Nov 2000 19:37:23 +0100
From: Christian Lescher christian@lescher.de
Subject: New InstallShield: no more DLLs
> I've put up a new InstallShield for GHC 4.08.1 (Windows edition). This no
> longer contains DLLs and import libraries for the libraries, so you have to
> use the compiler with -static.
Hmm ... That's really a fundamental change in GHC's Windows edition.
> I intend to stick to this scheme in future releases (probably replacing
> -static with -dynamic
Good idea! :-) I also regard statically linking as more common than dynamically
linking, so I welcome your idea to make statically linking the default.
> ), as GHC derives few benefits from DLLized libraries,
> and a lot of disadvantages. Also, there is at present an unresolved and
> deep-seated bug (possibly not even in GHC) that prevents some very simple
> DLLized programs from working.
When may Win users expect this bug to be fixed? (A difficult question, I know.)
Although I regard statically linking as much more important than the DLLized
alternative, dynamically linking is (was?) an important feature of GHC for Win -
f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC.
> Users of DLLs need not despair: one important (and, to the best of my
> knowledge, fully working) version of DLL building remains: you can still
> build static DLLs, that is, DLLs in which all the code has been compiled
> statically, so that all the necessary library code is linked into the DLL.
> Hence, you can still build DLLs to be called from other languages, or to be
> wrapped up as COM components, or whatever.
Exposing Haskell functions to other languages in DLLs is a very, very important
feature of GHC's Win edition! Please go on supporting it as you do!!
> Finally, one nice side effect is that the size of the distribution is nearly
> halved: it now weighs in at a little over 12Mb.
Cheers, Christian
From plop@redbrick.dcu.ie Tue Nov 28 11:15:14 2000
Date: Tue, 28 Nov 2000 11:15:14 +0000
From: Smelly Pooh plop@redbrick.dcu.ie
Subject: Exception Handling
I'm writing an application at the moment (in Haskell duh) and the issue of
exception handling has come up. I don't want to use Maybe (because that would
destructure the code somewhat) or any kind of Monad and I've settled on the
idea of SPJs Exception extension. The idea is to create a data type with a
different constructor per exception as in
data MyException = Ex1 | Ex2 | Ex3
then use throwDyn/catchDyn to throw and catch it. Unfortunately this requires
MyException to be an instance of class Typeable, and the documentation on that
is quite sparse. Any advice or pointers would be greatly appreciated
From stolz@I2.Informatik.RWTH-Aachen.DE Tue Nov 28 11:28:50 2000
Date: Tue, 28 Nov 2000 12:28:50 +0100
From: Volker Stolz stolz@I2.Informatik.RWTH-Aachen.DE
Subject: Exception Handling
On Tue, Nov 28, 2000 at 11:15:14AM +0000, Smelly Pooh wrote:
> I'm writing an application at the moment (in Haskell duh) and the issue of
> exception handling has come up. I don't want to use Maybe (because that would
> destructure the code somewhat) or any kind of Monad and I've settled on the
> idea of SPJs Exception extension. The idea is to create a data type with a
> different constructor per exception as in
>
> data MyException = Ex1 | Ex2 | Ex3
>
> then use throwDyn/catchDyn to throw and catch it. Unfortunately this requires
> MyException to be an instance of class Typeable, and the documentation on that
> is quite sparse. Any advice or pointers would be greatly appreciated
\begin{code}
data DMsg = DOne | DTwo Int | DThree String | DQuit
instance Typeable DMsg where
typeOf _ = mkAppTy msgTc []
msgTc :: TyCon
msgTc = mkTyCon "Msg"
-- To Dynamic:
let dyn = toDyn msg
-- and back:
let msg = fromDynamic dyn
case msg of
Just _ -> ...
Nothing -> error (..)
\end{code}
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From rrt1001@cam.ac.uk Tue Nov 28 12:48:46 2000
Date: Tue, 28 Nov 2000 12:48:46 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: New InstallShield: no more DLLs
> > Also, there is at present an unresolved and
> > deep-seated bug (possibly not even in GHC) that prevents some very simple
> > DLLized programs from working.
>
> When may Win users expect this bug to be fixed? (A difficult question, I know.)
I've given up on it for the moment; having looked at the source code of ld,
asked on the binutils and Cygwin mailing lists, and a few other things, I
can't work out what the problem is. I do have a few more things to try, but
I don't hold out much hope of fixing it soon without help.
> Although I regard statically linking as much more important than the DLLized
> alternative, dynamically linking is (was?) an important feature of GHC for Win -
> f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC.
This is only a good idea if you really are distributing several DLLs or EXEs
built with GHC (so that you do get space savings), and even then you have to
ask yourself if it's worth the risk of DLL Hell (which I have suffered from
several times). Disk space is so cheap now that you really have to be hurt
somewhere (e.g. increased download times, decreased performance because of
large unshared binaries) before it's worth dynamic linking (except to
relatively stable system libraries).
--
http://sc3d.org/rrt/ | computation, n. automated pedantry
From christian@lescher.de Tue Nov 28 18:47:00 2000
Date: Tue, 28 Nov 2000 19:47:00 +0100
From: Christian Lescher christian@lescher.de
Subject: New InstallShield: no more DLLs
> > > Also, there is at present an unresolved and
> > > deep-seated bug (possibly not even in GHC) that prevents some very simple
> > > DLLized programs from working.
> >
> > When may Win users expect this bug to be fixed? (A difficult question, I know.)
>
> I've given up on it for the moment; having looked at the source code of ld,
> asked on the binutils and Cygwin mailing lists, and a few other things, I
> can't work out what the problem is. I do have a few more things to try, but
> I don't hold out much hope of fixing it soon without help.
I'd like to offer help, but I'm afraid I don't know enough about the 'interna' of GHC
and cygwin :-( [Would be nice, if I could learn more about it in the future!]
Besides, I've got some (not so fortunate) news: even after updating binutils and the
whole cygwin to the latest version, the problem with *statically* linked and
afterwards stripped DLLs build with GHC remains - the unstripped version works well,
but the stripped one crashes in some constellations. I will try to make this error
reproducable and let you know about it. Something is still wrong here - probably with
cygwin. Maybe this has also got something to do with the dyn. linking problem?
> > Although I regard statically linking as much more important than the DLLized
> > alternative, dynamically linking is (was?) an important feature of GHC for Win -
> > f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC.
>
> This is only a good idea if you really are distributing several DLLs or EXEs
> built with GHC (so that you do get space savings), and even then you have to
> ask yourself if it's worth the risk of DLL Hell (which I have suffered from
> several times). Disk space is so cheap now that you really have to be hurt
> somewhere (e.g. increased download times, decreased performance because of
> large unshared binaries) before it's worth dynamic linking (except to
> relatively stable system libraries).
Yes, that's true. However, dynamically linking would be a feature.
Cheers, Christian
From abf@cs.ucc.ie Thu Nov 30 14:21:00 2000
Date: Thu, 30 Nov 2000 14:21:00 GMT
From: Alex Ferguson abf@cs.ucc.ie
Subject: ghc-4.xx Alpha port?
Hi guys. Has anyone been so rash as to try this? Any indications
as to the likely "degree of difficulty"? I'd have a go myself, but
I'm rather busy with teaching. (Which is ironic, since teaching is
what I want it for...)
Cheers,
Alex.
From simonmar@microsoft.com Thu Nov 30 15:40:58 2000
Date: Thu, 30 Nov 2000 07:40:58 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: ghc-4.xx Alpha port?
> Hi guys. Has anyone been so rash as to try this? Any indications
> as to the likely "degree of difficulty"? I'd have a go myself, but
> I'm rather busy with teaching. (Which is ironic, since teaching is
> what I want it for...)
Degree of difficulty is likely to be less than a starting completely
non-existent port (eg. IA64), but still significant. The 64-bitness is
likely to be more of an issue than the Alpha-specific stuff, though.
If there's sufficient demand for a port I'll help out; I did have an
account on the Compaq testdrive machines at one point (they have
Alpha/Linux and Alpha/*BSD machines) which has probably expired now, but
it's a good place to get some free Alpha cycles.
Cheers,
Simon
From v-julsew@microsoft.com Thu Nov 30 16:14:46 2000
Date: Thu, 30 Nov 2000 08:14:46 -0800
From: Julian Seward (Intl Vendor) v-julsew@microsoft.com
Subject: ghc-4.xx Alpha port?
| > Hi guys. Has anyone been so rash as to try this? Any indications
| > as to the likely "degree of difficulty"? I'd have a go myself, but
| > I'm rather busy with teaching. (Which is ironic, since teaching is
| > what I want it for...)
|
| Degree of difficulty is likely to be less than a starting completely
| non-existent port (eg. IA64), but still significant. The
| 64-bitness is
| likely to be more of an issue than the Alpha-specific stuff, though.
Getting it working on Alphas would also be of benefit in the sense
that it gets the 64-bitness working again. That gives one less thing
to worry about when porting to IA64, if/when that should happen.
J
From Malcolm.Wallace@cs.york.ac.uk Thu Nov 30 17:18:42 2000
Date: Thu, 30 Nov 2000 17:18:42 +0000
From: Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Subject: file suffixes
I recall that at one point GHC came with "bundles", built in "ways",
like profiling, parallel, tickyticky, etc.. There was also some
filename-mangling scheme for distinguishing .hi interface and .o
object files from the different bundles.
My question is, what was that filename-mangling scheme? I ask because
I'm about to do something similar for nhc98's "ways" (heap-profiling,
time-profiling, tracing, etc.), and some consistency here might
be useful.
Regards,
Malcolm
From rrt1001@cam.ac.uk Thu Nov 30 17:42:05 2000
Date: Thu, 30 Nov 2000 17:42:05 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: file suffixes
> I recall that at one point GHC came with "bundles", built in "ways",
> like profiling, parallel, tickyticky, etc.. There was also some
> filename-mangling scheme for distinguishing .hi interface and .o
> object files from the different bundles.
>
> My question is, what was that filename-mangling scheme? I ask because
> I'm about to do something similar for nhc98's "ways" (heap-profiling,
> time-profiling, tracing, etc.), and some consistency here might
> be useful.
We change extensions such as .ext to .way_ext. This works for most things
except libraries, which get changed from .a to _way.a.
--
http://sc3d.org/rrt/ | certain, a. insufficiently analysed
From simonpj@microsoft.com Wed Nov 1 10:34:37 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 1 Nov 2000 02:34:37 -0800
Subject: ppr for Haskell Abstract Syntax
Message-ID: <74096918BE6FD94B9068105F877C002D355ACE@red-pt-02.redmond.corp.microsoft.com>
GHC has a pretty printer for Haskell. It's in ghc/compiler/hsSyn/*.lhs,
along with the (numerous) data type declarations that define the
full Haskell syntax. It would take a little work to rip it out
of GHC, mind you
Simon
| -----Original Message-----
| From: Kate S. Golder [mailto:kgolder@wellesley.edu]
| Sent: 31 October 2000 21:07
| To: glasgow-haskell-users@haskell.org
| Subject: ppr for Haskell Abstract Syntax
|
|
| Hi -
| I was wondering if anyone knows if there is a pretty printer
| for Haskell
| Abstract Syntax anywhere? I've been asking around, but
| haven't located
| one yet. If you know of one that I could use, it would be
| really helpful!
| Thanks in advance,
| *Kate
|
| **********************
| Kate S. Golder
| Wellesley College
| Class of 2002
|
| Freeman Hall
| Wellesley College
| Wellesley, Ma 02481
|
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simonmar@microsoft.com Wed Nov 1 12:16:50 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 1 Nov 2000 04:16:50 -0800
Subject: ppr for Haskell Abstract Syntax
Message-ID: <9584A4A864BD8548932F2F88EB30D1C610CE53@TVP-MSG-01.europe.corp.microsoft.com>
> Hi -
> I was wondering if anyone knows if there is a pretty printer
> for Haskell
> Abstract Syntax anywhere? I've been asking around, but
> haven't located
> one yet. If you know of one that I could use, it would be
> really helpful!
> Thanks in advance,
> *Kate
We have one in GHC's CVS source tree now. hslibs/hssource contains a
Haskell abstract syntax, parser, and a pretty printer. It should compile on
pretty much any version of GHC, but you'll probably need a recent version of
Happy (1.8) for the parser.
Cheers,
Simon
From chak@cse.unsw.edu.au Thu Nov 2 08:08:25 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 02 Nov 2000 19:08:25 +1100
Subject: Quick question re RULES
Message-ID: <20001102190825G.chak@cse.unsw.edu.au>
PrelBase contains the appended code. Am I correct in
assuming that the stuff is structured as it is, because the
"map" rule first `breaks' the map `open', which exposes it
to the various foldr/build rules, and if no foldr/build rule
matches, the "mapList" rule `closes' it again in a later
phase of optimisation - after build was inlined? If so, it
seems like the whole thing depends a bit on the timing of
the various optimsations (the map might be closed again
before any of the foldr/build rules fires). Is this maybe
the reason that build has an INLINE 2 pragma, which delays
its inlining, and thus, the closing of the map?
All very cunning, it seems ;-)
Cheers,
Manuel
-=-
map :: (a -> b) -> [a] -> [b]
map = mapList
-- Note eta expanded
mapFB :: (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst
mapFB c f x ys = c (f x) ys
mapList :: (a -> b) -> [a] -> [b]
mapList _ [] = []
mapList f (x:xs) = f x : mapList f xs
{-# RULES
"map" forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs)
"mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f.g)
"mapList" forall f. foldr (mapFB (:) f) [] = mapList f
#-}
From simonpj@microsoft.com Thu Nov 2 08:18:45 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 2 Nov 2000 00:18:45 -0800
Subject: Quick question re RULES
Message-ID: <74096918BE6FD94B9068105F877C002D355AD9@red-pt-02.redmond.corp.microsoft.com>
| PrelBase contains the appended code. Am I correct in
| assuming that the stuff is structured as it is, because the
| "map" rule first `breaks' the map `open', which exposes it
| to the various foldr/build rules, and if no foldr/build rule
| matches, the "mapList" rule `closes' it again in a later
| phase of optimisation - after build was inlined? If so, it
| seems like the whole thing depends a bit on the timing of
| the various optimsations (the map might be closed again
| before any of the foldr/build rules fires). Is this maybe
| the reason that build has an INLINE 2 pragma, which delays
| its inlining, and thus, the closing of the map?
That's exactly it.
| All very cunning, it seems ;-)
A bit too cunning for comfort. I wish I could think of a better
way to expose map's impl using build without paying a price
for doing so if it turns out not to fuse with anything. But so
far I've failed to do so.
Is this a propos of your new transformations for parallelism?
Simon
From chak@cse.unsw.edu.au Thu Nov 2 10:27:32 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 02 Nov 2000 21:27:32 +1100
Subject: Fun with GHC's optimiser
Message-ID: <20001102212732K.chak@cse.unsw.edu.au>
----Next_Part(Thu_Nov__2_21:27:30_2000_507)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Questions over questions arise in my quest to understand
GHC's code generator. In this nice little piece of STG
$w$snewPArray =
NO_CCS[] \r[ww w]
case newIntArray# [ww realWorld#] of wild {
(#,#) s2# mba# ->
case -# [ww 1] of y {
DEFAULT ->
let { wild1 = NO_CCS I#! [ww];
} in
case ># [0 y] of wild2 {
True -> PArray [wild1 mba#];
False ->
let {
$wgo2 =
NO_CCS[] \r[y1 y2]
let { a = NO_CCS PArray! [wild1 mba#];
} in
case w of wild3 {
I# e# ->
case writeIntArray# [mba# y1 e# y2] of s2#1 {
DEFAULT ->
case ==# [y1 y] of wild11 {
True -> (#,#) [s2#1 a];
False ->
case +# [y1 1] of stg_c2aL {
DEFAULT -> $wgo2 stg_c2aL s2#1
};
}
};
};
} in case $wgo2 0 s2# of wild3 { (#,#) ds r -> r; };
}
};
};
I am wondering whether there is a particular reason why the
optimiser doesn't pull the
(1) a = NO_CCS PArray! [wild1 mba#];
and the
(2) case w of wild3 {
I# e# ->
out off the $wgo2 loop - or at least push (1) down into the
True branch of `case ==# [y1 y] of'. I would say that (1)
in this form pointlessly allocates heap like mad, but is
only using one of the many copies of `a', namely the one
allocated in the final iteration and returned to the caller.
As for (2), the loop would be nice and straight if that
unboxing where outside of the loop - as it is, we break the
pipeline once per iteration it seems (if the branch
prediction isn't very clever).
Or do I misunderstand something here, or is there maybe some
magic after STG that gets rid of the stuff?
I attach the Haskell source, which I compiled with
ghc -O -c PArrays.hs -fglasgow-exts -ddump-stg
(This is 4.08.1 of course.)
Also if somebody is looking at the attached source, I was
wondering why, when I use the commented out code in
`newPArray', I get a lot worse code (the STG code is in a
comment at the end of the file). In particular, the lambda
abstraction is not inlined, whereas `fill' gets inlined into
the code of which the dump is above. Is it because the
compiler has a lot harder time with explicit recursion than
with fold/build? If so, the right RULES magic should allow
me to do the same for my own recursively defined
combinators, shouldn't it?
Cheers,
Manuel
PS: Otherwise, it is quite impressive what the RULES and
inliner do to the foldr that produced the above code.
----Next_Part(Thu_Nov__2_21:27:30_2000_507)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="PArrays.hs"
-- Parallel Arrays: Sequential prototype
--
-- Authors: Manuel M. T. Chakravarty
-- Gabriele Keller
-- Created: 26 October 2000
--
-- Version $Revision$ from $Date$
--
-- Copyright (c) 2000 Chakravarty & Keller
--
-- This file is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This file is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
--- DESCRIPTION ---------------------------------------------------------------
--
-- This module provides unboxed arrays of primitive types as a sequential
-- prototype for the parallel arrays of Gabi's SCL. They come with all the
-- necessary operations to support flattened Haskell generated from lambdaPA.
--
--- DOCU ----------------------------------------------------------------------
--
-- language: Haskell 98 + GHC extensions (unboxed types and byte arrays)
--
-- We export the immutable `PArray' only; however, we internally also use a
-- mutable variant `MPArray', which allows us an efficient incremental
-- definition of the collective structure.
--
-- The class `PAE' is quite peculiar. It essentially serves to overload
-- array access (which depends on the size of the unboxed value stored in the
-- parallel array); however, the actual operations in the class are only to
-- be used internally in this module - and therefore, the class `PAE' is
-- exported *abstractly*. In fact, most operations work on mutable parallel
-- arrays for efficiency.
--
-- We shamelessly steal coding tricks from GHC's `ArrayBase', `IArray' &
-- friends, but without most of that overloading mess.
--
--- TODO ----------------------------------------------------------------------
--
module PArrays (
PAE, PArray, newPArray, (!|), loop, gen
) where
-- infixl 9 !|
import PrelGHC
import PrelBase
import PrelST
import ST
-- data structures
-- ---------------
-- * although all `PArray's are represented by the same structure, the
-- functions operating on them differ with the element type; hence, we have
-- to overload these functions
-- integer indexed array (EXPORTED ABSTRACTLY)
--
data PArray e = PArray Int ByteArray#
-- mutable integer indexed array
--
data MPArray s e = MPArray Int (MutableByteArray# s)
-- the class of "Parallel Array Element"s (EXPORTED ABSTRACTLY)
--
class PAE a where
newMPArray :: Int -> ST s (MPArray s a)
readMPArray :: MPArray s a -> Int -> ST s a
writeMPArray :: MPArray s a -> Int -> a -> ST s ()
indexPArray :: PArray a -> Int -> a
-- exported functions
-- ------------------
-- create new parallel array, where all elements are initialised to the given
-- values (EXPORTED)
--
newPArray :: PAE e => Int -> e -> PArray e
newPArray n e = runST (do
mpa <- newMPArray n
-- simpleGen n $
-- \i -> writeMPArray mpa i e
-- return $ unsafeFreezeMPArray mpa)
foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1]) -- a la ArrayBase
{-# SPECIALIZE newPArray :: Int -> Int -> PArray Int #-}
fill mpa e i next = writeMPArray mpa i e >> next
-- indexing of a parallel array (EXPORTED)
--
(!|) :: PAE e => PArray e -> Int -> e
(!|) = indexPArray
-- Gabi's loop (EXPORTED)
--
loop :: () -- ??
loop = error "loop?"
-- Gabi's gen (EXPORTED)
--
gen :: () -- ??
gen = error "gen??"
-- instances of `PAE'
-- ------------------
instance PAE Int where
newMPArray = newMPArrayInt
readMPArray = readMPArrayInt
writeMPArray = writeMPArrayInt
indexPArray = indexPArrayInt
newMPArrayInt :: Int -> ST s (MPArray s Int)
newMPArrayInt n@(I# n#) = ST $ \s# ->
case (newIntArray# n# s#) of {(# s2#, mba# #) ->
(# s2#, MPArray n mba# #)}
readMPArrayInt :: MPArray s Int -> Int -> ST s Int
{-# INLINE readMPArrayInt #-}
readMPArrayInt (MPArray _ mba#) (I# i#) = ST $ \s# ->
case readIntArray# mba# i# s# of {(# s2#, r# #) ->
(# s2#, I# r# #)}
writeMPArrayInt :: MPArray s Int -> Int -> Int -> ST s ()
{-# INLINE writeMPArrayInt #-}
writeMPArrayInt (MPArray _ mba#) (I# i#) (I# e#) = ST $ \s# ->
case writeIntArray# mba# i# e# s# of {s2# ->
(# s2#, () #)}
indexPArrayInt :: PArray Int -> Int -> Int
{-# INLINE indexPArrayInt #-}
indexPArrayInt (PArray _ ba#) (I# i#) =
case indexIntArray# ba# i# of {r# ->
(I# r#)}
-- auxilliary functions
-- --------------------
-- unsafely convert a mutable into an immutable array
--
unsafeFreezeMPArray :: MPArray s e -> PArray e
unsafeFreezeMPArray (MPArray n mba#) = PArray n (unsafeCoerce# mba#)
-- simple generator abstraction
--
simpleGen :: Monad m => Int -> (Int -> m ()) -> m ()
simpleGen 0 p = return ()
simpleGen n p = p (n - 1) >> simpleGen (n - 1) p
{-
-- That's what we get for a newPArray specialised for Int and using the
-- explicitly recursive simpleGen.
$wsimpleGen =
NO_CCS srt: (0,2)[] \r[ww w]
case ww of ds {
0 -> $wlvl1;
DEFAULT ->
let {
stg_c1Qg =
NO_CCS srt: (0,1)[] \r[s1]
case -# [ds 1] of a {
DEFAULT ->
let { stg_c1Lg = NO_CCS I#! [a];
} in
case w stg_c1Lg s1 of wild {
(#,#) new_s r -> $wsimpleGen a w new_s;
}
};
} in stg_c1Qg
};
SRT: [$wsimpleGen, $wlvl1]
$w$snewPArray =
NO_CCS srt: (0,1)[] \r[ww w]
case newIntArray# [ww realWorld#] of wild {
(#,#) s2# mba# ->
let {
stg_c1M1 =
NO_CCS[] \r[i]
case i of wild1 {
I# i# ->
case w of wild2 {
I# e# ->
let {
stg_c1Q7 =
NO_CCS[] \r[s#]
case writeIntArray# [mba# i# e# s#] of s2#1 {
DEFAULT -> (#,#) [s2#1 ()]
};
} in stg_c1Q7;
};
};
} in
case $wsimpleGen ww stg_c1M1 s2# of wild1 {
(#,#) new_s r -> let { a = NO_CCS I#! [ww]; } in (#,#) [a mba#];
};
};
SRT: [$wsimpleGen]
-- the `case w of' could be pulled out of the loop
-- stg_c1Q7 builds a superfluous closure (which is immediately entered)
-- could we somehow get a specialised version of simpleGen?
-}
----Next_Part(Thu_Nov__2_21:27:30_2000_507)----
From simonmar@microsoft.com Thu Nov 2 12:18:51 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 2 Nov 2000 04:18:51 -0800
Subject: Fun with GHC's optimiser
Message-ID: <9584A4A864BD8548932F2F88EB30D1C610CE5B@TVP-MSG-01.europe.corp.microsoft.com>
> I am wondering whether there is a particular reason why the
> optimiser doesn't pull the
>
> (1) a = NO_CCS PArray! [wild1 mba#];
>
> and the
>
> (2) case w of wild3 {
> I# e# ->
I checked with the before-ghci-branch compiler, and it pulls out (1) but not
(2). Simon did a fair amount of work on improving the compilation of IO-ish
code and code with lots of newtypes in it after we noticed some problems
like the ones you point out above. We'll need to investigate whether the
case can be pulled out of the loop too, though.
Cheers,
Simon
From simonpj@microsoft.com Thu Nov 2 12:46:41 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 2 Nov 2000 04:46:41 -0800
Subject: Fun with GHC's optimiser
Message-ID: <74096918BE6FD94B9068105F877C002D355ED9@red-pt-02.redmond.corp.microsoft.com>
I can never resist messages like these, even when I'm meant
to be doing other things. It's very helpful when people offer
fairly precise performance-bug reports. Thanks!
| I am wondering whether there is a particular reason why the
| optimiser doesn't pull the
|
| (1) a = NO_CCS PArray! [wild1 mba#];
This one is a definite bug. It turns out that the head of the
before-ghci-branch doesn't have this bug, so I'm disinclined
to investigate it further.
| (2) case w of wild3 {
| I# e# ->
|
| As for (2), the loop would be nice and straight if that
| unboxing where outside of the loop - as it is, we break the
| pipeline once per iteration it seems
This one is a bit harder. Basically we want to make a wrapper
for a recursive function if it's sure to evaluate its free variables.
In fact the 'liberate-case' pass (which isn't switched on in 4.08)
is meant to do just this. It's in simplCore/LiberateCase.lhs,
and it's not very complicated. I've just tried it and it doesn't seem
to have the desired effect, but I'm sure that's for a boring reason.
If anyone would like to fix it, go ahead!
(You can't just say '-fliberate-case' on the command line to make
it go; you have to add -fliberate-case at a sensible point to the
minusOflags in driver/Main.hs.)
Incidentally, you'll find that -ddump-simpl gives you a dump that
is pretty close to STG and usually much more readable. Most
performance bugs show up there. -dverbose-simpl gives you more
clues about what is happening where.
| Also if somebody is looking at the attached source, I was
| wondering why, when I use the commented out code in
| `newPArray', I get a lot worse code (the STG code is in a
| comment at the end of the file). In particular, the lambda
| abstraction is not inlined, whereas `fill' gets inlined into
| the code of which the dump is above. Is it because the
| compiler has a lot harder time with explicit recursion than
| with fold/build? If so, the right RULES magic should allow
| me to do the same for my own recursively defined
| combinators, shouldn't it?
I couldn't figure out exactly what you meant. The only commented
out code is STG code. Maybe send a module with the actual
source you are bothered about.
S
From chak@cse.unsw.edu.au Thu Nov 2 12:15:02 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 02 Nov 2000 23:15:02 +1100
Subject: Quick question re RULES
In-Reply-To: <74096918BE6FD94B9068105F877C002D355AD9@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D355AD9@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20001102231502Q.chak@cse.unsw.edu.au>
Simon Peyton-Jones wrote,
> Is this a propos of your new transformations for parallelism?
Precisely! Trying to figure out how to generate the fastest
possible array code with GHC.
Manuel
From lizard@Xterminator.STUDFB.UniBw-Muenchen.de Thu Nov 2 13:39:22 2000
From: lizard@Xterminator.STUDFB.UniBw-Muenchen.de (Oliver Braun)
Date: Thu, 2 Nov 2000 14:39:22 +0100
Subject: fatal error: heapCensus
Message-ID: <20001102143922.A1000@Mail.StudFb.UniBw-Muenchen.De>
Dear GHC-Users,
I am currently developing part of the EdComb library
(http://ist.unibw-muenchen.de/EdComb/).
I have compiled all files with the -prof and the -auto-all flag.
When starting the program
* without any RTS options -> everything is OK
* with +RTS -p -> everything is OK
* with +RTS -h -> fatal error: heapCensus
I am using GHC version 4.08.1 on a Debian/GNU Linux Box,
installed with the newest Debian packages from
http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian.
Olli
--
Federal Armed Forces University Munich Tel. 089 - 60190686
Werner-Heisenberg-Weg 102/128 Fax. 089 - 244333158
85577 Neubiberg mobil 0170 - 9317618
From chak@cse.unsw.edu.au Thu Nov 2 13:54:25 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 03 Nov 2000 00:54:25 +1100
Subject: Fun with GHC's optimiser
In-Reply-To: <74096918BE6FD94B9068105F877C002D355ED9@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D355ED9@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20001103005425N.chak@cse.unsw.edu.au>
----Next_Part(Fri_Nov__3_00:54:22_2000_559)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Simon Peyton-Jones wrote,
> I can never resist messages like these, even when I'm meant
> to be doing other things.
That's good to know ;-)
> It's very helpful when people offer
> fairly precise performance-bug reports. Thanks!
Thanks for the prompt reply! To SimonM, too.
> | I am wondering whether there is a particular reason why the
> | optimiser doesn't pull the
> |
> | (1) a = NO_CCS PArray! [wild1 mba#];
>
> This one is a definite bug. It turns out that the head of the
> before-ghci-branch doesn't have this bug, so I'm disinclined
> to investigate it further.
No problem, I can always build a new ghc from CVS.
> | (2) case w of wild3 {
> | I# e# ->
> |
> | As for (2), the loop would be nice and straight if that
> | unboxing where outside of the loop - as it is, we break the
> | pipeline once per iteration it seems
>
> This one is a bit harder. Basically we want to make a wrapper
> for a recursive function if it's sure to evaluate its free variables.
>
> In fact the 'liberate-case' pass (which isn't switched on in 4.08)
> is meant to do just this. It's in simplCore/LiberateCase.lhs,
> and it's not very complicated. I've just tried it and it doesn't seem
> to have the desired effect, but I'm sure that's for a boring reason.
> If anyone would like to fix it, go ahead!
Ok - something for a rainy weekend, I guess...
> Incidentally, you'll find that -ddump-simpl gives you a dump that
> is pretty close to STG and usually much more readable. Most
> performance bugs show up there. -dverbose-simpl gives you more
> clues about what is happening where.
Good to know. I just wasn't sure whether I wouldn't miss
out on some optimisations.
> | Also if somebody is looking at the attached source, I was
> | wondering why, when I use the commented out code in
> | `newPArray', I get a lot worse code (the STG code is in a
> | comment at the end of the file). In particular, the lambda
> | abstraction is not inlined, whereas `fill' gets inlined into
> | the code of which the dump is above. Is it because the
> | compiler has a lot harder time with explicit recursion than
> | with fold/build? If so, the right RULES magic should allow
> | me to do the same for my own recursively defined
> | combinators, shouldn't it?
>
> I couldn't figure out exactly what you meant. The only commented
> out code is STG code. Maybe send a module with the actual
> source you are bothered about.
Appended the version of the module where the code is
activated (it was commented out with --) - you'll find the
problematic code by searching for (**) in the code. It
generates
$w$snewPArray
= \ ww :: Int# w :: Int ->
case newIntArray# @ RealWorld ww realWorld#
of wild { (# s2#, mba# #) ->
case $wsimpleGen
ww
(\ i :: Int ->
case i of wild1 { I# i# ->
case w of wild2 { I# e# ->
__coerce (ST RealWorld ())
(\ s# :: (State# RealWorld) ->
case writeIntArray# @ RealWorld mba# i# e# s#
of s2#1 { __DEFAULT ->
(# s2#1, () #)
})
}
})
s2#
of wild1 { (# new_s, r #) ->
let {
a :: Int
a = $wI# ww
} in (# a, (__coerce ByteArray# mba#) #)
}
}
One thing that is not nice is in the lambda abstraction
based to $wsimpleGen. There is one lambda, then two
unboxing operations and another lambda for the state
variables s#. These two nested lambda's become in STG
stg_c1Op =
NO_CCS[] \r[i]
case i of wild1 {
I# i# ->
case w of wild2 {
I# e# ->
let {
stg_c1Sv =
NO_CCS[] \r[s#]
case writeIntArray# [mba# i# e# s#] of s2#1 {
DEFAULT -> (#,#) [s2#1 ()]
};
} in stg_c1Sv;
};
};
So, stg_c1Sv is allocated and immediately entered. I would
have hoped that the two lambda abstractions are merged into
something like this:
(\ i :: Int s# :: (State# RealWorld) ->
case i of wild1 { I# i# ->
case w of wild2 { I# e# ->
case writeIntArray# @ RealWorld mba# i# e# s#
of s2#1 { __DEFAULT -> (# s2#1, () #)
})
}
})
Maybe it is the __coerce, which prevents this from
happening?
Also, I am wondering why in the case of the
foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1])
the function `fill' gets inlined into the foldr loop, but in
the above, the lambda abstraction gets not inlined into
$wsimpleGen. Maybe it is because $wsimpleGen itself gets
not inlined...
Cheers,
Manuel
----Next_Part(Fri_Nov__3_00:54:22_2000_559)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="PArrays.hs"
-- Parallel Arrays: Sequential prototype
--
-- Authors: Manuel M. T. Chakravarty
-- Gabriele Keller
-- Created: 26 October 2000
--
-- Version $Revision$ from $Date$
--
-- Copyright (c) 2000 Chakravarty & Keller
--
-- This file is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This file is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
--- DESCRIPTION ---------------------------------------------------------------
--
-- This module provides unboxed arrays of primitive types as a sequential
-- prototype for the parallel arrays of Gabi's SCL. They come with all the
-- necessary operations to support flattened Haskell generated from lambdaPA.
--
--- DOCU ----------------------------------------------------------------------
--
-- language: Haskell 98 + GHC extensions (unboxed types and byte arrays)
--
-- We export the immutable `PArray' only; however, we internally also use a
-- mutable variant `MPArray', which allows us an efficient incremental
-- definition of the collective structure.
--
-- The class `PAE' is quite peculiar. It essentially serves to overload
-- array access (which depends on the size of the unboxed value stored in the
-- parallel array); however, the actual operations in the class are only to
-- be used internally in this module - and therefore, the class `PAE' is
-- exported *abstractly*. In fact, most operations work on mutable parallel
-- arrays for efficiency.
--
-- We shamelessly steal coding tricks from GHC's `ArrayBase', `IArray' &
-- friends, but without most of that overloading mess.
--
--- TODO ----------------------------------------------------------------------
--
module PArrays (
PAE, PArray, newPArray, (!|), loop, gen
) where
import PrelGHC
import PrelBase
import PrelST
import ST
infixl 9 !|
-- data structures
-- ---------------
-- * although all `PArray's are represented by the same structure, the
-- functions operating on them differ with the element type; hence, we have
-- to overload these functions
-- integer indexed array (EXPORTED ABSTRACTLY)
--
data PArray e = PArray Int ByteArray#
-- mutable integer indexed array
--
data MPArray s e = MPArray Int (MutableByteArray# s)
-- the class of "Parallel Array Element"s (EXPORTED ABSTRACTLY)
--
class PAE a where
newMPArray :: Int -> ST s (MPArray s a)
readMPArray :: MPArray s a -> Int -> ST s a
writeMPArray :: MPArray s a -> Int -> a -> ST s ()
indexPArray :: PArray a -> Int -> a
-- exported functions
-- ------------------
-- create new parallel array, where all elements are initialised to the given
-- values (EXPORTED)
--
newPArray :: PAE e => Int -> e -> PArray e
newPArray n e = runST (do
mpa <- newMPArray n
simpleGen n $ -- (**) These three lines instead
\i -> writeMPArray mpa i e -- of the following commented
return $ unsafeFreezeMPArray mpa) -- out line gives worse code.
-- foldr (fill mpa e) (return $ unsafeFreezeMPArray mpa) [0..n-1]) -- a la ArrayBase
{-# SPECIALIZE newPArray :: Int -> Int -> PArray Int #-}
fill mpa e i next = writeMPArray mpa i e >> next
-- indexing of a parallel array (EXPORTED)
--
(!|) :: PAE e => PArray e -> Int -> e
(!|) = indexPArray
-- Gabi's loop (EXPORTED)
--
loop :: () -- ??
loop = error "loop?"
-- Gabi's gen (EXPORTED)
--
gen :: () -- ??
gen = error "gen??"
-- instances of `PAE'
-- ------------------
instance PAE Int where
newMPArray = newMPArrayInt
readMPArray = readMPArrayInt
writeMPArray = writeMPArrayInt
indexPArray = indexPArrayInt
newMPArrayInt :: Int -> ST s (MPArray s Int)
newMPArrayInt n@(I# n#) = ST $ \s# ->
case (newIntArray# n# s#) of {(# s2#, mba# #) ->
(# s2#, MPArray n mba# #)}
readMPArrayInt :: MPArray s Int -> Int -> ST s Int
{-# INLINE readMPArrayInt #-}
readMPArrayInt (MPArray _ mba#) (I# i#) = ST $ \s# ->
case readIntArray# mba# i# s# of {(# s2#, r# #) ->
(# s2#, I# r# #)}
writeMPArrayInt :: MPArray s Int -> Int -> Int -> ST s ()
{-# INLINE writeMPArrayInt #-}
writeMPArrayInt (MPArray _ mba#) (I# i#) (I# e#) = ST $ \s# ->
case writeIntArray# mba# i# e# s# of {s2# ->
(# s2#, () #)}
indexPArrayInt :: PArray Int -> Int -> Int
{-# INLINE indexPArrayInt #-}
indexPArrayInt (PArray _ ba#) (I# i#) =
case indexIntArray# ba# i# of {r# ->
(I# r#)}
-- auxilliary functions
-- --------------------
-- unsafely convert a mutable into an immutable array
--
unsafeFreezeMPArray :: MPArray s e -> PArray e
unsafeFreezeMPArray (MPArray n mba#) = PArray n (unsafeCoerce# mba#)
-- simple generator abstraction
--
simpleGen :: Monad m => Int -> (Int -> m ()) -> m ()
{-# INLINE simpleGen #-}
simpleGen 0 p = return ()
simpleGen n p = p (n - 1) >> simpleGen (n - 1) p
{-
-- That's what we get for a newPArray specialised for Int and using the
-- explicitly recursive simpleGen.
$wsimpleGen =
NO_CCS srt: (0,2)[] \r[ww w]
case ww of ds {
0 -> $wlvl1;
DEFAULT ->
let {
stg_c1Qg =
NO_CCS srt: (0,1)[] \r[s1]
case -# [ds 1] of a {
DEFAULT ->
let { stg_c1Lg = NO_CCS I#! [a];
} in
case w stg_c1Lg s1 of wild {
(#,#) new_s r -> $wsimpleGen a w new_s;
}
};
} in stg_c1Qg
};
SRT: [$wsimpleGen, $wlvl1]
$w$snewPArray =
NO_CCS srt: (0,1)[] \r[ww w]
case newIntArray# [ww realWorld#] of wild {
(#,#) s2# mba# ->
let {
stg_c1M1 =
NO_CCS[] \r[i]
case i of wild1 {
I# i# ->
case w of wild2 {
I# e# ->
let {
stg_c1Q7 =
NO_CCS[] \r[s#]
case writeIntArray# [mba# i# e# s#] of s2#1 {
DEFAULT -> (#,#) [s2#1 ()]
};
} in stg_c1Q7;
};
};
} in
case $wsimpleGen ww stg_c1M1 s2# of wild1 {
(#,#) new_s r -> let { a = NO_CCS I#! [ww]; } in (#,#) [a mba#];
};
};
SRT: [$wsimpleGen]
-- the `case w of' could be pulled out of the loop
-- stg_c1Q7 builds a superfluous closure (which is immediately entered)
-- could we somehow get a specialised version of simpleGen?
-}
----Next_Part(Fri_Nov__3_00:54:22_2000_559)----
From lizard@Xterminator.STUDFB.UniBw-Muenchen.de Thu Nov 2 14:56:24 2000
From: lizard@Xterminator.STUDFB.UniBw-Muenchen.de (Oliver Braun)
Date: Thu, 2 Nov 2000 15:56:24 +0100
Subject: fatal error: heapCensus
In-Reply-To: <20001102143922.A1000@Mail.StudFb.UniBw-Muenchen.De>; from lizard@mail.studfb.unibw-muenchen.de on Don, Nov 02, 2000 at 02:39:22 +0100
References: <20001102143922.A1000@Mail.StudFb.UniBw-Muenchen.De>
Message-ID: <20001102155624.A648@Mail.StudFb.UniBw-Muenchen.De>
Hi again,
unfortunately I forgot to ask my questions ;o)
What does heapCensus mean ?
What can I do to avoid this error ?
> I have compiled all files with the -prof and the -auto-all flag.
>
> When starting the program
>
> * without any RTS options -> everything is OK
> * with +RTS -p -> everything is OK
> * with +RTS -h -> fatal error: heapCensus
>
> I am using GHC version 4.08.1 on a Debian/GNU Linux Box,
> installed with the newest Debian packages from
> http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian.
Olli
--
Federal Armed Forces University Munich Tel. 089 - 60190686
Werner-Heisenberg-Weg 102/128 Fax. 089 - 244333158
85577 Neubiberg mobil 0170 - 9317618
From simonpj@microsoft.com Thu Nov 2 17:11:47 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 2 Nov 2000 09:11:47 -0800
Subject: My mistake is harder to diagnose than it could be
Message-ID: <74096918BE6FD94B9068105F877C002D355AEE@red-pt-02.redmond.corp.microsoft.com>
In the new GHCi system we plan to make it *required* that the module name
and the file name
match, EXCEPT for module Main.
This seems to remove a whole class of errors.
Yell if that'll be problematic for you
Simon
| -----Original Message-----
| From: qrczak@knm.org.pl [mailto:qrczak@knm.org.pl]
| Sent: 18 August 2000 19:45
| To: glasgow-haskell-users@haskell.org
| Subject: My mistake is harder to diagnose than it could be
|
|
| I've just done the same mistake a third time: took a module A, moved
| part of it to a new module B, imported A from B, but forgot to change
| the module header in B which still said "module A".
|
| The GHC's answer to that when compiling B.hs is that the module A
| does not export a bunch of things (if listed explicitly in import),
| or that they are not found at all (if imported the whole A). Things
| that are easily seen exported from A.hs - strange that I was wondering
| again what's going on.
|
| GHC should warn when a module imports itself. Or warn about mismatches
| between the module and file name except Main. Or whatever -
| the current
| error message is not very helpful.
|
| --
| __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
| \__/
| ^^ SYGNATURA ZASTEPCZA
| QRCZAK
|
|
From simonmar@microsoft.com Fri Nov 3 10:02:25 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 3 Nov 2000 02:02:25 -0800
Subject: fatal error: heapCensus
Message-ID: <9584A4A864BD8548932F2F88EB30D1C610CE64@TVP-MSG-01.europe.corp.microsoft.com>
> unfortunately I forgot to ask my questions ;o)
>
> What does heapCensus mean ?
It's an internal error in GHC's heap profiler, and indicates a bug
somewhere. Could you send us the code?
Cheers,
Simon
From rrt1001@cam.ac.uk Mon Nov 6 12:21:40 2000
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Mon, 6 Nov 2000 12:21:40 +0000 (GMT)
Subject: New InstallShield
Message-ID:
Yet another improvement to the GHC 4.08.1 InstallShield. Thanks to Christian
Lescher and Sigbjorn Finne, various bugs have been fixed to do with DLL
building, so both static DLLs (where all the haskell stuff is linked in) and
dynamic DLLs (where the DLL you build is dependent on the GHC DLLs) work
rather better.
Also, thanks to Martijn Schrage for pointing out that I'd omitted the net
hslib from the InstallShield. It's there now.
--
http://sc3d.org/rrt/ | certain, a. insufficiently analysed
From stolz@I2.Informatik.RWTH-Aachen.DE Tue Nov 7 13:56:28 2000
From: stolz@I2.Informatik.RWTH-Aachen.DE (Volker Stolz)
Date: Tue, 7 Nov 2000 14:56:28 +0100
Subject: Select.hSelect & Threads
In-Reply-To: ; from kgolder@wellesley.edu on Tue, Oct 31, 2000 at 04:07:08PM -0500
References:
Message-ID: <20001107145628.A26868@agamemnon.informatik.rwth-aachen.de>
Will Select.hSelect block all running Haskell threads? I assume it does. However,
the small explanation at the bottom of the documentation seems too convoluted to
me to convey it's meaning. How about adding "Remember that this will *block* *all*
*your* *threads*" to it?
--
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From bjpop@cs.mu.OZ.AU Fri Nov 10 05:56:15 2000
From: bjpop@cs.mu.OZ.AU (Bernard James POPE)
Date: Fri, 10 Nov 2000 16:56:15 +1100 (EST)
Subject: getting type information about local bindings
Message-ID: <200011100556.QAA28692@mulga.cs.mu.OZ.AU>
Hi all,
In GHC 4.09 the flag "-ddump-types" causes the type signatures of
top-level bound identifiers to be printed.
I would really like to make use of the type-checker in GHC, however, I would
also like to obtain the types of locally bound identifiers
(things in let expressions and where clauses). Obviously there is going to
be some trickery regarding type variables from enclosing scopes.
I looked in the TcModule.lhs module and noticed that the TcResults
value returned by typecheckModule contains a value environment that only
specifies the types of top bound identifiers.
Further investigation of the code led me to the TcBinds.lhs module
and the tcBindsAndThen function. I can see that local type environments
are not passed upwards during type checking/inference.
At some point I got lost in the code. Does anyone know of a reasonable means
for obtaining this type information? I don't mind doing some hacking, but
I wanted to get advise from the experts as to whether I might be wasting
my time.
Perhaps such a thing is done somewhere when generating Core code?
As an aside I dare say that such an extension would be useful to other
people, particularly those writing source transformation code.
Regards,
Bernie.
From simonpj@microsoft.com Fri Nov 10 09:23:28 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 10 Nov 2000 01:23:28 -0800
Subject: getting type information about local bindings
Message-ID: <74096918BE6FD94B9068105F877C002D0110D62B@red-pt-02.redmond.corp.microsoft.com>
Don't try to get the type environment out. Instead, look at the
syntax tree produced by the type checker. Each binder is an Id.
There's a function
idType :: Id -> Type
that tells you the type of each binder. Quite how you present it
to the user in a good way isn't clear to me,
Simon
| -----Original Message-----
| From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU]
| Sent: 10 November 2000 05:56
| To: glasgow-haskell-users@haskell.org
| Cc: bjpop@cs.mu.OZ.AU
| Subject: getting type information about local bindings
|
|
| Hi all,
|
| In GHC 4.09 the flag "-ddump-types" causes the type signatures of
| top-level bound identifiers to be printed.
|
| I would really like to make use of the type-checker in GHC,
| however, I would
| also like to obtain the types of locally bound identifiers
| (things in let expressions and where clauses). Obviously
| there is going to
| be some trickery regarding type variables from enclosing scopes.
|
| I looked in the TcModule.lhs module and noticed that the TcResults
| value returned by typecheckModule contains a value
| environment that only
| specifies the types of top bound identifiers.
|
| Further investigation of the code led me to the TcBinds.lhs module
| and the tcBindsAndThen function. I can see that local type
| environments
| are not passed upwards during type checking/inference.
|
| At some point I got lost in the code. Does anyone know of a
| reasonable means
| for obtaining this type information? I don't mind doing some
| hacking, but
| I wanted to get advise from the experts as to whether I might
| be wasting
| my time.
|
| Perhaps such a thing is done somewhere when generating Core code?
|
| As an aside I dare say that such an extension would be useful
| to other
| people, particularly those writing source transformation code.
|
| Regards,
| Bernie.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simonmar@microsoft.com Mon Nov 13 15:41:53 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 13 Nov 2000 07:41:53 -0800
Subject: Select.hSelect & Threads
Message-ID: <9584A4A864BD8548932F2F88EB30D1C610CE8F@TVP-MSG-01.europe.corp.microsoft.com>
> Will Select.hSelect block all running Haskell threads? I
> assume it does. However,
> the small explanation at the bottom of the documentation
> seems too convoluted to
> me to convey it's meaning. How about adding "Remember that
> this will *block* *all*
> *your* *threads*" to it?
Thanks. I've rewritten this section to be clearer. It does indeed block
all Haskell threads.
Cheers,
Simon
From christian@lescher.de Mon Nov 13 18:24:14 2000
From: christian@lescher.de (Christian Lescher)
Date: Mon, 13 Nov 2000 19:24:14 +0100
Subject: Bug in GHC's Garbage Collection? (fwd) - C Strings
References: <9584A4A864BD8548932F2F88EB30D1C611576C@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <3A1031CE.2C4ED0F4@lescher.de>
Hi Simon,
> > 1) How to convert the Haskell string to a C string? - There's
> > a function
> >
> > packCString# :: [Char] -> ByteArray#
> > packCString# str = case (packString str) of { ByteArray _ _ bytes ->
> > bytes }
> >
> > in CStrings.lhs / PrelPack.lhs, which I probably have to use.
>
> Yes (but use packString rather than packString#).
Okay, so I have use: packString :: [Char] -> ByteArray Int
btw: what's the difference between packString and packCString then?
> > 2) How to pass a pointer (Addr) of the converted string back
> > to the outside
> > world?
>
> You can pass the ByteArray directly to a foreign imported function (which
> *must* be declared unsafe - you can't pass ByteArrays to safe ccalls).
I think, here the context got lost: I want to expose a Haskell function with
a string result rather than calling a C function from Haskell.
> > 3) Who is responsible for freeing the memory of the string result? I
> > suppose this should be done outside. But what to do that GHC's garbage
> > collection doesn't free it automatically?
>
> The ByteArray is freed automatically by GHC's garbage collector. If you
> need something more permanent, use malloc/free and the functions from
> Storable to do the marshalling.
For instance, how would you define a function like
revstr :: String -> String
revstr s = reverse s
for foreign export?
(The conversion of the string argument I handled like this:)
strlength :: Addr -> IO Int
strlength cstr = do
s <- unpackCStringIO cstr
return (length s)
foreign export stdcall strlength :: Addr -> IO Int
Cheers, Christian
P.S. I think, some information on the handling of typical string conversion
problems would be an interesting topic for GHC's user's manual, too.
From marte@pms.informatik.uni-muenchen.de Tue Nov 14 17:58:28 2000
From: marte@pms.informatik.uni-muenchen.de (Michael Marte)
Date: Tue, 14 Nov 2000 18:58:28 +0100 (CET)
Subject: Problems with libgmp
Message-ID:
Hello,
I am maintaining the Haskell stuff at informatik.uni-muenchen.de.
(I took over the job from Sven Panne.)
As a first exercise, I try to compile ghc-4.08.1 from scratch.
But I always run into trouble with the libgmp stuff.
IMHO, my problems are caused by several factors:
1. We use Suse Linux 7.0 (that provides libgmp-3.0.x).
2. The ghc-4.08-1 distribution includes libgmp-2.x.x.
3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names
are generated only if the header file is included.
4. The configure script does not recognize that libgmp is
installed (because it does not include the header file.)
5. When linking, the linker cannot resolve symbols prefixed by mpz_
(because the 2.x.x header file was used in compilation but the
linker uses the shared library provided by Suse Linux.)
5. Even if informed about the local installation of libgmp (by manually
changing config.cache), the 2.x.x header file will be used (again
resulting in unresolved bindings when linking).
The same problems occur when bootstrapping from .hc files.
What to do? Should I hack the Makefiles? Should I replace the libgmp
distribution included in the ghc distribution by some new 3.x.x
distribution?
Thank you,
Michael Marte
From romildo@urano.iceb.ufop.br Wed Nov 15 05:15:53 2000
From: romildo@urano.iceb.ufop.br (=?iso-8859-1?Q?Jos=E9_Romildo_Malaquias?=)
Date: Wed, 15 Nov 2000 03:15:53 -0200
Subject: The Parsec library distributed with GHC
Message-ID: <20001115031553.D26549@urano.iceb.ufop.br>
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Hello.
The Parsec library (in package text from hslibs)
distributed with GHC 4.08.1 and from CVS does not
work as expected. When I try the attached
program, ghc gives me error messages:
=================================
test.hs:6:
Couldn't match `TokenParser' against `[Char]'
Expected type: TokenParser
Inferred type: [Char]
In the first argument of `symbol', namely `"let"'
In a do statement: symbol "let"
test.hs:12:
Ambiguous type variable(s) `a' in the constraint `Show a'
arising from use of `print' at test.hs:12
In the right-hand side of an equation for `main':
print (parse pLet "" "let a = 232")
Compilation had errors
=================================
This same program works if I use the Parsec library
downloaded from the author page
(after correcting a small bug relative to using some
names from the Char module without importing them).
I hope the library gets updated in the GHC CVS repository
and the next GHC release corrects this problem.
Regards,
Romildo
--
Prof. José Romildo Malaquias
Departamento de Computação
Universidade Federal de Ouro Preto
Brasil
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test.hs"
module Main where
import Parsec
import ParsecToken
pLet = do symbol "let"
id <- identifier
symbol "="
x <- integer
return (id,x)
main = print (parse pLet "" "let a = 232")
--VS++wcV0S1rZb1Fb--
From simonmar@microsoft.com Wed Nov 15 09:50:04 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 15 Nov 2000 01:50:04 -0800
Subject: Problems with libgmp
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611576E@TVP-MSG-01.europe.corp.microsoft.com>
> I am maintaining the Haskell stuff at informatik.uni-muenchen.de.
> (I took over the job from Sven Panne.)
>
> As a first exercise, I try to compile ghc-4.08.1 from scratch.
> But I always run into trouble with the libgmp stuff.
> IMHO, my problems are caused by several factors:
>
> 1. We use Suse Linux 7.0 (that provides libgmp-3.0.x).
> 2. The ghc-4.08-1 distribution includes libgmp-2.x.x.
> 3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names
> are generated only if the header file is included.
> 4. The configure script does not recognize that libgmp is
> installed (because it does not include the header file.)
> 5. When linking, the linker cannot resolve symbols prefixed by mpz_
> (because the 2.x.x header file was used in compilation but the
> linker uses the shared library provided by Suse Linux.)
> 5. Even if informed about the local installation of libgmp
> (by manually
> changing config.cache), the 2.x.x header file will be used (again
> resulting in unresolved bindings when linking).
>
> The same problems occur when bootstrapping from .hc files.
>
> What to do? Should I hack the Makefiles? Should I replace the libgmp
> distribution included in the ghc distribution by some new 3.x.x
> distribution?
I'll try to clarify the situation, since it's a bit confusing.
- GHC tries to detect GMP 2 on the host system during the
configuration process. If it detects it, the build will
go on to use the installed version.
- If GMP 2 was *not* found, then we fall back to the copy of
GMP in the source tree, which is build statically.
- the RPMs have a dependency on the gmp2 packages.
- GMP 3 is only source compatible with GMP 2, as you discovered.
Furthermore, using the GMP 2 headers with the GMP 3 library
aint gonna work. (if your system is set up like this, then
it's broken, just like ours :-)
- GHC versions post-4.08.X use GMP 3.
So, I can't quite work out what went wrong in your case. If the build
didn't detect GMP 2, then it should have just used the one in the tree.
BTW, you can't use GMP 3 with ghc-4.08.1 (the native code generator at
least will break).
Hope this helps :)
Cheers,
Simon
From marte@pms.informatik.uni-muenchen.de Wed Nov 15 16:47:08 2000
From: marte@pms.informatik.uni-muenchen.de (Michael Marte)
Date: Wed, 15 Nov 2000 17:47:08 +0100 (CET)
Subject: Problems with libgmp
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611576E@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Hello Simon,
> So, I can't quite work out what went wrong in your case. If the build
> didn't detect GMP 2, then it should have just used the one in the tree.
Obviously, when linking, it did not use the one in the tree :-(
Conclusion: The Linux linker does not behave like other linkers or
there is a bug in some Makefile.
> BTW, you can't use GMP 3 with ghc-4.08.1 (the native code generator at
> least will break).
Ok, I'll to try to get a snapshot from the CVS repository.
Thanks,
Michael
From ger@Informatik.Uni-Bremen.DE Wed Nov 15 17:42:29 2000
From: ger@Informatik.Uni-Bremen.DE (George Russell)
Date: Wed, 15 Nov 2000 18:42:29 +0100
Subject: Instant readFile
Message-ID: <3A12CB05.C7E6F754@informatik.uni-bremen.de>
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 . . .
From simonmar@microsoft.com Thu Nov 16 09:57:00 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 16 Nov 2000 01:57:00 -0800
Subject: Problems with libgmp
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F2B7@TVP-MSG-01.europe.corp.microsoft.com>
> > > So, I can't quite work out what went wrong in your case.
> If the build
> > > didn't detect GMP 2, then it should have just used the
> one in the tree.
> >
> > Obviously, when linking, it did not use the one in the tree :-(
> > Conclusion: The Linux linker does not behave like other linkers or
> > there is a bug in some Makefile.
>
> Of late I have had problems with libgmp2 and woody-debian. I
> solved the
> problem the first time around by adding a sym link
> /usr/lib/libgmp2.so ->
> /usr/lib/libgmp.so.2.0.2
>
> Yesterday I solved the problem by installing libgmp2-dev
> because ld was
> looking for libgmp.a for some reason when trying to compile hdirect.
>
> Hacks at best. Haven't really looked for whys and wherefores.
The binary distributions of 4.08.2 will come with a statically linked
libgmp.a.
It's up to the package maintainers (RedHat RPM, Debian etc.) to decide
the best approach for those systems, i.e. whether it's better to depend
on the system-supplied shared libgmp or supply one in the GHC package.
On FreeBSD for example I just use the system-supplied one since it's
part of the base system.
Cheers,
Simon
From simonmar@microsoft.com Thu Nov 16 10:24:36 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 16 Nov 2000 02:24:36 -0800
Subject: Instant readFile
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115772@TVP-MSG-01.europe.corp.microsoft.com>
George Russell writes:
> 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?
Well, you could always free the address directly after unpacking it,
since unpackCStringLenIO generates the whole string in one go.
> 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 . . .
The alternative is to use a ByteArray to store the string. These live
in the heap and so get garbage collected automatically, and should be
quicker to allocate than using malloc.
Check out the hGetBuf family of functions in IOExts, there are versions
for reading into/out of ByteArrays, and there are variants of
unpackCString that work with ByteArrays (unpackNBytesBA, for example).
[ side note: ByteArrays and MutableByteArrays will eventually be
replaced by UArray and STUArray/IOUArray which are functionally
identical but have a nice overloaded interface in IArray/MArray. ]
Cheers,
Simon
From hul@progsoc.uts.edu.au Thu Nov 16 03:05:13 2000
From: hul@progsoc.uts.edu.au (Rahul Bhargava)
Date: Thu, 16 Nov 2000 14:05:13 +1100 (EST)
Subject: Problems with libgmp
In-Reply-To:
Message-ID:
> > So, I can't quite work out what went wrong in your case. If the build
> > didn't detect GMP 2, then it should have just used the one in the tree.
>
> Obviously, when linking, it did not use the one in the tree :-(
> Conclusion: The Linux linker does not behave like other linkers or
> there is a bug in some Makefile.
Of late I have had problems with libgmp2 and woody-debian. I solved the
problem the first time around by adding a sym link /usr/lib/libgmp2.so ->
/usr/lib/libgmp.so.2.0.2
Yesterday I solved the problem by installing libgmp2-dev because ld was
looking for libgmp.a for some reason when trying to compile hdirect.
Hacks at best. Haven't really looked for whys and wherefores.
Rahul
From qrczak@knm.org.pl Wed Nov 15 22:10:19 2000
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 15 Nov 2000 22:10:19 GMT
Subject: Instant readFile
References: <3A12CB05.C7E6F754@informatik.uni-bremen.de>
Message-ID:
Wed, 15 Nov 2000 18:42:29 +0100, George Russell pisze:
> 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.
Applying
foldr (\_ t -> t) (return ())
to the string (and executing this application as an IO action) will
force it to be read completely. If it came from readFile, the file
gets closed as soon as the string is evaluated up to its end.
> 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 . . .
Unfortunately the design of these areas (conversion between Haskell
strings and C strings) is not yet complete. And Unicode in Haskell
strings (already implemented in GHC development versions) will make
the library more complex.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From bjpop@cs.mu.OZ.AU Sun Nov 19 07:34:21 2000
From: bjpop@cs.mu.OZ.AU (Bernard James POPE)
Date: Sun, 19 Nov 2000 18:34:21 +1100 (EST)
Subject: types from ghc (another question)
Message-ID: <200011190734.SAA29150@mulga.cs.mu.OZ.AU>
Hi again,
Simon Peyton-Jones writes:
> Don't try to get the type environment out. Instead, look at the
> syntax tree produced by the type checker. Each binder is an Id.
> There's a function
> idType :: Id -> Type
> that tells you the type of each binder. Quite how you present it
> to the user in a good way isn't clear to me,
Thanks Simon.
In TcModule.lhs I added some code like this:
myDumpTc results
= myPprMonoBinds $ tc_binds results
where
myPprMonoBinds (AndMonoBinds b1 b2)
= myPprMonoBinds b1 $$ myPprMonoBinds b2
myPprMonoBinds (FunMonoBind id _ matches _)
= (ppr (toRdrName id)) <+>
dcolon <+>
(ppr $ idType id) $$
myPprMatches matches
{- etc, etc ... -}
For the following contrived example:
main = putStr $ show (fred 1 3)
where
fred a b = let myid x = x in myid (plus a b)
plus x y = x + y
My output is:
main :: IO ()
plus :: a -> a -> a
fred :: a -> a -> a
myid :: t_aMv -> t_aMv
Which is nearly exactly what I want, however, the class constraints are missing
from the signatures for plus and fred. The universal quantification of
the type variable t_aMv is also missing.
One curiosity is that the compiler has generated the variable 'a' in
the two circumstances where the variables are constrained, which makes me think
something special is happening here.
If you defined all the binders at the top-level and supplied the
-ddump-types flag to ghc (with a modification to the code to turn off the
conversion to HsType, so that the unique variable names do not get clobbered)
you get the proper polymorphic type signatures
for each of the identifiers (ie myid :: forall t_aMv . t_aMv -> t_aMv).
My question is: can I find out any information about the constraints on
variables from the types that I find in the tc_binds component of the type
checking results?
(apologies for my being long-winded).
Regards,
Bernie.
From simonpj@microsoft.com Mon Nov 20 09:50:31 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 20 Nov 2000 01:50:31 -0800
Subject: types from ghc (another question)
Message-ID: <74096918BE6FD94B9068105F877C002D0110D77A@red-pt-02.redmond.corp.microsoft.com>
Bernie
All (I think) the top level bindings come out of the type check
as an AbsBinds. This is where we generalise from a monomorphic
thing to a polymorphic thing.
An AbsBinds has four components, the third of which is a list of
triples (TyVar, Id, Id). You want to grab the first of these Ids (only).
You can then ignore the MonoBinds inside the fourth component of
the AbsBinds. So your code will get quite a bit simpler.
The two Ids in the triple are the polymorphic top-level binder and
the monomorphic (perhaps recursive) thing that it generalises.
It's a bit hard to explain in a short space. Look at the output of the
desugarer for a simple defn, to see what an AbsBinds translates to.
Anyway these polymorphic Ids will have exactly the for-alls and
constraints that you want
hope this gets you moving
Simon
| -----Original Message-----
| From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU]
| Sent: 19 November 2000 07:34
| To: glasgow-haskell-users@haskell.org
| Cc: bjpop@cs.mu.OZ.AU
| Subject: types from ghc (another question)
|
|
| Hi again,
|
| Simon Peyton-Jones writes:
|
| > Don't try to get the type environment out. Instead, look at the
| > syntax tree produced by the type checker. Each binder is an Id.
| > There's a function
| > idType :: Id -> Type
| > that tells you the type of each binder. Quite how you present it
| > to the user in a good way isn't clear to me,
|
| Thanks Simon.
|
| In TcModule.lhs I added some code like this:
|
| myDumpTc results
| = myPprMonoBinds $ tc_binds results
| where
| myPprMonoBinds (AndMonoBinds b1 b2)
| = myPprMonoBinds b1 $$ myPprMonoBinds b2
|
| myPprMonoBinds (FunMonoBind id _ matches _)
| = (ppr (toRdrName id)) <+>
| dcolon <+>
| (ppr $ idType id) $$
| myPprMatches matches
|
| {- etc, etc ... -}
|
|
| For the following contrived example:
|
| main = putStr $ show (fred 1 3)
| where
| fred a b = let myid x = x in myid (plus a b)
| plus x y = x + y
|
| My output is:
|
| main :: IO ()
| plus :: a -> a -> a
| fred :: a -> a -> a
| myid :: t_aMv -> t_aMv
|
| Which is nearly exactly what I want, however, the class
| constraints are missing
| from the signatures for plus and fred. The universal
| quantification of
| the type variable t_aMv is also missing.
|
| One curiosity is that the compiler has generated the variable 'a' in
| the two circumstances where the variables are constrained,
| which makes me think
| something special is happening here.
|
| If you defined all the binders at the top-level and supplied the
| -ddump-types flag to ghc (with a modification to the code to
| turn off the
| conversion to HsType, so that the unique variable names do
| not get clobbered)
| you get the proper polymorphic type signatures
| for each of the identifiers (ie myid :: forall t_aMv . t_aMv
| -> t_aMv).
|
| My question is: can I find out any information about the
| constraints on
| variables from the types that I find in the tc_binds
| component of the type
| checking results?
|
| (apologies for my being long-winded).
|
| Regards,
| Bernie.
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From bjpop@cs.mu.OZ.AU Tue Nov 21 06:42:47 2000
From: bjpop@cs.mu.OZ.AU (Bernard James POPE)
Date: Tue, 21 Nov 2000 17:42:47 +1100 (EST)
Subject: types from ghc - got them!
Message-ID: <200011210642.RAA04906@mulga.cs.mu.OZ.AU>
Hi again,
For my previous example:
main = putStr $ show (fred 1 3)
where
fred a b = let myid x = x in myid (plus a b)
plus x y = x + y
I can now get the following output:
==================== Bernie: All Binder TypeSigs ====================
main :: IO ()
plus :: forall a. (Num a) => a -> a -> a
fred :: forall a. (Num a) => a -> a -> a
myid :: forall t_aMv. t_aMv -> t_aMv
Which is exactly what I want. Turned out to be quite simple in the end.
Thanks a lot for all your help Simon.
Just out of curiosity, do you think that this sort of output would be
useful for other people? I don't know what your plans are for GHCi, but you
may be considering a mode that prints types out, something like :t in
hugs. I always found it frustrating in hugs that I couldn't get the types
of locally defined values. My students also find this frustrating, and it
sometimes causes them to avoid local definitions. Obviously there are issues
with type variables which are quantified outside the local definition, but
careful naming of things should be able to fix this.
Regards,
Bernie.
Simon Peyton-Jones writes:
> Bernie
>
> All (I think) the top level bindings come out of the type check
> as an AbsBinds. This is where we generalise from a monomorphic
> thing to a polymorphic thing.
>
> An AbsBinds has four components, the third of which is a list of
> triples (TyVar, Id, Id). You want to grab the first of these Ids (only).
> You can then ignore the MonoBinds inside the fourth component of
> the AbsBinds. So your code will get quite a bit simpler.
>
> The two Ids in the triple are the polymorphic top-level binder and
> the monomorphic (perhaps recursive) thing that it generalises.
> It's a bit hard to explain in a short space. Look at the output of the
> desugarer for a simple defn, to see what an AbsBinds translates to.
>
> Anyway these polymorphic Ids will have exactly the for-alls and
> constraints that you want
>
> hope this gets you moving
From simonpj@microsoft.com Tue Nov 21 13:48:42 2000
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 21 Nov 2000 05:48:42 -0800
Subject: types from ghc - got them!
Message-ID: <74096918BE6FD94B9068105F877C002D0110D7BB@red-pt-02.redmond.corp.microsoft.com>
Well done.
We're blazing away on GHCI (an interactive version of GHC)
at the moment, including
a user interface. When it's usable, perhaps you'd like to look
at it with a view to adding this feature?
Simon
| -----Original Message-----
| From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU]
| Sent: 21 November 2000 06:43
| To: glasgow-haskell-users@haskell.org
| Cc: bjpop@cs.mu.OZ.AU
| Subject: types from ghc - got them!
|
|
| Hi again,
|
| For my previous example:
|
| main = putStr $ show (fred 1 3)
| where
| fred a b = let myid x = x in myid (plus a b)
| plus x y = x + y
|
| I can now get the following output:
|
| ==================== Bernie: All Binder TypeSigs
| ====================
| main :: IO ()
| plus :: forall a. (Num a) => a -> a -> a
| fred :: forall a. (Num a) => a -> a -> a
| myid :: forall t_aMv. t_aMv -> t_aMv
|
| Which is exactly what I want. Turned out to be quite simple
| in the end.
|
| Thanks a lot for all your help Simon.
|
| Just out of curiosity, do you think that this sort of output would be
| useful for other people? I don't know what your plans are for
| GHCi, but you
| may be considering a mode that prints types out, something like :t in
| hugs. I always found it frustrating in hugs that I couldn't
| get the types
| of locally defined values. My students also find this
| frustrating, and it
| sometimes causes them to avoid local definitions. Obviously
| there are issues
| with type variables which are quantified outside the local
| definition, but
| careful naming of things should be able to fix this.
|
| Regards,
| Bernie.
|
|
| Simon Peyton-Jones writes:
|
| > Bernie
| >
| > All (I think) the top level bindings come out of the type check
| > as an AbsBinds. This is where we generalise from a monomorphic
| > thing to a polymorphic thing.
| >
| > An AbsBinds has four components, the third of which is a list of
| > triples (TyVar, Id, Id). You want to grab the first of
| these Ids (only).
| > You can then ignore the MonoBinds inside the fourth component of
| > the AbsBinds. So your code will get quite a bit simpler.
| >
| > The two Ids in the triple are the polymorphic top-level binder and
| > the monomorphic (perhaps recursive) thing that it generalises.
| > It's a bit hard to explain in a short space. Look at the
| output of the
| > desugarer for a simple defn, to see what an AbsBinds translates to.
| >
| > Anyway these polymorphic Ids will have exactly the for-alls and
| > constraints that you want
| >
| > hope this gets you moving
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
From simona@I2.Informatik.RWTH-Aachen.DE Tue Nov 21 15:31:50 2000
From: simona@I2.Informatik.RWTH-Aachen.DE (Axel Simon)
Date: Tue, 21 Nov 2000 16:31:50 +0100 (CET)
Subject: types from ghc - got them!
In-Reply-To: <200011210642.RAA04906@mulga.cs.mu.OZ.AU>
Message-ID:
On Tue, 21 Nov 2000, Bernard James POPE wrote:
> Obviously there are issues
> with type variables which are quantified outside the local definition, but
> careful naming of things should be able to fix this.
Hi,
For my master thesis I wrote a tool called Typeview (presented at IFL'00)
that can display the types of arbitrary expressions (even in programs that
are not typecorrect). We chose to append an underscore to every type
variable that is not quantified at the examined expression:
f :: a -> (a, Int)
f x = let g y = (x,y) in g 3
In this program the type of the local expression is g:: b -> (_a,b). This
approach could be used for local type annotations (and thereby replacing
the pattern annotations), the :t command and error messages. Of course
you have to make sure that _a is not ambiguous.
Cheers,
Axel.
From phoenix@esther.donga.ac.kr Sat Nov 25 12:03:21 2000
From: phoenix@esther.donga.ac.kr (Wooseok Yang)
Date: Sat, 25 Nov 2000 21:03:21 +0900
Subject: unsubscribe glasgow-haskell-users
Message-ID: <006d01c056d7$b4ec8250$a42573a8@phoenix>
dW5zdWJzY3JpYmUgZ2xhc2dvdy1oYXNrZWxsLXVzZXJzDQo=
From rrt1001@cam.ac.uk Mon Nov 27 10:45:23 2000
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Mon, 27 Nov 2000 10:45:23 +0000 (GMT)
Subject: New InstallShield: no more DLLs
Message-ID:
I've put up a new InstallShield for GHC 4.08.1 (Windows edition). This no
longer contains DLLs and import libraries for the libraries, so you have to
use the compiler with -static.
I intend to stick to this scheme in future releases (probably replacing
-static with -dynamic), as GHC derives few benefits from DLLized libraries,
and a lot of disadvantages. Also, there is at present an unresolved and
deep-seated bug (possibly not even in GHC) that prevents some very simple
DLLized programs from working.
Users of DLLs need not despair: one important (and, to the best of my
knowledge, fully working) version of DLL building remains: you can still
build static DLLs, that is, DLLs in which all the code has been compiled
statically, so that all the necessary library code is linked into the DLL.
Hence, you can still build DLLs to be called from other languages, or to be
wrapped up as COM components, or whatever.
Finally, one nice side effect is that the size of the distribution is nearly
halved: it now weighs in at a little over 12Mb.
--
http://sc3d.org/rrt/ | violence, n. bravery for cowards
From christian@lescher.de Mon Nov 27 18:37:23 2000
From: christian@lescher.de (Christian Lescher)
Date: Mon, 27 Nov 2000 19:37:23 +0100
Subject: New InstallShield: no more DLLs
References: <20001127170101.F3801101E@www.haskell.org>
Message-ID: <3A22A9E3.53BF5203@lescher.de>
> I've put up a new InstallShield for GHC 4.08.1 (Windows edition). This no
> longer contains DLLs and import libraries for the libraries, so you have to
> use the compiler with -static.
Hmm ... That's really a fundamental change in GHC's Windows edition.
> I intend to stick to this scheme in future releases (probably replacing
> -static with -dynamic
Good idea! :-) I also regard statically linking as more common than dynamically
linking, so I welcome your idea to make statically linking the default.
> ), as GHC derives few benefits from DLLized libraries,
> and a lot of disadvantages. Also, there is at present an unresolved and
> deep-seated bug (possibly not even in GHC) that prevents some very simple
> DLLized programs from working.
When may Win users expect this bug to be fixed? (A difficult question, I know.)
Although I regard statically linking as much more important than the DLLized
alternative, dynamically linking is (was?) an important feature of GHC for Win -
f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC.
> Users of DLLs need not despair: one important (and, to the best of my
> knowledge, fully working) version of DLL building remains: you can still
> build static DLLs, that is, DLLs in which all the code has been compiled
> statically, so that all the necessary library code is linked into the DLL.
> Hence, you can still build DLLs to be called from other languages, or to be
> wrapped up as COM components, or whatever.
Exposing Haskell functions to other languages in DLLs is a very, very important
feature of GHC's Win edition! Please go on supporting it as you do!!
> Finally, one nice side effect is that the size of the distribution is nearly
> halved: it now weighs in at a little over 12Mb.
Cheers, Christian
From plop@redbrick.dcu.ie Tue Nov 28 11:15:14 2000
From: plop@redbrick.dcu.ie (Smelly Pooh)
Date: Tue, 28 Nov 2000 11:15:14 +0000
Subject: Exception Handling
Message-ID: <20001128111514.A8576@enigma.redbrick.dcu.ie>
I'm writing an application at the moment (in Haskell duh) and the issue of
exception handling has come up. I don't want to use Maybe (because that would
destructure the code somewhat) or any kind of Monad and I've settled on the
idea of SPJs Exception extension. The idea is to create a data type with a
different constructor per exception as in
data MyException = Ex1 | Ex2 | Ex3
then use throwDyn/catchDyn to throw and catch it. Unfortunately this requires
MyException to be an instance of class Typeable, and the documentation on that
is quite sparse. Any advice or pointers would be greatly appreciated
From stolz@I2.Informatik.RWTH-Aachen.DE Tue Nov 28 11:28:50 2000
From: stolz@I2.Informatik.RWTH-Aachen.DE (Volker Stolz)
Date: Tue, 28 Nov 2000 12:28:50 +0100
Subject: Exception Handling
In-Reply-To: <20001128111514.A8576@enigma.redbrick.dcu.ie>; from plop@redbrick.dcu.ie on Tue, Nov 28, 2000 at 11:15:14AM +0000
References: <20001128111514.A8576@enigma.redbrick.dcu.ie>
Message-ID: <20001128122850.D15027@agamemnon.informatik.rwth-aachen.de>
On Tue, Nov 28, 2000 at 11:15:14AM +0000, Smelly Pooh wrote:
> I'm writing an application at the moment (in Haskell duh) and the issue of
> exception handling has come up. I don't want to use Maybe (because that would
> destructure the code somewhat) or any kind of Monad and I've settled on the
> idea of SPJs Exception extension. The idea is to create a data type with a
> different constructor per exception as in
>
> data MyException = Ex1 | Ex2 | Ex3
>
> then use throwDyn/catchDyn to throw and catch it. Unfortunately this requires
> MyException to be an instance of class Typeable, and the documentation on that
> is quite sparse. Any advice or pointers would be greatly appreciated
\begin{code}
data DMsg = DOne | DTwo Int | DThree String | DQuit
instance Typeable DMsg where
typeOf _ = mkAppTy msgTc []
msgTc :: TyCon
msgTc = mkTyCon "Msg"
-- To Dynamic:
let dyn = toDyn msg
-- and back:
let msg = fromDynamic dyn
case msg of
Just _ -> ...
Nothing -> error (..)
\end{code}
--
\usepackage[latin1]{inputenc}!
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From rrt1001@cam.ac.uk Tue Nov 28 12:48:46 2000
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Tue, 28 Nov 2000 12:48:46 +0000 (GMT)
Subject: New InstallShield: no more DLLs
In-Reply-To: <3A22A9E3.53BF5203@lescher.de>
Message-ID:
> > Also, there is at present an unresolved and
> > deep-seated bug (possibly not even in GHC) that prevents some very simple
> > DLLized programs from working.
>
> When may Win users expect this bug to be fixed? (A difficult question, I know.)
I've given up on it for the moment; having looked at the source code of ld,
asked on the binutils and Cygwin mailing lists, and a few other things, I
can't work out what the problem is. I do have a few more things to try, but
I don't hold out much hope of fixing it soon without help.
> Although I regard statically linking as much more important than the DLLized
> alternative, dynamically linking is (was?) an important feature of GHC for Win -
> f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC.
This is only a good idea if you really are distributing several DLLs or EXEs
built with GHC (so that you do get space savings), and even then you have to
ask yourself if it's worth the risk of DLL Hell (which I have suffered from
several times). Disk space is so cheap now that you really have to be hurt
somewhere (e.g. increased download times, decreased performance because of
large unshared binaries) before it's worth dynamic linking (except to
relatively stable system libraries).
--
http://sc3d.org/rrt/ | computation, n. automated pedantry
From christian@lescher.de Tue Nov 28 18:47:00 2000
From: christian@lescher.de (Christian Lescher)
Date: Tue, 28 Nov 2000 19:47:00 +0100
Subject: New InstallShield: no more DLLs
References:
Message-ID: <3A23FDA3.A994B660@lescher.de>
> > > Also, there is at present an unresolved and
> > > deep-seated bug (possibly not even in GHC) that prevents some very simple
> > > DLLized programs from working.
> >
> > When may Win users expect this bug to be fixed? (A difficult question, I know.)
>
> I've given up on it for the moment; having looked at the source code of ld,
> asked on the binutils and Cygwin mailing lists, and a few other things, I
> can't work out what the problem is. I do have a few more things to try, but
> I don't hold out much hope of fixing it soon without help.
I'd like to offer help, but I'm afraid I don't know enough about the 'interna' of GHC
and cygwin :-( [Would be nice, if I could learn more about it in the future!]
Besides, I've got some (not so fortunate) news: even after updating binutils and the
whole cygwin to the latest version, the problem with *statically* linked and
afterwards stripped DLLs build with GHC remains - the unstripped version works well,
but the stripped one crashes in some constellations. I will try to make this error
reproducable and let you know about it. Something is still wrong here - probably with
cygwin. Maybe this has also got something to do with the dyn. linking problem?
> > Although I regard statically linking as much more important than the DLLized
> > alternative, dynamically linking is (was?) an important feature of GHC for Win -
> > f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC.
>
> This is only a good idea if you really are distributing several DLLs or EXEs
> built with GHC (so that you do get space savings), and even then you have to
> ask yourself if it's worth the risk of DLL Hell (which I have suffered from
> several times). Disk space is so cheap now that you really have to be hurt
> somewhere (e.g. increased download times, decreased performance because of
> large unshared binaries) before it's worth dynamic linking (except to
> relatively stable system libraries).
Yes, that's true. However, dynamically linking would be a feature.
Cheers, Christian
From abf@cs.ucc.ie Thu Nov 30 14:21:00 2000
From: abf@cs.ucc.ie (Alex Ferguson)
Date: Thu, 30 Nov 2000 14:21:00 GMT
Subject: ghc-4.xx Alpha port?
Message-ID: <200011301421.OAA00622@joyce.ucc.ie>
Hi guys. Has anyone been so rash as to try this? Any indications
as to the likely "degree of difficulty"? I'd have a go myself, but
I'm rather busy with teaching. (Which is ironic, since teaching is
what I want it for...)
Cheers,
Alex.
From simonmar@microsoft.com Thu Nov 30 15:40:58 2000
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 30 Nov 2000 07:40:58 -0800
Subject: ghc-4.xx Alpha port?
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611577B@TVP-MSG-01.europe.corp.microsoft.com>
> Hi guys. Has anyone been so rash as to try this? Any indications
> as to the likely "degree of difficulty"? I'd have a go myself, but
> I'm rather busy with teaching. (Which is ironic, since teaching is
> what I want it for...)
Degree of difficulty is likely to be less than a starting completely
non-existent port (eg. IA64), but still significant. The 64-bitness is
likely to be more of an issue than the Alpha-specific stuff, though.
If there's sufficient demand for a port I'll help out; I did have an
account on the Compaq testdrive machines at one point (they have
Alpha/Linux and Alpha/*BSD machines) which has probably expired now, but
it's a good place to get some free Alpha cycles.
Cheers,
Simon
From v-julsew@microsoft.com Thu Nov 30 16:14:46 2000
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Thu, 30 Nov 2000 08:14:46 -0800
Subject: ghc-4.xx Alpha port?
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60EFB51@red-msg-06.redmond.corp.microsoft.com>
| > Hi guys. Has anyone been so rash as to try this? Any indications
| > as to the likely "degree of difficulty"? I'd have a go myself, but
| > I'm rather busy with teaching. (Which is ironic, since teaching is
| > what I want it for...)
|
| Degree of difficulty is likely to be less than a starting completely
| non-existent port (eg. IA64), but still significant. The
| 64-bitness is
| likely to be more of an issue than the Alpha-specific stuff, though.
Getting it working on Alphas would also be of benefit in the sense
that it gets the 64-bitness working again. That gives one less thing
to worry about when porting to IA64, if/when that should happen.
J
From Malcolm.Wallace@cs.york.ac.uk Thu Nov 30 17:18:42 2000
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 30 Nov 2000 17:18:42 +0000
Subject: file suffixes
Message-ID:
I recall that at one point GHC came with "bundles", built in "ways",
like profiling, parallel, tickyticky, etc.. There was also some
filename-mangling scheme for distinguishing .hi interface and .o
object files from the different bundles.
My question is, what was that filename-mangling scheme? I ask because
I'm about to do something similar for nhc98's "ways" (heap-profiling,
time-profiling, tracing, etc.), and some consistency here might
be useful.
Regards,
Malcolm
From rrt1001@cam.ac.uk Thu Nov 30 17:42:05 2000
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Thu, 30 Nov 2000 17:42:05 +0000 (GMT)
Subject: file suffixes
In-Reply-To:
Message-ID:
> I recall that at one point GHC came with "bundles", built in "ways",
> like profiling, parallel, tickyticky, etc.. There was also some
> filename-mangling scheme for distinguishing .hi interface and .o
> object files from the different bundles.
>
> My question is, what was that filename-mangling scheme? I ask because
> I'm about to do something similar for nhc98's "ways" (heap-profiling,
> time-profiling, tracing, etc.), and some consistency here might
> be useful.
We change extensions such as .ext to .way_ext. This works for most things
except libraries, which get changed from .a to _way.a.
--
http://sc3d.org/rrt/ | certain, a. insufficiently analysed