May 2007 - Haskell-Cafe

More mystery with existentials and fundeps
by Matthew Sackman 14 May '07

14 May '07

Hi, > {-# OPTIONS_GHC -fglasgow-exts #-} > > class F a b | b -> a where > > data G :: * -> * where > GC :: (F a b) => a -> G b > > foo :: (F a b) => G b -> a > foo g = case g of > (GC a) -> a I may be being dumb, but I think this should work. Any value of G using the GC constructor will be able to define a from G b given F a b due to the functional dependency. In the above 'case' statement version I get: Couldn't match expected type `a' (a rigid variable) against inferred type `a1' (a rigid variable) `a' is bound by the type signature for `foo' at Test.lhs:10:11 `a1' is bound by the pattern for `GC' at Test.lhs:12:12-15 In the expression: a In a case alternative: (GC a) -> a In the expression: case g of (GC a) -> a > foo2 :: (F a b) => G b -> a > foo2 g = let (GC a) = g in a And this 'let' statement version explodes with: My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors. In the binding group for (GC a) In a pattern binding: (GC a) = g In the expression: let (GC a) = g in a In the definition of `foo2': foo2 g = let (GC a) = g in a So is this a missing feature of GHC or am I (more likely) utterly mistaken about what should be possible here? Many thanks, Matthew

1 1

Disadvantages of de Bruijn indicies?
by Neil Mitchell 14 May '07

14 May '07

Hi, de Bruijn indicies look quite nice, and seem to eliminate a lot of complexity when dealing with free variables: http://en.wikipedia.org/wiki/De_Bruijn_index So I was wondering, are they suitable for use in a compiler? If so, what are their disadvantages/advantages? Is there any particular reason that GHC (as an example) doesn't use them in its Core? I'm trying to decide if I should use them in my compilers data type - and would like some recommendations before I start. Thanks Neil

7 9

hash of a lazy bytestring?
by David Roundy 13 May '07

13 May '07

I was just contemplating hashes, and it occurred to me that it would be nice to be able to compute the hash of a lazily constructed bytestring and lazily consume its output without requiring the whole string to ever be in memory. Or in general, it'd be nice to be able to perform two simultaneous consumptions of a lazy list without requiring that the entire list be stored. Another example would be computing the length of an ordinary list: do l <- readFile "foo" let len = length l writeFile "bar" l putStrLn $ "Length is " ++ show l It would be nice if one could write length such that the above function doesn't require the entire file be stored in memory. Are there any approaches that would make this possible? The only approach I can imagine would involve something like weak pointers and finalizers. It seems like it'd be a useful paradigm, if it's possible. Basically to be able to write a lazy consumer that doesn't hold onto its input, but instead is computed as the garbage collector frees the input. Something like: length' :: [a] -> Integer length' !xs = l' 0 `safeInterleave` xs where l' n [] = n l' !n (y:ys) = l' (n+1) `safeInterleave` ys safeInterleave :: (a -> b) -> a -> b safeInterleave f !x = -- create weak reference to x, associate finalizer, -- so that if x is GCed, then we'll immediately -- evaluate f x before we lose the value of x. Is this possible? Would it be reasonable? I imagine we'd run into trouble with laziness keeping safeInterleave from being called, with the result that we'd hang onto x even though the safeInterleave would have hoped to allow x to be GCed. -- David Roundy http://www.darcs.net

4 4

Compilling GHC on Vista
by Monique Monteiro 13 May '07

13 May '07

Hi all, I'm trying to compile GHC on Windows Vista, but I encountered the following error when running ./configure --host=i386-unknown-mingw32 --with-gcc=c:/MinGW/bin/gcc: configure: error: C compiler cannot create executables See `config.log' for more details. ./configure: line 3404: cannot create temp file for here document: No such file or directory ./configure: line 3441: cannot create temp file for here document: No such file or directory Has anyone any idea about what may be happening? Thanks in advance, Monique -- __________________________________________________________ Monique Monteiro, MSc MCP .NET Framework 2.0 / SCJP / IBM OOAD Project Manager Recife Microsoft Innovation Center +55 81 34198137 http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx monique(a)qualiti.com.br MSN: monique_louise(a)msn.com

5 23

ambiguous type variables at MPTC
by Nicolas Frisby 13 May '07

13 May '07

This is a question about some interesting behaviors in GHC's typechecker regarding MPTCs. The brief code is at the bottom of the message. By the way, the types can be inferred but not declared without the forall and ascription in the where clause. f1 below is illegal because we don't know what type the result of read should be: it's type is ambigious. Why isn't f2 illegal as well? If C had a functional dependency of a -> b, then I could understand accepting the type. However, without the functional dependency, b might not necessarily be determined from a. i) The above reasoning encroaches on the magic of TypeCast, which effectively allows local functional dependencies to be declared at the instance-level. Because of this, the typeclass mechanism might effectively have a means of determining b from a without the class being explicitly decorated with the functional dependency. ii) Type errors where b really isn't determined by a are caught by the typechecker wherever f2's arguments are instantiated (at some usage site). This is convenient at times (it admits the uncertainty of the "might not necessarily") and annoying at others (debugging): perhaps there's a ghc switch to disallow this? If f2 is legal, why if f3 illegal? For some usage site of f3, the constraint C String b might allow b to be resolved given whatever instances of C are in effect. Is there a motivation for these behaviors? Are these sorts of cases discussed in the CHR/FD paper that motivated the coverage condition (which I have yet to read)? If ATs or GADTs would handle these situations differently, why so? Should FDs also handle these situations differently? Thanks for your time. class C a b where method :: a -> b {- illegal due to ambiguous variable f1 :: forall a . (Read a) => String -> () f1 x = () where _ = read x :: a -} -- legal, despite the lack of an FD (a -> b) on C f2 :: forall a b . (C a b) => a -> () f2 x = () where _ = method x :: b {- illegal due to none of the forall'd variables being "reachable" from the type proper f3 :: forall b . (C String b) => String -> () f3 x = () where _ = method x :: b -}

