August 2004 - Glasgow-haskell-users

RE: What does LIE stand for?
by Simon Peyton-Jones 19 Aug '04

19 Aug '04

Yep, "Local Instance Environment". It comes from one of the original papers about giving a formal description for Haskell's type system (in TOPLAS, by Cordelia Hall et al). It's not a very good name. | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Sean Seefried | Sent: 19 August 2004 03:50 | To: GHC Users | Subject: What does LIE stand for? | | Hi all, | | I've been looking through the source code and the GHC commentary and I | still can't quite work out what LIE stands for. The Type Checking | section of the Commentary suggests "LIE (Local Instance Environment?)". | Could someone out there tell me what it does actually stand for? | | Cheers, | | | Sean | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

What does LIE stand for?
by Sean Seefried 19 Aug '04

19 Aug '04

Hi all, I've been looking through the source code and the GHC commentary and I still can't quite work out what LIE stands for. The Type Checking section of the Commentary suggests "LIE (Local Instance Environment?)". Could someone out there tell me what it does actually stand for? Cheers, Sean

1 0

FW: Space usage
by Simon Peyton-Jones 18 Aug '04

18 Aug '04

| > When the GC discovers a selector function applied to an evaluated | > argument, it "evaluates" the selector on-the-fly by just swizzling | > pointers. It needs some co-operation from the compiler to make | > selector functions look obvious, but that isn't too difficult. | | So ghc doesn't do this (or something better)? I'm surprised | because it seems like a really basic and simple feature to me. I | implemented a toy FPL a few years ago and even my gc incorporated | this optimisation. It's a bit strange that this should have been | overlooked considering in all other respects ghc is far more | sophisticated than my efforts were :-) It does; see my reply below | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Simon Peyton-Jones | Sent: 17 August 2004 17:25 | To: Malcolm Wallace; glasgow-haskell-users(a)haskell.org | Subject: RE: Space usage | | | | You probably mean | | J. Sparud, "Fixing Some Space Leaks without a Garbage Collector", | FPCA'93. | | http://citeseer.ist.psu.edu/sparud93fixing.html | | Indeed. | | | as implemented in hbc. It is also possible to use Wadler's | | garbage-collector fix for this space leak, as implemented in nhc98. | | P Wadler, "Fixing a Space Leak with a Garbage Collector", SP&E | Sept 1987. | | | | When the GC discovers a selector function applied to an evaluated | | argument, it "evaluates" the selector on-the-fly by just swizzling | | pointers. It needs some co-operation from the compiler to make | | selector functions look obvious, but that isn't too difficult. | | GHC does this, but it does not always work. What starts as | let x = fst t in | let h = case x of { True -> 1; False -> 2 } in | ... | may become | let h = case t of { (x,_) -> case x of {True->1;False->2} } | ... | and now there is no selector thunk any more. So the selector stuff is | fragile to otherwise-valuable optimisations. And that's what's happening | in this case. A non-optimising compiler is fine. | | Simon | | Regards | -- | Adrian Hey | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: Space usage
by Simon Peyton-Jones 17 Aug '04

17 Aug '04

| You probably mean | J. Sparud, "Fixing Some Space Leaks without a Garbage Collector", FPCA'93. | http://citeseer.ist.psu.edu/sparud93fixing.html Indeed. | as implemented in hbc. It is also possible to use Wadler's | garbage-collector fix for this space leak, as implemented in nhc98. | P Wadler, "Fixing a Space Leak with a Garbage Collector", SP&E Sept 1987. | | When the GC discovers a selector function applied to an evaluated | argument, it "evaluates" the selector on-the-fly by just swizzling | pointers. It needs some co-operation from the compiler to make | selector functions look obvious, but that isn't too difficult. GHC does this, but it does not always work. What starts as let x = fst t in let h = case x of { True -> 1; False -> 2 } in ... may become let h = case t of { (x,_) -> case x of {True->1;False->2} } ... and now there is no selector thunk any more. So the selector stuff is fragile to otherwise-valuable optimisations. And that's what's happening in this case. A non-optimising compiler is fine. Simon

1 0

Re: Bug in GHC when compiling with -O ?
by MR K P SCHUPKE 17 Aug '04

17 Aug '04

You will have to give both the errors and the source code... I have done quite a bit with classes and GHC's constraint inferance is pretty good. The chances are you really do need to add some extra constraints... (by the way if you are working with heterogeneous collections, you may be interested in out paper, http://www.cwi.nl/~ralf/HList ) Keean.

