- Haskell-Cafe - Haskell.org

problem with implicit parameter
by Eric 16 May '07

16 May '07

Hi there, I've written the following program putchr = putChar ?d main = do { c <- getChar ; putchr with ?d = c} which I try to compile with ghc --make -fimplicit-params myprogram However I keep getting the following error: myprogram.hs:5:17: parse error on input `=' What's wrong? E.

3 2

Re: ANNOUNCE: Harpy -- run-time code generation library
by apfelmus 16 May '07

16 May '07

[Relocated to haskell-cafe] Dirk Kleeblatt wrote: > apfelmus wrote: >> Note that even currently, your operations cannot be strict in the >> address a label refers to because this may be determined later than the >> first use of the label. In other words, your example code >> >> fac = do > [...] >> (1) jmp loopTest > [...] >> (2) loopTest @@ cmp ecx (0 :: Word32) > [...] >> already shows that the function jmp that generates a jmp-instruction may >> not be strict in the position it jumps to as the address behind loopTest >> is only known later at line (2). > > When generating code for (1), the label loopTest is used as an index > into a map, to see whether there's a code position associated with it. > If it is, the code position is used to compute the jump offset for the > jmp instruction, if not (as in this example), a dummy value is placed in > the code buffer, and Harpy remembers this position to be patched later > on. At (2), the label is defined, and this leads to patching all > instructions that have been emitted before this definition. > > So, yes, the code position is only used after the definition of the > label. But the "look up in a map"-part makes the jmp operation strict in > the label parameter. Ah, I slowly get what you mean. In short, the point is that you're reinventing lazy evaluation because you're writing directly to a memory buffer and writing a raw _|_ is impossible. So, you invent a scheme to delay the evaluation of the _|_ until they are defined. With raw writing, we indeed have the strictness writeByte buf _|_ = _|_ which implies jmp _|_ = _|_ I thought that you'd simply store the instructions in a list/monoid like the Builder-Monoid from Data.Binary with the effect that jmp _|_ /= _|_ as monadic action although it stores _|_ as instruction. Lazy evaluation then takes care of filling the _|_-instructions with content in times of need. Here's an illustration with a fictional robodog toy assembly language import Control.Monad.RWS type Address = Int data Dogcode = Bark | Bite | Jump Address data CodeGen a = RWS () [Dogcode] Address a emitDogcode :: Dogcode -> CodeGen Address emitDogcode c = x <- get tell c put (x+1) return x jump :: Label -> CodeGen Address jump = emitDogcode . Jump bark, bite :: CodeGen Address bark = emitDogcode Bark bite = emitDogcode Bite generateDogCode :: CodeGen a -> CodeBuffer generateDogCode c = let (_,instructionCount, code) = runRWST c () 0 in ... whatever to do with a list of instructions ... Now, you magically get recursive do-notation without lifting a finger because RWS is already an instance of MonadFix. For example, the following works out of the box pluto :: CodeGen Address pluto = mdo bark jump loop bite loop <- bark bark jump loop (The return value of type Address encapsulated in the monad is the line number of the last instruction of pluto.) If you really want to directly write to a memory buffer, I think that you can still use lazy evaluation to fill in the _|_ by emitting a "jump PATCHME" dummy instruction and build a stack (f.i. of type [Address]) of addresses. The stack takes the role of the map you currently use, I think that a stack is enough. The addresses therein may well be _|_. After having written all instructions into the buffer, all the _|_ are resolved and you can patch the "PATCHME"s in a second pass over the buffer. However, because of omnipresent lazy evaluation, it is unclear whether "directly" writing to a buffer instead of first building a monoid does give a speed/space advantage. So, your current approach may well be slower than a naïve "first (difference) list, then raw memory" approach. > We could omit the map, and just remember where to patch the code, but > then we'd need to call explicitly some function after code generation > that does the patching. We had implemented this, but found the current > solution easier to use, since backpatching is completely automatic and > hidden from the user. Huh, I thought that runCodeGen would do an additional backpatch pass as transparently? >> I also think that having liftIO in the CodeGen-monad is plain wrong. I >> mean, CodeGen is a monad that generates code without any execution >> taking place. The execution part is already handled by runCodeGen. >> Having liftIO means that arbitrary Haskell programs can be intertwined >> with assembly generation and I doubt that you want that. > > Feel free to doubt, but this is exactly what we want. :-) > > Also, note that runCodeGen runs the code _generation_, executing the > generated code is done _within_ the CodeGen monad via the functions > generated by callDecl (or the predefined functions in the Harpy.Call > module). This is even more intertwined, but intentional. Huh? That means that code gets executed during it's own generation? But why do you mix separate concerns? I don't see what use this is besides being an opportunity to mess up. > Of course, again a different design is possible, making runCodeGen > return a binary code object, that can be called from the IO monad. But > then, the user has to care about releasing code buffers, and not to have > unevaluated closures having code pointers to already released run-time > generated code. Huh, why does the user have to care? Shouldn't wrapping the raw memory block into a Foreign.ForeignPtr do the job? Regards, apfelmus

