August 2004 - Glasgow-haskell-users

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

RE: overzealous defaulting?
by Simon Peyton-Jones 24 Aug '04

24 Aug '04

| I feel that it must be somewhat related to this behaviour: | | Prelude> :t show . read | show . read :: String -> String | Prelude> (show . read) " 13213 " | "13213" | Prelude> (show . read) " 0x10000 " | "65536" | Prelude> (show . read) " 10000.0 " | "*** Exception: Prelude.read: no parse | | For some reason GHC defaults to Integer, even when monomorphism | restriction doesn't come into play. This is all quite reasonable. The defaulting rule says precisely what should happen. When there is an ambiguous constraint, (Show a, Read a) in this case, the defaulting rules say to try Integer and then Int (unless you have a default declaration). In this case Integer works. | Hugs chooses this funny, but IMHO more correct, type: | | Prelude> :t show . read | show . read :: (Read a, Show a) => [Char] -> [Char] It's no more correct, because it's ambiguous. Every call to (show . read) will give rise to an ambiguous constraint, which will be resolved in the same way. GHC just does it a little earlier. Simon

2 1

profiling in 6.2.2-pre
by Serge D. Mechveliani 24 Aug '04

24 Aug '04

Please, could you help me to arrange profiling with cvs ghc-6-2-2 ? Without profiling, the Makefile contains ------------------------------------------------------------- HCFlags = $(language) -i$(idirs) -odir $(e) -hidir $(e) \ -ddump-hi-diffs \ +RTS $(space) -RTS $(extraHCOpts) extraHCOpts = pack = Package {name = "\"dm\"", \ import_dirs = ["\"$(e)\""], \ source_dirs = [], \ library_dirs = ["\"$(e)\""], \ hs_libraries = ["\"HSdm\""], \ extra_libraries = [], \ include_dirs = [], \ c_includes = [], \ package_deps = [\"data\"], \ extra_ghc_opts = [$(extraPackageOpts)], \ extra_cc_opts = [], \ extra_ld_opts = [] } obj: if [ ! -d $(e) ]; then mkdir $(e); fi $(ghc) $(HCFlags) --make DExport -package-name dm dm: obj rm -f $(e)/libHSdm.a $(e)/HSdm.o ar -qc $(e)/libHSdm.a $(wildcard $(e)/*.o) $(RANLIB) $(e)/libHSdm.a $(RANLIB) $(e)/libHSdm.a echo $(pack) | $(ghcpkg) -f $(s)/dm.conf -u -g $(ghcpkg) -f $(s)/dm.conf -l ----------------------------------------------------------------- First, I do not recall why the line $(RANLIB) $(e)/libHSdm.a repeats, by intention or by a typo. Then, for the profiling, I set extraHCOpts = -prof -hisuf p_hi -osuf p_o ... dm: obj rm -f $(e)/libHSdm* $(e)/HSdm* ar -qc $(e)/libHSdm_p.a $(wildcard $(e)/*.p_o) ~~~~ ~~~~ $(RANLIB) $(e)/libHSdm_p.a ~~~~ $(RANLIB) $(e)/libHSdm_p.a echo $(pack) | $(ghcpkg) -f $(s)/dm.conf -u -g ~~~ $(ghcpkg) -f $(s)/dm.conf -l To build the test, I command cd demotest ghc $pcpdm -prof -hisuf p_hi -osuf p_o --make Main Please, where to set foo_p.a or foo.p_a ... ? (or what it might be). And how the above $(ghcpkg) ... -u -g correlates with this. What to change in pack = Package {... ? } I set it one way, and the library build reports cannot find `libHSdm.a' on library path. I set it other way, and ghc $pcpdm -prof -hisuf p_hi -osuf p_o --make Main reports cannot find HSdm_p Should it be export/HSdm_p.o or HSdm.p_o or HSdm.o or ? export/libHSdm_p.a or libHSdm.p_a or libHSdm.a or ? As Simon Marlow has the source d.zip, maybe he could send me the corresponding settled Makefile? > In the future, Cabal will make this easier. > Have you tried using Cabal for docon yet? > It should simplify a lot of things for you. I applied profiling with GHC 2-3 years ago. It helped. And do not recall of Cabal, nor even of -hisuf p_hi -osuf p_o options. Why should GHC complicate the usage? Thank you in advance for the help, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: overzealous defaulting?
by Simon Peyton-Jones 23 Aug '04

23 Aug '04

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

2 1