- Glasgow-haskell-users

Existentials and newtype
by Arthur Baars 22 Nov '01

22 Nov '01

At glasgow-haskell-bugs(a)haskell.org I asked the following: > this works > > data Exists f = forall x . E ( f x) > > this doesn't work > > newtype Exists f = forall x . E ( f x) > > Hugs accepts both. > > It there a reason why existential quantification does not work with a > newtype, or is it just > a parser problem? This problem is clearly not a bug but a restriction imposed by the designers of GHC, as Keith Wansbrough pointed out to me: > >From the manual, section 7.12.3 "Restrictions": > > --8<-- > You can't use existential quantification for newtype declarations. So this is illegal: > newtype T = forall a. Ord a => MkT a > > Reason: a value of type T must be represented as a pair of a > dictionary for Ord t and a value of type t. That contradicts the idea > that newtype should have no concrete representation. You can get just > the same efficiency and effect by using data instead of newtype. If > there is no overloading involved, then there is more of a case for > allowing an existentially-quantified newtype, because the data because > the data version does carry an implementation cost, but single-field > existentially quantified constructors aren't much use. So the simple > restriction (no existential stuff on newtype) stands, unless there are > convincing reasons to change it. > --8<-- I perfectly understand why the use of class constraints in combination with newtype and existential quantification is illegal. In my opinion the restriction should only forbit this particular combination, instead of all uses of newtype with existentials. For me single-field existentially quantified constructors are quite useful: For example newtype Exists f = forall x . E (f x) data Object a = Object {value :: a , toString:: a -> String } data Thing a = Thing {val :: a , next :: a -> a, run :: a -> IO ()} -- Here I hide the type variables of Object and Thing using the type Exists: type EObject = Exists Object type EThing = Exists Thing without single-field existentially quantified constructors I would have to write: data EObject = forall a . EObject a (a -> String) data EThing = forall a . EThing a (a -> a) (a-> IO ()) or write the Exists type using data When using data I have to pay a (however small) run-time cost, that I would not have to pay when using a newtype. The other solution does not have this run-time cost, but it makes my code less readable: I have to invent new types and constructor names. I cannot use named fields. I cannot reuse polymorphic functions that work on Object on EObjects. Summarizing: without single-field existentially quantified constructors in newtypes either my code gets less readable or I have to pay a run-time price. Is it possible to relax the restriction on newtypes in combination with existentials? Cheers, Arthur

1 0

RE: Socket library ghc 5.02.1
by Simon Marlow 22 Nov '01

22 Nov '01

> Am 22. Nov 2001 um 16:22 MET schrieb Simon Marlow: > > I'm sad to say there was another bug in > SocketPrim.getSocketOption in > > 5.02.1. Please try the enclosed patch. > > How does this explain the two differing behaviours? > And why didn't it happen in a compiled version? Because the 'optlen' parameter to getsockopt was wrong (1 instead of sizeof(int)), which means that the other 3 bytes would be garbage. If the other 3 bytes happened to be zero, you probably wouldn't notice. Anyway, I've tested this with the latest sources and it seems to work, whereas I can repro the bug with 5.02.1 in GHCi. Cheers, Simon

1 0

RE: Socket library ghc 5.02.1
by Simon Marlow 22 Nov '01

22 Nov '01

> In local.glasgow-haskell-users, you wrote: > > It seems that the Socket library does still not work > > with ghc 5.02.1. > > [ghci clarification] > There, it crashes for me even on the 2nd invocation: > > connect(13, {sin_family=AF_INET, sin_port=htons(80), > sin_addr=inet_addr("137.226.194.33")}}, 16) = -1 EINPROGRESS > (Operation now in progress) > gettimeofday({1006436761, 219035}, NULL) = 0 > select(14, [], [13], NULL, {134, 217727}) = 1 (out [13], left > {134, 220000}) > getsockopt(13, SOL_SOCKET, SO_ERROR, [1835091456], [1]) = 0 > write(1, "*", 1) = 1 > > whereas on the first, succeeding call to 'connect' it says; > > select(14, [], [13], NULL, {134, 217727}) = 1 (out [13], left > {134, 210000}) > getsockopt(13, SOL_SOCKET, SO_ERROR, [0], [1]) = 0 I'm sad to say there was another bug in SocketPrim.getSocketOption in 5.02.1. Please try the enclosed patch. Cheers, Simon

2 1

RE: GHC parsers
by Simon Marlow 22 Nov '01

22 Nov '01