2 2

Type class help please
by Adrian Hey 16 May '07

16 May '07

Hello, Here's a simple module I'm playing about with.. {-# OPTIONS_GHC -fglasgow-exts #-} module Test(GT(..)) where -- GT class -- class Ord key => GT map key | map -> key where assocsAscending :: map a -> [(key,a)] -- Just 1 of many methods -- Instances of GT are instances of Eq -- instance (GT map key, Eq a) => Eq (map a) where map1 == map2 = assocsAscending map1 == assocsAscending map2 When I compile it I get this error.. Test.hs:9:0: Variable occurs more often in a constraint than in the instance head in the constraint: GT map key (Use -fallow-undecidable-instances to permit this) In the instance declaration for `Eq (map a)' But I can't see any problem here. If map and key are collectively instances of GT, and the fundep in GT fixes the type of key if type of map is known, and GT class has Ord constraint on key (and IIRC Ord class has an Eq constraint so key is a known instance of Eq), then why is this undecidable? Anyway, if I compile with -fallow-undecidable-instances I get this error instead.. Test.hs:10:16: Overlapping instances for Eq [(key, a)] arising from use of `==' at Test.hs:10:16-59 Matching instances: instance (Eq a) => Eq [a] -- Defined in GHC.Base instance (GT map key, Eq a) => Eq (map a) -- Defined at Test.hs:9:0 In the expression: (assocsAscending map1) == (assocsAscending map2) In the definition of `==': == map1 map2 = (assocsAscending map1) == (assocsAscending map2) In the definition for method `==' .. but I don't understand what that means (or to be more precise, what it seems to be saying makes no sense to me, so it's probably saying something else :-) How can my new instance overlap with the old (ghc) instance unless [] is also an instance of GT for some key type (which it isn't). Could someone explain? If I try making key a type arg of map (with no -fallow-undecidable-instances ).. {-# OPTIONS_GHC -fglasgow-exts #-} module Test(GT(..)) where -- GT class -- class Ord key => GT map key | map -> key where assocsAscending :: map key a -> [(key,a)] -- key is type arg of map -- Instances of GT are instances of Eq -- instance (GT map key, Eq a) => Eq (map key a) where map1 == map2 = assocsAscending map1 == assocsAscending map2 .. then I don't get the first error "Variable occurs more often in a constraint than in the instance head". But I still get the second ("Overlapping instances.."). But I don't really want to do this anyway as it as AFAICS it defeats the object of using the fundep in GT class. I also don't really understand why this second form should be decidable (presumably), whereas the first isn't. What extra information does the second provide that isn't already provided by the fundep in the first? If I also use the -fallow-overlapping-instances flag then both forms of this module compile, but with the warning.. Warning: orphan instances: instance [overlap ok] base:GHC.Base.Eq [.] = $f1 I'd be grateful if someone could take the time to explain what's going on here and (if possible) what I can or should do to get this code to compile (preferably without using undecidable or overlapping anything). Thanks -- Adrian Hey

2 2

Higher order types via the Curry-Howard correspondence
by Gaal Yahas 15 May '07

15 May '07

What do higher-order types like lists mean when viewed through the Curry-Howard correspondence? I've been wondering about this for a while. The tutorials ask me to consider id :: forall a. a -> a (.) :: forall a b c. (b -> c) -> (a -> b) -> (a -> c) These represent theorems in a logical calculus, with the variables a, b, c denoting propositions. In the case of the composition function, the proposition (a -> c) may be deduced if (b -> c) and (a -> b) obtain, and so on. (I've obviously skimmed some details.) We know the function e :: a -> b diverges because there is no way to deduce b from a with no other premises; the only value that satisfies this is bottom -- and so on. But what does the following mean? map :: (a -> b) -> [a] -> [b] Since the empty list inhabits the type [b], this theorem is trivially a tautology, so let's work around and demand a non-trivial proof by using streams instead: data Stream a = SHead a (Stream a) sMap :: (a -> b) -> Stream a -> Stream b What is the object "Stream a" in logic? What inference rules may be applied to it? How is "data Stream" introduced, and what about variant constructors? -- Gaal Yahas <gaal(a)forum2.org> http://gaal.livejournal.com/

