GHCi is being too helpful
Hi everyone, When evaluating an IO monad in GHCi from the 6.6.1 distribution, the REPL tries to be a bit too smart about printing out the returned value. For example, () values are not printed: Prelude System.Directory setCurrentDirectory work Prelude System.Directory ...but String, or, as far as I can see, any other values, do get printed: Prelude System.Directory getCurrentDirectory /home/shinobi Prelude System.Directory set In my particular case, the value printed is a 250,000-element list -- waiting for the value to print out is not an option. I don't want to see the whole list at once, but do need to examine parts of it, subject it to intermediate transformations, etc. Is there any way to suppress this output and revert to the old behavior, where the value was simply bound to it, without being printed? Thanks, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Portage slots for GHC?
Hi, I'm using GHC on Gentoo, and so far I've had to stay clear of GHC 6.6, because I've also installed stuff depending on 6.4.2, like wxHaskell, for instance. Now I see a new version of mtl, which I also have installed, depends on 6.6.1, while all of the rest of the stuff is lagging behind with a dependency on 6.4.2. Of course, I can easily solve the problem partially by masking out the new version for mtl, but this is going to become a major inconvenience with new versions of GHC and its dependents. What I'm getting at is, can we please have separate slots for GHC 6.4.2 and 6.6 on portage? Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On 6/20/07, Isaac Dupree [EMAIL PROTECTED] wrote: yes, binutils written in Haskell! Will never happen! :)) It's crossed my mind as well, once or twice -- maybe it's not such a bad idea. Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Happy bug
On 4/16/07, Isaac Dupree [EMAIL PROTECTED] wrote: The code generated by Alex is perfectly good Haskell98+cpp, except: #if __GLASGOW_HASKELL__ = 603 #include ghcconfig.h #else #include config.h #endif If that else is modified to only trigger if we're using GHC at all[1], then plain C pre-processing[2] makes it run fine in Hugs, too. [1] (which I don't know how to do, I actually just deleted the line #include config.h from the generated file) Guarding the whole block with #ifdef __GLASGOW_HASKELL__ should do it. Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scripts on unix
FWIW, I used to employ a combination of environment vars and registry entries (for file associations) on Windows in order to be able to work with multiple GHC versions. The environment vars (e.g. for PATH or LIB inclusion) would all depend on a GHC_HOME var, which could be redefined to point to the GHC installation du jour. I am not sure how much common structure there would be among installations of GHC, NHC, HUGS, etc., but maybe the same thing could still work, possibly with some tweaks. Cheers, Dinko On 3/15/07, Sven Panne [EMAIL PROTECTED] wrote: On Thursday 15 March 2007 10:56, Malcolm Wallace wrote: [...] If you install hmake, and change 'runhaskell' to runhs, it works. This reminds me of something, at least for the Linux world: No Haskell compiler/interpreter should directly install 'runhaskell'. Instead of that, it should only directly install runghc, runhugs, runnhc, ... and use update-alternatives (or a similar technology for that platform) to inform the native package system that there is a new alternative for 'runhaskell'. Similar reasoning holds for cpphs, hsc2hs and friends. I'll update the .spec files accordingly soon. Doing it that way, the local sysadmin has the choice to configure which Haskell implementation is the default and several versions of the same implementation could be installed side by side. I don't have a clue how to do this correctly for Mac OS X and Windows, though. And 'runhs' is actually not a very good name to run nhc98, runnhc or runnhc98 would be much better IMHO. Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: size of snapshot archive
On 2/18/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello glasgow-haskell-users, i'm tried to download newer snapshot of 6.6 and found that now it's 74 mb! why it is so large and why it's so enlarged after 6.6 release? isn't it possible to reduce size of this package? Does this include darcs version info? I've noticed that darcs generates suspiciously large quantities of context info for very small patches (e.g. ~7000 lines of context for a ~700 line patch) -- for what I've seen so far, the context section might be growing linearly with the file's history. For what it's worth, I've got a partial tree that is ~64M in size, of which version info is about 60%, and current source is about 40%. Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Views in Haskell
On 1/24/07, Brian Hulley [EMAIL PROTECTED] wrote: A possible syntax could represent the value being matched explicitly, say using ? to represent the value currently being matched, then the pattern could be written as an equation: f (prodSize ? = Small) = ... f (prodSize ? = Medium) = ... f (prodSize ? = Big) = ... ...or maybe (Small = prodSize ?), etc., to be consistent with let bindings? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Common subexpression elemination (CSE)
On 11/27/06, Lennart Augustsson [EMAIL PROTECTED] wrote: GHC doesn't normally do CSE. CSE can cause space leaks, so you can't do it willy-nilly. I'm sure there are some strict contexts where it could be done safely, but I don't think ghc uses that information (yet). -- Lennart My apologies in advance for asking possibly stupid questions, but I don't understand this. How exactly can CSE cause space leaks, and what does this have to do with strictness? Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Common subexpression elemination (CSE)
On 11/28/06, Bertram Felgenhauer [EMAIL PROTECTED] wrote: Dinko Tenev wrote: On 11/27/06, Lennart Augustsson [EMAIL PROTECTED] wrote: GHC doesn't normally do CSE. CSE can cause space leaks, so you can't do it willy-nilly. I'm sure there are some strict contexts where it could be done safely, but I don't think ghc uses that information (yet). -- Lennart My apologies in advance for asking possibly stupid questions, but I don't understand this. How exactly can CSE cause space leaks, and what does this have to do with strictness? Combining two expressions means that they're represented by the same memory location. In particular when you start evaluating the first, the second reference to the value will keep all of it alive even if parts of it could otherwise be freed. This is especially problematic for infinite lists. http://hackage.haskell.org/trac/ghc/ticket/947 demonstrates this problem, caused by the little CSE that ghc does. (Note: This is not of the form let x = term in ... term ..., but it will be once it's desugared and the simplifier has floated out the constant expressions from the primes0 and primes functions) I'm not sure how it relates to strictness. I'd be more worried about about the size of the data that's being kept alive. Numbers are more likely to be ok than lists. Bertram I see the point, though it still feels a bit weird to call this a leak (it also explains the relation to strictness for me, as the issue seems to be irrelevant in a strict context.) Thanks for the explanation. -- Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: limitations of newtype-derivings (fixed)
On 4/11/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | deriving (Show Foo) I'm all for that. A modest but useful gain. All we need is the syntax, and that is something that Haskell Prime might usefully define. Speaking of which, how about simply qualifying a body-less instance with deriving, like this: deriving instance Show Foo -- Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: partial application syntax
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/FlexiblePartialApplication On 3/7/06, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Hello, there was some proposal for introducing a special syntax where f x _ z or f x ? z means \y - f x y z. Is there some information on the Haskell' trac site about this? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime -- Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Problem building on sparc/Linux
Something to do with Parsec, maybe? For what it's worth, the darcs repo version of genprimopcodes compiled with GHC 6.4 does parse the attached vore-primops.txt. On 3/1/06, Ian Lynagh [EMAIL PROTECTED] wrote: [ ... ] ../utils/genprimopcode/genprimopcode --data-decl prelude/primops.txt primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected \t expecting primop, section or thats_all_folks [ ... ] -- Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more flexible partial application
On 1/26/06, Aaron Denney [EMAIL PROTECTED] wrote: On 2006-01-26, Dinko Tenev [EMAIL PROTECTED] wrote: On 1/26/06, Conor McBride [EMAIL PROTECTED] wrote: [...] We'd do daft stuff like (200 * _ ^ 2) unitsquare Yes, I played with a concept like that at one point, and came to the conclusion that it was better done with lambdas. I am all specifically about function application, not arbitrary expressions. Arbitrary expressions are just function application. ...arbitrarily deeply nested. I meant looking at a single level of function application, with all the consequences for how high up the tree the underscore may escape as a lambda. You're probably going to tell me that f x y z represents 3 different levels, but many folks would see this as little more than a cute way of writing f(x, y, z), and they'll have a point, given how the concept of partial application is bandied every so often. It is quite reasonable to identify a minimal enclosing application, with all visible arguments consumed up to the innermost enclosing pair of parentheses. Sure, it's not a very elegant concept, but neither is the current mechanism for operator sections (which does exactly the same.) The only implication will be that you won't be able to use sections *and* emphasize the order of application at the same time, and I am yet to hear from anyone who prefer (((f x) y) z) to (f x y z) in their code. BTW, it just occurred to me that if this section syntax is extended to operators as well, it would cure the rather embarrassing case of the - operator :) If you do want to pull a stunt like this, you need some other funny brackets which specifically indicate this binding power, and then you can do grouping inside them, to create larger linear abstractions. You could have something like (| f (_ * 3) _ |) We already have lambdas for this, and they're shorter, clearer, and more powerful. The same hold (except for shorter) for this whole extension, and I don't know that shorter holds here. I missed an underscore, so you have your point about shorter. About the whole extension, (f x _ z) is arguably clearer than \y - f x y z, and is also really unobtrusive syntactic sugar, very much unlike a new kind of brackets. -- Aaron Denney -- Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: more flexible partial application
On 1/26/06, John Hughes [EMAIL PROTECTED] wrote: I'd be against this--its semantics isn't clear enough to me. For example, I usually assume id e = e, for any e, but id (f _ x) y = id (\y-f y x) y = f y x /= f _ x y = \z - f z x y Or would (f _ x) y and f _ x y maybe be different? That would fix the problem above, while introducing another. Please, no! They should be different for this to work. The reasonable thing to do would be to rewrite every (e _ a1 a2 ... an) as (\x - (e x a1 a2 ... an)) and the parentheses should be mandatory. Note that this can be done recursively, so that e.g. (f _ y _ t) == (\x1 - (f x1 y _ t)) == (\x1 - (\x2 - (f x1 y x2 t))) I see this as no worse than operator sections: we already have (- x) and (-) x meaning different things. Having in mind that (e _ ...) is just syntax, it should be easy to keep it separate from application, so f x y z will still be the same as ((f x) y) z. John Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Broken build
Yes, last night's build worked for me, thanks.On 11/21/05, Simon Peyton-Jones [EMAIL PROTECTED] wrote: I believe I have fixed this.(It was my fault, late last week.)I'm compiling now to test.Meanwhile it'd be worth your having another go.Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Broken build
I updated from HEAD recently, and got some strange error messages while building the stuff under libraries/X11: ../../ghc/compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches -fwarn-unused-imports -cpp -fffi -Iinclude -I/usr/X11R6/include -ignore-package X11 -O -dcore-lint -W -fno-warn-unused-matches -fwarn-unused-imports -keep-hc-files -package base -fgenerics-c Graphics/X11/Xlib/Font.hs -o Graphics/X11/Xlib/Font.o -ohi Graphics/X11/Xlib/Font.hi Font.hsc:70:0: Unacceptable argument type in foreign declaration: Display When checking declaration: foreign import ccall unsafe static HsXlib.h XQueryFont queryFont :: Display - Font - IO FontStruct ...as well as several others for the same file, along the same lines. I am none the wiser by the messages, but the comment for ghc/compiler/prelude/TysWiredIn.lhs#rev1.75 seems to be related. Is this a regression? BTW, could someone give me a clue what the point is with a type like the one mentioned? Regards, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network Exception
It looks odd to me, because the service is not particularly meaningful to the transport, and thus not a crucial piece of information. Unless I am missing something, this could be a bug in the Network module. You may want to try the lower-level stuff from Network.Socket instead. Cheers, Dinko On 10/14/05, Arias [EMAIL PROTECTED] wrote: Hi,I've a problem, I'm using this code on GHC compiler version 6.4.1:--- BEGIN ---module Main whereimport System.IOimport Networkmain = withSocketsDo $ dohandle - connectTo localhost ( PortNumber 8080 ) hSetBuffering handle LineBufferinghClose handle--- END ---The problems is that it throws an exception at connectTo, the exception is:getServiceEntry: does not exist (no such service entry) The server and the port is correct, I have apache listening on port 8080and if I put http://localhost:8080/ on browser it loads a web page.Do somebody knows what it happens and how to fix it? thanks. ___Glasgow-haskell-users mailing listGlasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building GHC
On 7/18/05, Simon Marlow [EMAIL PROTECTED] wrote: The GHC command-line isn't declarative, it's imperative. Options are processed left-to-right. I don't have any doubts about whether GHC can make sense of conflicting options or not, be it the one way or the other. What's causing the trouble is that part of the intent specified on the command line is not carried-out by the compiler, and the only way to diagnose (or even be aware of) such occurrences seems to be searching through the manual, perhaps without even knowing what one is looking for. That's the general rule, anyway. It would be an interesting exercise to specify the GHC command-line semantics, or better still, redesign it :) I for one would find it quite helpful to see a warning line for each overriden option, if without so much of an explanation -- a red light to let me know something might be wrong. Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building GHC
On 7/15/05, Simon Marlow [EMAIL PROTECTED] wrote: As a workaround you can disable object splitting. Add the line SplitObjs=NO to mk/build.mk before building. I did that, and it got me a bit further. Now ghc-inplace dumps core compiling Language/Haskell/Syntax.hs: ==fptools== make way=p all; PWD = /home/shinobi/build/fptools/libraries/haskell-src ../../ghc/compiler/ghc-inplace -H32m -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports -ignore-package haskell-src -package base -fgenerics -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Language/Haskell/Syntax.hs -o Language/Haskell/Syntax.p_o -ohi Language/Haskell/Syntax.p_hi Language/Haskell/Syntax.hs:68:0: Warning: Module `Data.Generics.Instances' is imported, but nothing from it is used (except perhaps instances visible in `Data.Generics.Instances') make[3]: *** [Language/Haskell/Syntax.p_o] Killed make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/shinobi/build/fptools/libraries' make: *** [build] Error 1 Any ideas? Cheers, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building GHC
BTW, I tried to compile the file with the installed ghc, and I am kind of puzzled by the error message I get: ghc -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports -ignore-package haskell-src -package base -fgenerics -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Language/Haskell/Syntax.hs -o Language/Haskell/Syntax.p_o -ohi Language/Haskell/Syntax.p_hi ghc-6.2.2: -ohi can only be used when compiling a single source file Usage: For basic information, try the `--help' option. How am I trying to compile anything other than a single source file here??? Cheers, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building GHC
I did a devel build this time, which produced some verbose output
for the last line.
One thing that troubles me is that gcc still manages to kick-in - what
exactly is going on???
==fptools== make all -wr;
in /home/shinobi/build/fptools/libraries/haskell-src
../../ghc/compiler/ghc-inplace -H32m -O0 -fasm -W
-fno-warn-unused-matches -fwarn-unused-imports -ignore-package
haskell-src -O -dcore-lint -W -fno-warn-unused-matches
-fwarn-unused-imports -keep-hc-files -package base -fgenerics-c
Language/Haskell/Syntax.hs -o Language/Haskell/Syntax.o -ohi
Language/Haskell/Syntax.hi
check_tc DataziTuple.Z2T{(w) tc 46}
Language/Haskell/Syntax.hs:68:0:
Warning: Module `Data.Generics.Instances' is imported, but nothing
from it is used
(except perhaps instances visible in `Data.Generics.Instances')
check_tc DataziTuple.Z2T{(w) tc 46}
check_tc DataziTuple.Z2T{(w) tc 46}
check_tc DataziTuple.Z2T{(w) tc 46}
check_tc DataziTuple.Z2T{(w) tc 46}
check_tc DataziTuple.Z2T{(w) tc 46}
check_tc DataziTuple.Z2T{(w) tc 46}
check_tc DataziTuple.Z2T{(w) tc 46}
NOTE: Simplifier still going after 4 iterations; bailing out.
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-3.3/README.Bugs.
make[2]: *** [Language/Haskell/Syntax.o] Error 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/shinobi/build/fptools/libraries'
make: *** [build] Error 1
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building GHC
It turns out, ar couldn't quite handle building the symbol table for the archive. I tried ar qS, then ranlib the archive, but ranlib turns out to be exactly the same kind of brittle crap... I am currently looking for more robust binutils - I'll appreciate any siggestions. Cheers, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problem building GHC
Hi, I am trying to build from the current GHC source tree on a Debian sarge box, and the build dies trying to compile /home/shinobi/build/fptools/ghc/parser/Parser.hs, with the following output: /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -recomp -Rghc-timing -H16M '-#include hschooks.h' -i../lib/compat -fno-warn-incomplete-patterns -fvia-C -Onot -fno-ignore-interface-pragmas -c parser/Parser.hs -o stage1/parser/Parser.o -ohi stage1/parser/Parser.hi gcc: Internal error: Killed (program cc1) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.3/README.Bugs. ghc: 1033208048 bytes, 2605 GCs, 14120845/28258632 avg/max bytes residency (11 samples), 74M in use, 0.00 INIT (0.00 elapsed), 7.63 MUT (19.52 elapsed), 5.54 GC (5.57 elapsed) :ghc make[2]: *** [stage1/parser/Parser.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/shinobi/build/fptools/ghc' make: *** [build] Error 1 It seems that, apart from whatever else might be wrong, there is a problem with GCC. I guess I'll have to switch to version 2.95.2 as suggested by the guide (I am currently using 3.3.5,) but I also see some messages reporting Bad eta expand earlier in the output - could this also be related to the problem? Cheers, D. tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: ANNOUNCE: GHC survey results
On 6/28/05, Jim Apple [EMAIL PROTECTED] wrote: Some people would like features removed (implicit parameters was mentioned a couple of times). Linear implicit parameters is a clear candidate for removal. I don't understand the motivation for this. Implicit parameters do weird things with the monomorphism restriction, but when I'm worried about that, I choose not to use them together. Why remove a feature from a product? Why not, instead, just choose to not use it? It depends on what you mean by using it, of course, but sometimes that's not a matter of choice (e.g. when you're reading others' code.) Cheers, D. Tenev ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: explicit signatures and default for integer literals
On 5/31/05, Daniel Fischer [EMAIL PROTECTED] wrote: Why is ghc unable the determine the type of the Literal 0 in the definition of g? Answer: Since somewhere an instance e.g. New [(a,Double)] (Map a Int) could be defined, leading to problems when threating 0 as (0::Int). There could be such an instance, but that's obviously not the case. At the point where g is defined, GHC only knows about New [(a,b)] (Map a b), and New [(a,Double)] (Map a Int) doesn't fit. Consider this: *Main :type new . flip zip [0..] new . flip zip [0..] :: (New [(a, b1)] b, Num b1, Enum b1) = [a] - b Trying to infer New [(u, v)] w out of all that we know, i.e. New [(a,b)] (Map a b) should give us w === Map u v --- New [(u, v)] (Map u v) so finally v === Int --- New [(u, Int)] (Map u Int) to infer the context of g. Is there any good reason not to do this? Cheers, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicit signatures and default for integer literals
On 5/31/05, Seth Kurtzberg [EMAIL PROTECTED] wrote: Because I'm not smart enough to understand it? ;-) OK, sorry about the notation (I just didn't feel like doing so much typing, you know :) Here goes... First we observe that, g = new . flip zip [0..], so, without the type specification, it has the general type (New [(a, b1)] b, Num b1, Enum b1) = [a] - b, as reported by GHC. Then we infer from (1) g :: (New [(u, v)] w, Num v, Enum v) = [u] - w and (2) instance New [(a, b)] (Map a b) that in (New [(u, v)] w), w can only be (Map u v), so subst (Map u v) for w to obtain (3) g :: (New [(u, v)] (Map u v), Num v, Enum v) = [u] - Map u v Furthermore, for g we have already specified (4) g :: Ord a = [a] - Map a Int so finally substituting Int for v should give us (5) g :: (New [(u, Int)] (Map u Int), Num Int, Enum Int, Ord Int) = [u] - Map u Int Is there any good reason why GHC won't do this? Particularly, is there any good reason not to infer (New [(u, v)] (Map u v)) from (New [(u, v)] w) as in (1), (2) -- (3) above? Cheers, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicit signatures and default for integer literals
On 5/31/05, robert dockins [EMAIL PROTECTED] wrote: Dinko Tenev wrote: First we observe that, g = new . flip zip [0..], so, without the type specification, it has the general type (New [(a, b1)] b, Num b1, Enum b1) = [a] - b, as reported by GHC. Then we infer from (1) g :: (New [(u, v)] w, Num v, Enum v) = [u] - w and (2) instance New [(a, b)] (Map a b) that in (New [(u, v)] w), w can only be (Map u v) This step in the reasoning requires a functional dependency, which you mentioned earlier you were unwilling to supply. Without functional dependencies w can, in fact, be something other than (Map u v). We need to infer New [(u, v)] w, and the only thing we know so far is New [(a, b)] (Map a b). In this context, what else could we possibly have for w besides (Map u v) ? Cheers, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicit signatures and default for integer literals
*Main :type fromList
fromList :: (Ord k) = [(k, a)] - Map k a
*Main :type new
new :: (New a b) = a - b
The type of new probably accounts for the difference (even though it
still makes me wonder what the big deal is :)
Using functional dependencies seems to fix it, i.e.:
class New a b | a - b where new :: a - b
or, perhaps more appropriately:
class New a b | b - a where new :: a - b
Cheers,
D. Tenev
On 5/27/05, Mirko Rahn [EMAIL PROTECTED] wrote:
Hi all,
an explicit given signature causes ghc to choose the right types for
integer literals as in
{-# OPTIONS -fglasgow-exts #-}
import Data.Map
f :: Ord a = [a] - Map a Int
f xs = fromList $ zip xs [0..]
Here the Literal 0 is threated as (0::Int).
But the setting
{-# OPTIONS -fglasgow-exts #-}
import Data.Map
class New a b where new :: a - b
instance Ord a = New [(a,b)] (Map a b) where new = fromList
g :: Ord a = [a] - Map a Int
g xs = new $ zip xs [0..]
causes the error message
Could not deduce (New [(a, b)] (Map a Int)) from the context (Ord a)
arising from use of `new' at Why.hs:10:7-9
ghc seems to be unable to threat the Literal 0 as (0::Int) this time but
I do not understand why :-(
Can anyone explain it?
Thanks,
--
-- Mirko Rahn -- Tel +49-721 608 7504 --
--- http://liinwww.ira.uka.de/~rahn/ ---
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
