- Glasgow-haskell-users

Re: GHC and MPTCs
by MR K P SCHUPKE 25 Aug '04

25 Aug '04

Try type annotations: new_point (s::s) t b : interleave (next_state s::s) bs (t:ts) Keean.

2 1

RE: Is it possible to load bindings into ghci
by Simon Marlow 25 Aug '04

25 Aug '04

On 25 August 2004 15:06, Andreas Marth wrote: > Later Tomasz Z. >> How about this: >> >>> def . readFile >> :. C.hs >> >> I guess I got there first ;) > > That works great! And you can even put the ":def . readFile" in the > .ghci File! > So now I start ghci with "ghci MyFile" wait until it's finished and do > ":. all_the_stuff_I_need_in_a_file" > and every thing is fine! Yes, that's a neat trick. I'm annoyed I didn't think of it, especially since I'm the one who invented :def. Duh :-) Cheers, Simon

2 1

RE: Is it possible to load bindings into ghci
by Simon Marlow 25 Aug '04

25 Aug '04

On 24 August 2004 12:47, Andreas Marth wrote: > At the moment it happens that I use an unfinished program with ghci. > And each time I start GHCi, I have to introduce the same bindings aka > 'cont <- readFile "myFile"' ... > Is there a way to define them once in a File and then point GHCi to > it? (I need somme of the functions in the unfinished program so it has > to be after reading the program file.) Like the '.' command in /bin/sh? Yes, we ought to have something like that. I'll get around to it at some point, unless anyone gets there first. Cheers, Simon

3 4

RE: Extra parse stage...
by Simon Marlow 25 Aug '04

25 Aug '04

On 25 August 2004 12:28, MR K P SCHUPKE wrote: > I wish to add some extended syntax to type definitions, > assuming I modify the parser files and associated datatypes > to carry the extra information, is there a convenient place > to insert a pre-parse (before type-checking) to convert the > syntax extensions to regular haskell? GHC's strategy is to not do any translation before typechecking, so that we can generate good error messages. Nevertheless, it's certainly possible to do what you're suggesting: just insert an HsSyn->HsSyn pass after parsing (I imagine). Various things might complicate matters, such as needing to refer to fixed entities in other modules in the translation. Cheers, Simon

1 0

GHC and MPTCs
by Ketil Malde 25 Aug '04

25 Aug '04

Hi, I recently tried to do the following code: class VertexState s v where new_point :: s -> v -> v -> v next_state :: s -> s -- interleave :: (VertexState s a) => s -> [a] -> [a] -> [a] interleave s (t:ts) (b:bs) = new_point s t b : interleave (next_state s) bs (t:ts) interleave _ [] [b] = [] Firstly, GHC doesn't deal all too gracefully with this if the type signature is uncommented, it tells me: Could not deduce (VertexState s v) from the context (VertexState s a) arising from use of `next_state' at Grid.lhs:25 Probable fix: Add (VertexState s v) to the type signature(s) for `interleave' Unfortunately, doing the probable fix just results in a new request for (VertexState s v1), and so on. I suppose the real problem is that GHC can't decide from next_state that it is supposed to use exactly this instance of VertexState, is there a good way to do that without adding an explicit dummy parameter of type v? (I really would like to be able to have instances with the same s but different v's, which I think adding functional deps would make difficult.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Bug in compiling large projects ?
by Klaus Lüttich 25 Aug '04

25 Aug '04

Hello, I have send a message to these lists a weak ago with almost the same topic, but I have now additional observations: The problem is not related to option -O in GHC 6.2.1 ! We use in conjunction these command line switches for the compilation: --make -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances and get this error message, when we try to compile the complete project: 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' When we issue the same ghc call again, Common/Lib/Rel is compiled without errors. Well, the needed tar-ball (4.2M) to reproduce the error is downloadable at http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… Cheers, Klaus -- Klaus Lüttich Email: luettich(a)tzi.de FB 3 Phone: +49-421-218-7129 Uni Bremen

2 2

Extra parse stage...
by MR K P SCHUPKE 25 Aug '04

25 Aug '04

I wish to add some extended syntax to type definitions, assuming I modify the parser files and associated datatypes to carry the extra information, is there a convenient place to insert a pre-parse (before type-checking) to convert the syntax extensions to regular haskell? Keean.

1 0

profiling in 6-2-2-cvs
by Serge D. Mechveliani 24 Aug '04

24 Aug '04

I have tested the profiling for the time cost -auto-all (-O) in CVS ghc-6-2-2-branch of about July 20. It looks correct. The problem was to find out that the names ..HSdm.a, ..HSdm_p.a are needed in the Makefile segment ar -qc $(e)/libHSdm.a $(wildcard $(e)/*.p_o) ar -qc $(e)/libHSdm_p.a $(wildcard $(e)/*.p_o) ar -s $(e)/libHSdm_p.a and ..HSdm.p_a not needed. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Is it possible to load bindings into ghci
by Andreas Marth 24 Aug '04

24 Aug '04

Hi everybody! At the moment it happens that I use an unfinished program with ghci. And each time I start GHCi, I have to introduce the same bindings aka 'cont <- readFile "myFile"' ... Is there a way to define them once in a File and then point GHCi to it? (I need somme of the functions in the unfinished program so it has to be after reading the program file.) Thanks, Andreas

1 0

RE: overzealous defaulting?
by Simon Marlow 24 Aug '04

24 Aug '04

There's some documentation on this in the User's Guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/x1075.html#GHCI- DEFAULTING Cheers, Simon On 23 August 2004 17:15, Simon Peyton-Jones wrote: > The binding > let t = printQ > falls under the monomorphism restriction. The Haskell Report would > not default (Show a), so you might think you'd get an "ambiguous type > variable" error. But it's so annoying to get this error for > ghci> show [] > that GHCi is a bit more eager about defaulting ambiguous types: it'll > apply defaulting if all the constrained classes are standard, and at > least one of them is numeric *or* is Show, Eq or Ord. > The *or* part is the non-standard bit. > > Admittedly, I'm not sure this is documented. > > Simon > >> -----Original Message----- >> From: glasgow-haskell-users-bounces(a)haskell.org >> [mailto:glasgow-haskell-users- bounces(a)haskell.org] On Behalf Of >> Abraham Egnor >> Sent: 23 August 2004 16:02 >> To: glasgow-haskell-users(a)haskell.org >> Subject: overzealous defaulting? >> >> I'm not sure if this is an actual bug, as opposed to an odd instance >> of defaulting: >> >> *GUI.Parser> let printQ q = runQ q >>= print >> *GUI.Parser> :t printQ >> printQ :: forall a. (Show a) => Q a -> IO () >> *GUI.Parser> let p = printQ >> *GUI.Parser> :t p >> p :: Q Integer -> IO () >> >> ...but I'm not sure when that would ever be the correct behavior. >> >> Abe >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2