9 14

openBinaryFile
by Eric 15 May '07

15 May '07

Hello all, Does anyone have some sample code for reading and writing to binary files? E.

2 1

readline crashes in Emacs buffer on Windows
by Gleb Alexeyev 15 May '07

15 May '07

Hello Cafe! I asked about this problem on IRC channel but with little luck. The problem boils down to the following: readline crashes on any input if the calling program runs in the Emacs buffer. To reproduce this bug, load the code below into ghci using haskell-mode and run main. >import System.Console.Readline > >main = do readline "prompt" > putStrLn "You cannot see this, because I've crashed. Amen" I'm running Windows 2003 Server, GHC-6.6, Emacs 22.0.50.1.

1 0

Problem with finalizers
by Ivan Tomac 15 May '07

15 May '07

Why does the finalizer in the following code never get called unless I explicitly call finalizeForeignPtr fptr? Even adding System.Mem.performGC made no difference. The code was compiled with ghc --make -fffi -fvia-c Test.hs Ivan -------------------- Test.hs ------------------------ module Main where import Foreign.Ptr import Foreign.ForeignPtr import Foreign.Marshal.Utils import System.Mem foreign import ccall safe "ctest.h &ctest" ctestPtr :: FunPtr (Ptr Int -> IO ()) test :: Int -> IO () test i = with i test' where test' ptr = do fptr <- newForeignPtr ctestPtr ptr putStrLn "test" -- finalizeForeignPtr fptr main = do putStrLn "before test..." test 33 putStrLn "after test..." performGC --------------------- ctest.h ---------------------- #include <stdio.h> static inline void ctest( int *i ) { printf( "finalizer called with: %d\n", *i ); }

3 5

Code layout in Emacs' haskell-mode
by Christopher L Conway 15 May '07

15 May '07