[ moved to glasgow-haskell-users(a)haskell.org ] > we would like to adapt a Haskell parser for whatever > purposes, and looked > for one in the ghc distribution. However, in ghc 5.02, we found two > happy-generated parsers, one in ghc/compiler/parser and one in > hslibs/hssource which both look similar, but seem to be > slightly different > (at least their version numbers are). Could someone tell me what the > differences are and which one we really ought to use? The parser in hslibs/hssource is designed to be portable (it's written in standard Haskell 98). GHC's parser, and in particular the lexer, by contrast uses several GHC extensions. Also, the hssource parser doesn't handle any GHC extensions to the Haskell syntax. If you're looking for a standalone Haskell parser, then hslibs/hssource is almost certainly the way to go. Cheers, Simon

1 0

RE: hdirect-0.18 comserv example
by Lehti, Patrick 22 Nov '01

22 Nov '01

I could figure out the problems mentioned earlier. The type library problem is easy fixed by switching on the SUPPORT_TYPELIBS option in the src/Makefile during the build of hdirect. Note that you cannot switch on this option in a first time build. The link error has something to do with cygwin, when I remove cygwin from my PATH, this error disappears. But then unfortunately no dll file is built at all, without any error message! So I am still waiting for a solution... Patrick -----Original Message----- From: Janna Khegai [mailto:janna@cs.chalmers.se] Sent: Montag, 12. November 2001 00:47 To: glasgow-haskell-users(a)haskell.org Cc: Patrick.Lehti(a)softwareag.com Subject: hdirect-0.18 comserv example I've tried to build the comserv example with hDirect-0.18 and ghc-5.02 under Windows ME. I've encountered the problems similar to ones mentioned earlier in: http://www.haskell.org/pipermail/glasgow-haskell-users/2001-October/000974.h tml <http://www.haskell.org/pipermail/glasgow-haskell-users/2001-October/000974. html> : >problems generating the type library: it is simply not created. and http://www.haskell.org/pipermail/glasgow-haskell-users/2001-October/000979.h tml <http://www.haskell.org/pipermail/glasgow-haskell-users/2001-October/000979. html> : > a problem linking the DLL, I always get this error message: > >/usr/lib/mingw/libmingw32.a(gccmain.o)(.text+0x88):gccmain.c: multiple >definition of `__main' >/usr/lib/libm.a(ds00023.o)(.text+0x0): first defined here If anybody already knows the cure to these problems, help me, please! thanks in advance, Janna Khegai

1 0

Re: Socket library ghc 5.02.1
by Sven Eric Panitz 22 Nov '01

22 Nov '01

From: Volker Stolz <stolz(a)hyperion.informatik.rwth-aachen.de> Cc: glasgow-haskell-users(a)haskell.org In local.glasgow-haskell-users, you wrote: >> main = >> do >> d <- connectTo "localhost" (PortNumber 80) >> hPutStr d "GET / HTTP/1.0\n\n" >> hFlush d >> c <- hGetContents d >> putStr c > > whereas on Linux I get the following error: > *** Exception: failed > Action: connect > Reason: Unknown error 142731264 Please run the program with 'strace', e.g. strace -o log ./a.out and post the log when it fails. Be aware that 'hGetContents' is broken on 5.02.1 if you use it extensively (the GC will close already-reused fds and cause your program to crash!), the patch was recently postet to -bugs by Simon Marlow and works. OTOH, this is not the bug you're seeing. As I just figured out, reported error above only occurs within ghci. Otherwise Sockets seem to work on ghc 5.02.1 for Linux. Sven Eric

1 0

hsc: Passing -1 as CString/Ptr a?
by Volker Stolz 22 Nov '01

22 Nov '01

Hi, I want to invoke the C-function 'dlsym', which has three possible options for a parameter of type (void*): - NULL - void* to a string, i.e. CString in Haskell - RTLD_NEXT = (void *)(-1) The first two ones are no problem, I can use a CString and 'nullPtr'. For the last one, I have the problem that in the "Next"-case I cannot write pack :: Flag -> CString pack Null = nullPtr pack Name str = str pack Next = #const RTLD_NEXT because there's no way to cast Int to a Ptr -- at least I didn't find any. Unluckily, the C-codes (void *)(-1) even gets expanded by hsc to the literal "4294967295" which can't be right either. So currently I'm facing two possible solutions: pack Next = nullPtr `plusPtr` 4294967295 (expanded from "... #const RTLD_NEXT") or pack Next = nullPtr `plusPtr` (-1) (which is not a good idea since it doesn't use the C-constant) "Ptr" is abstract so I cannot create this Ptr myself. Maybe the Ptr-module just lacks a 'minusOnePtr' similar to 'nullPtr'? -- Volker Stolz * vs(a)foldr.org * PGP + S/MIME

1 0

RE: Binary library
by Jan de Wit 22 Nov '01

22 Nov '01

> > Does Malcolm's Binary library exist for ghc? If not, is there > > a standard > > way (ie using Haskell that works on any compiler) to dump a data > > structure into a file that another program or part of the same program > > can then pick up and read (cf "serialize" in Java)? I'm > > reluctant to go > > with a solution that's compiler-specific. > > Using Show & Read is the only really portable way to do this, > unfortunately. [snip] Well, it's not really portable... Try the program at the end of this file, by first executing hugsMain in hugs, exiting and then running main in ghc or ghci, and you'll see: | Cons{hd='a',tl=(Cons{hd='b',tl=Nil})} | *** Exception: Prelude.read: no parse So, at least ghc and hugs disagree... My ghc version is 5.02 and my hugs is February 2000/2001 (both give the same output). Cheers, Jan de Wit ----8<---- module Test where data List a = Nil | Cons { hd :: a, tl :: List a } deriving (Show,Read,Eq) theList = Cons 'a' (Cons 'b' Nil) hugsMain = do writeFile "test.txt" (show theList) main main = do s <- readFile "test.txt" let theListFromFile = read s print theList print theListFromFile print $ theList == theListFromFile writeFile "test.txt" (show theList)

3 5

RE: Binary library
by Jan de Wit 21 Nov '01

21 Nov '01

> Can anyone spot the fault in the derived instance of Read produced > by DrIFT? > > Regards, > Malcolm The precedence of things printed or read after a label should IMO be lower than 10, probably even 0. In other words: calls to showsPrec/readsPrec 10 should be replaced by showsPrec/readsPrec 0 in the code below. I haven't checked this though, however I've written a generic version of read and show using Generic Haskell which omits the superfluous parentheses by using precedence 0. Cheers, Jan > > > data List a = Nil | Cons { hd :: a, tl :: List a } > > > > {-* Generated by DrIFT-v1.0 : Look, but Don't Touch. *-} > > instance (Show a) => Show (List a) where > > showsPrec d (Nil) = showString "Nil" > > showsPrec d (Cons aa ab) = showParen (d >= 10) > > (showString "Cons" . showChar '{' . > > showString "hd". showChar '='. showsPrec 10 aa. showChar',' . > > showString "tl" . showChar '=' . showsPrec 10 ab > > . showChar '}') > > > > instance (Read a) => Read (List a) where > > readsPrec d input = > > (\ inp -> [((Nil) , rest) | ("Nil" , rest) <- lex inp]) input > > ++ > > readParen (d > 9) > > (\ inp -> > > [((Cons aa ab) , rest) | ("Cons" , inp) <- lex inp , > > ("{" , inp) <- lex inp , ("hd" , inp) <- lex inp , > > ("=" , inp) <- lex inp , (aa , inp) <- readsPrec 10 inp , > > ("," , inp) <- lex inp , ("tl" , inp) <- lex inp , > > ("=" , inp) <- lex inp , (ab , inp) <- readsPrec 10 inp , > > ("}" , rest) <- lex inp]) > > input

1 0

[Linux-basic-compiling]GHC-3.02 build on GHC-2.10
by Rafael Martínez Torres 21 Nov '01

21 Nov '01

I apologize if this is not the correct moment-place to deal with this old version. I'm trying to compile the GHC-3.02 version using ghc-2.10 binaries, happy-1.6 binaries on a i386-unknown-linux. In the future I would like to hack with it. I had to modify the file ghc/run_time/main/Signals.lc because it used a non-existing structure, named "struct sigcontext_struct" instead of "struct sigcontext". Main problem arise when linking. If I'm not wrong, the output from Haskell code are "C" files. They are compiled and linked by the C compiler. At the final linking step, the linker shows me unresolved references to symbols: "_fxstat","_lxstat" or "__setmjmp". After inspecting the code, on directory ghc/lib/cbits/openFile.c [...], I realized this belong to C functions fstat(),lstat() and setjmp() . These libraries are implicitly included by libc, I think. Any C-program links without problem,when compiled by invoking explictly "gcc", but I seems the ghc-2.10 compiler not to find the libc (and so his sub-components ). Does any body suggest me what I can do to perform a good compiling ? What parameters should I modify and where ? In directory mk ? Where lasgow-haskell-users(a)haskell.org else ?

1 0