2 1

Re: [Haskell-cafe] GHC Hangs
by Josiah Manson 12 May '07

12 May '07

When the intermediate files are removed, GHC still hangs. In fact, the intermediate files do not seem to be corrupt in any way, as the only way to get a working executable is to run GHC more than once. First to produce the intermediate files, then to link them into an executable. On 5/7/07, Cale Gibbard <cgibbard(a)gmail.com> wrote: > > On 07/05/07, Josiah Manson <josiahmanson(a)gmail.com> wrote: > > There is still a problem when I use the version you linked to. At first > I > > was hopeful, because the first time I tried compiling bisect.hs it > worked. > > All subsequent attempts, however, have failed. > > Maybe try getting rid of all the intermediate (*.hi *.o) files created > when compiling it? Not that this is necessarily a permanent > solution... > > - Cale >

3 4

Ignore
by Ian Lynagh 12 May '07

12 May '07

Sorry, please ignore.

1 0

"Recent content is available under a simple permissive license"
by Robin Green 11 May '07

11 May '07

The Haskell wiki[1] says "Recent content is available under a simple permissive license". But this is unilluminating - recent? how recent, exactly? - and will become increasingly understated as time goes by. Wouldn't it be slightly more helpful to say "Content added after " ... YYYY/MM/DD ... " is available under a simple permissive license"? -- Robin [1] http://www.haskell.org/haskellwiki

3 2

Re: [Haskell] ANNOUNCE: Harpy -- run-time code generation library
by Justin Bailey 11 May '07

11 May '07

On 5/11/07, Dirk Kleeblatt <klee(a)cs.tu-berlin.de> wrote: > > Hi everybody, > > we're pleased to announce the first release of Harpy. > > Harpy is a library for run-time code generation of x86 machine code. > It provides not only a low level interface to code generation > operations, but also a convenient domain specific language for machine > code fragments, a collection of code generation combinators and a > disassembler. Impressive. Does the library require that an assembler (e.g. MASM) be installed? Justin

3 2

Re: [Haskell] ANNOUNCE: Harpy -- run-time code generation library
by Duncan Coutts 11 May '07

11 May '07

On Fri, 2007-05-11 at 10:04 +0200, Dirk Kleeblatt wrote: > Hi everybody, > > we're pleased to announce the first release of Harpy. > > Harpy is a library for run-time code generation of x86 machine code. > It provides not only a low level interface to code generation > operations, but also a convenient domain specific language for machine > code fragments, a collection of code generation combinators and a > disassembler. > > Harpy homepage: > http://uebb.cs.tu-berlin.de/harpy/ This looks cool. I was wondering what the need for ensureBufferSize is? Could this by automated? I would have thought that we could just check this when writing out a single instruction. Duncan

2 1