I am new to Haskell---and also to languages with the off-side rule--and working my way through Hal Daume's tutorial. I'm a little confused by the support for code layout in Emacs' haskell-mode. Is it buggy, or am I doing something wrong. For example, here's the "Hello, world" example from the tutorial, with the indentation induced by pounding Tab in haskell-mode. test.hs: module Test where import IO main = do putStrLn "Hello, world" Prelude> :l test [1 of 1] Compiling Test ( test.hs, interpreted ) test.hs:12:0: parse error on input `main' In emacs, every line but the one with "where" reports "Sole indentation". With "where", I have the option of having it flush left or indented four spaces; "import" wants to be two spaces in from "where". Moving where doesn't change the error. But if I manually move import flush left (which is the way it's shown in the tutorial, BTW): module Test where import IO main = do putStrLn "Hello, world" Prelude> :l test [1 of 1] Compiling Test ( test.hs, interpreted ) Ok, modules loaded: Test. I have a similar problem with the layout of if-then-else... num.hs: module Num where import IO main = do putStrLn "Enter a number: " inp <- getLine let n = read inp if n == 0 then putStrLn "Zero" else putStrLn "NotZero" Prelude> :l num [1 of 1] Compiling Num ( num.hs, interpreted ) num.hs:11:2: parse error (possibly incorrect indentation) Again, if I hit tab on the "then" or "else" lines, emacs reports "Sole indentation". But if I manually change the indentation, it works. module Num where import IO main = do putStrLn "Enter a number: " inp <- getLine let n = read inp if n == 0 then putStrLn "Zero" else putStrLn "NotZero" Prelude> :l num [1 of 1] Compiling Num ( num.hs, interpreted ) Ok, modules loaded: Num. This is particularly weird because if-then-else doesn't always act this way: exp.hs: module Exp where my_exponent a n = if n == 0 then 1 else a * my_exponent a (n-1) Prelude> :l exp [1 of 1] Compiling Exp ( exp.hs, interpreted ) Ok, modules loaded: Exp. I suppose this might have something to do with the do-notation... Does haskell-mode support code layout? Are there conventions I need to know about to make it behave properly? I have haskell-mode version 2.1-1 installed from the Ubuntu feisty repository. Thanks, Chris

5 5

instance monad problem
by Veer Singh 14 May '07

14 May '07

Hello, I am trying to learn haskell , but i am struggling with types , its been around 7 days , it will be very kind if some explain it why this error , i think this is the only stumbling block . I am looking for the comparison on why similar code works , while other code not . I get this error on ghci : {- `a' is not applied to enough type arguments Expected kind `*', but `a' has kind `* -> *' In the type `SS a' In the type `(Monad a) => {Monad (SS a)}' In the instance declaration for `Monad (SS a)' -} Here is the very small code with comments: data SS a = SS a Int data Maybe1 a = Nothing1 | Just1 a instance Monad Maybe1 where (Just1 x) >>= f = f x --^^ this loads fine in ghci -- where as this instance (Monad a)=> Monad (SS a) where (SS x y) >>= f = f (x y) --^^ does not work , so whats the difference , both have type parameters -- something similar works like this : instance (Eq a)=>Eq (SS a) where (SS x y) == (SS b c) = (y == c) && (x == b) Thanks

3 2

Re: [Haskell-cafe] Limits of deduction
by Matthew Brecknell 14 May '07

14 May '07

Roberto Zunino: > Yes, you are right, I didn't want to involve type classes and assumed > 3::Int. A better example would be: > > polyf :: Int -> a -> Int > polyf x y = if x==0 then 0 > else if x==1 then polyf (x-1) (\z->z) > else polyf (x-2) () > > Here, passing both () and (\z->z) _does_ make inference fail. Alternatively, type inference succeeds in rejecting an illegal program [1,2]. :-) So I think we need to be a little more precise about exactly what is undecideable in this example. Yes, the explicit type signature you've given is valid, and the Hindley-Milner type inference algorithm is not able to assign that type without an explicit signature. But that doesn't make Hindley-Milner type inference undecideable. On the contrary, Hindley-Milner type inference is deliberately designed to be decideable. To achieve that, it assumes monomorphic types in certain identifiable contexts, and therefore rejects some functions for which valid types exist. So I think the point you were making is that the problem of inferring the types of all functions for which valid types exist is, in general, undecideable. Hindley-Milner inference ensures decideability by choosing a somewhat less general (but still useful) problem. For what it's worth (not much), it might be possible to invent a decideable type inference which could infer types for a slightly larger set of functions (including polyf), by automatically generalising the types of arguments which are not inspected. Of course, doing so would presuppose the decideability of the subproblem of identifying unused arguments, and achieving that would undoubtedly require certain restrictions on the subproblem definition, analogous to the ones employed by Hindley-Milner. [1] http://haskell.org/onlinereport/decls.html#sect4.1.4 [2] http://haskell.org/onlinereport/decls.html#sect4.5

1 0