1 0

Bug in GHC when compiling with -O ?
by Klaus Lüttich 17 Aug '04

17 Aug '04

Hello, we are working on a very large project called Hets (heterogenous tool set) where we encounterd two related errors in ghc, which disappear when we start over the compilation at that point where the compilation stopped due to one of that errors. We certainly use the current version 6.2.1 of GHC. We use in conjunction these command line switches for the compilation: --make -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -O where actually only some imported packages really need these switches: -fallow-overlapping-instances -fallow-undecidable-instances The tar-ball with the error enabled in the toplevel Makefile is available here: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… (4.2M) The errors also disappear when we compile the problematic modules separately. Cheers, Klaus The error messages we get when compiling: Compiling Common.Lib.Rel ( ./Common/Lib/Rel.hs, ./Common/Lib/Rel.o ) ./Common/Lib/Rel.hs:102: Could not unambiguously deduce (Show (a, a)) from the context (Show (Rel a), Show a, Ord a) arising from use of `show' at ./Common/Lib/Rel.hs:102 The choice of (overlapping) instance declaration depends on the instantiation of `a' Probable fix: Add (Show (a, a)) to the class or instance method `show' Or add an instance declaration for (Show (a, a)) In the first argument of `(.)', namely `show' In the definition of `show': show = show . (Common.Lib.Set.fromList . toList) In the definition for method `show' Compiling Common.PPUtils ( ./Common/PPUtils.hs, ./Common/PPUtils.o ) ./Common/PPUtils.hs:176: Could not unambiguously deduce (Show (a, b)) from the context (PrettyPrint a, PrettyPrint b) arising from the instance declaration at ./Common/PPUtils.hs:176 The choice of (overlapping) instance declaration depends on the instantiation of `a, b' Probable fix: Add (Show (a, b)) to the instance declaration superclass context Or add an instance declaration for (Show (a, b)) In the instance declaration for `PrettyPrint (a, b)' -- Klaus Lüttich Email: luettich(a)tzi.de FB 3 Phone: +49-421-218-7129 Uni Bremen

1 0

Announce: hs-plugins-0.9.6
by dons＠cse.unsw.edu.au 16 Aug '04

16 Aug '04

hs-plugins 0.9.6 has been released. hs-plugins is a dynamic loader and runtime compilation library for Haskell. This release features various stability and portability improvments over its predecessors, some extensions for better dynamically typed plugins, and an example of how to use plugins to implement a runtime-compiled printf, based on the 'eval' mechanism. You can find the code at: http://www.cse.unsw.edu.au/~dons/hs-plugins Cheers, Don

4 6

RE: Announce: hs-plugins-0.9.6
by MR K P SCHUPKE 16 Aug '04

16 Aug '04

>There is a portable System.Process library here: On that note, perhaps all signals on unix should be set to ignore, so if you are writing cross platform code you don't have to do special stuff with say sigPIPE for example Keean.

2 1

RE: Announce: hs-plugins-0.9.6
by Simon Marlow 16 Aug '04

16 Aug '04

On 16 August 2004 15:37, Carsten Schultz wrote: > Hi! > > On Mon, Aug 16, 2004 at 03:31:04PM +0100, Claus Reinke wrote: >> a cursory browse of the sources shows up things like "POpen" and >> "Posix", both no-nos, as far as portable ghc code is concerned (no >> longer supported in the default ghc for windows, AFAIK). it would be >> good if ghc-users would keep that in mind when writing portable >> Haskell code. > > Maybe someone should have a look at popen functionality in Python. > IMHO Python seems to have quite good libraries which work on Windows > and Unix. There is a portable System.Process library here: http://www.haskell.org/~simonmar/process/process.tar.gz Haddock docs here: http://www.haskell.org/~simonmar/process/System.Process.html This library is slated for inclusion in GHC 6.4. Cheers, Simon

1 0

RE: isEmptyChan, System.Posix.Signals
by Simon Marlow 16 Aug '04

16 Aug '04

On 16 August 2004 11:21, MR K P SCHUPKE wrote: > I thought NT and more recent was Posix compliant... Surely it should > support posix signals? Don't believe the hype. As I understand it, NT has a POSIX subsystem, which is entirely separate from the Win32 subsystem - you can't run a process which uses both APIs simultaneously. And the POSIX subsystem is *very* minimal, I doubt it has full support for signals. Cheers, Simon

1 0