Re: GADT Type Checking GHC 6.10 versus older GHC
Jason Dagit dagit at codersbase.com writes: On Fri, Nov 21, 2008 at 8:57 AM, Simon Peyton-Jones simonpj at microsoft.com wrote: You need a type signature for the case expression. As Daniel says, this is worth a readhttp://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching Thanks Simon. I had read that several times in the past and I've pointed it out to others. It's still relevant but, my question was about whether or not examples like the one posted are really in error or if GHC is just being overly strict now. In my case, we had rigid type signatures all over the place. The wiki document says that the type must be rigid at the point of the match. I guess that's what we were violating. If the code I posted isn't supposed to type check then I would like to report, as user feedback, that GADTs have become unwieldy. This is really worrying. I have spent some considerable time using GADTs to structure a library. I haven't tried 6.10 yet because it's not available in a packaged form for my flavour of linux. I will put some work into doing this today and report back. Dominic. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Exporting an #include from one package to another?
On Fri, 2008-11-21 at 18:28 -0800, Conal Elliott wrote: Is there a way to package up an #include like to share across (be #include'd into) various other haskell packages? I have some standard templates for type class instances that I can't define as instances without creating lots of overlapping instances. I can write an include file easily enough, but I don't know how to get other packages to find and #include that include file. Yes. This is partly what the install-includes: field in the .cabal file is for. Each client has to #include it explicitly of course, but the include search path should be set up to make that work. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT Type Checking GHC 6.10 versus older GHC
Dominic Steinitz dominic.steinitz at blueyonder.co.uk writes: packaged form for my flavour of linux. I will put some work into doing this today and report back. Dominic. Phew - I installed the windows 6.10.1 package and everything to do with GADTs still seems to work. Dominic. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, 2008-11-21 at 14:01 +, Simon Marlow wrote: I propose we do this: * extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package. This is good independently of the other suggestions. * Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs. This gives us line-editing on Windows, and removes problematic external C library dependencies. I think this is worth trying. It seems like Judah is prepared to put the work in to make haskeline work on various platforms and to trim the dependencies. Eg I'd rather us decide what to do about Unicode input rather than just end up de-facto standardising the utf8-string package. It seemed like we had a consensus on what to do for the H98 IO with Unicode. We just need to get on with it. In addition we need to agree some control over encoding when using a specific encoding is called for (eg reading a file that is known to be UTF-16 independent of the locale). * Make it possible to compile the ghc-bin package against readline. Upload ghc-bin to Hackage, so people can say cabal install ghc-bin -f readline and get a GHCi built against readline if they want. If haskeline works then I doubt there will be much pressure for readline support. The pining for the good old days of readline at the moment are only because editline clearly doesn't work. [For some definition of work] Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package? A variant license isn't a fundamental technical problem though perhaps the consensus is that variant licenses are a bad thing. I'm not sure. One would have to use OtherLicense and specify what the conditions are in the license file. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Arnar == Arnar Birgisson [EMAIL PROTECTED] writes: Arnar To clarify - most of modern fonts do in deed have Arnar latin-greek-cyrillic (including the U+03BB lambda), but I Arnar was referring to the specific math symbols such as the Arnar U+1D6CC bold lam(b)da, which reside in the Supplementary Arnar Multilingual Plane (SMP). Those are indeed not present in Arnar my fonts, including Lucida Math and Adobe Mathematical Pi). I tackled David Carlisle about this too: David On windows there's cambria math (unfortunately with a restrictive licence that restricts it to that platform, though you can get it for free by getting (for example) the free powerpoint viewer from microsoft) for a free font with a full range of characters best bet is stix font which has been 10 years in the making and is currently between beta and full release (but late again) the stix site removed the fonts after the beata test but you can get them from mozilla, and you need them if reading mathml in FF3. http://www.stixfonts.org/ http://www.mozilla.org/projects/mathml/fonts/ Colin echo $(uc 1D6cc) - doesn't print anything recognizable David That would require not only fonts with glyphs in that slot but also that the software (xterm here) understands plane 1 not just the 16bit unicode 2 support. I don't know whether xterm does or not. I downloaded the fonts, but xterm still doesn't display the character concerned. Nor does Firefox, although I haven't tried it with MathML yet. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross module optimization issues
jwlato: On Wed, Nov 19, 2008 at 4:17 PM, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | I'm compiling with -O2 -Wall. After looking at the Core output, I | think I've found the key difference. A function that is bound in a | where statement is different between the monolithic and split | sources. I have no idea why, though. I'll experiment with a few | different things to see if I can get this resolved. In general, splitting code across modules should not make programs less efficient -- as Don says, GHC does quite aggressive cross-module inlining. There is one exception, though. If a non-exported non-recursive function is called exactly once, then it is inlined *regardless of size*, because doing so does not cause code duplication. But if it's exported and is large, then its inlining is not exposed -- and even if it were it might not be inlined, because doing so duplicates its code an unknown number of times. You can change the threshold for (a) exposing and (b) using an inlining, with flags -funfolding-creation-threshold and -funfolding-use-threshold respectively. If you find there's something else going on then I'm all ears. Simon I did finally find the changes that make a difference. I think it's safe to say that I have no idea what's actually going on, so I'll just report my results and let others try to figure it out. I tried upping the thresholds mentioned, up to -funfolding-creation-threshold 200 -funfolding-use-threshold 100. This didn't seem to make any performance difference (I didn't check the core output). This project is based on Oleg's Iteratee code; I started using his IterateeM.hs and Enumerator.hs files and added my own stuff to Enumerator.hs (thanks Oleg, great work as always). When I started cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my minimal test case increased from 19s to 43s. I've found two factors that contributed. When I was cleaning up, I also removed a bunch of unused functions from IterateeM.hs (some of the test functions and functions specific to his running example of HTTP encoding). When I added those functions back in, and added INLINE pragmas to the exported functions in MyEnum.hs, I got the performance back. In general I hadn't added export lists to the modules yet, so all functions should have been exported. So it seems that somehow the unused functions in IterateeM.hs are affecting how the functions I care about get implemented (or exported). I did not expect that. Next step for me is to see what happens if I INLINE the functions I'm exporting and remove the others, I suppose. Thank you Simon and Don for your advice, especially since I'm pretty far over my head at this point. Is this , since it is in IO code, a -fno-state-hack scenario? Simon wrote recently about when and why -fno-state-hack would be needed, if you want to follow that up. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
On 2008 Nov 22, at 12:12, Colin Paul Adams wrote: Arnar == Arnar Birgisson [EMAIL PROTECTED] writes: Arnar To clarify - most of modern fonts do in deed have Arnar latin-greek-cyrillic (including the U+03BB lambda), but I Arnar was referring to the specific math symbols such as the Arnar U+1D6CC bold lam(b)da, which reside in the Supplementary Arnar Multilingual Plane (SMP). Those are indeed not present in Arnar my fonts, including Lucida Math and Adobe Mathematical Pi). David On windows there's cambria math (unfortunately with a restrictive licence that restricts it to that platform, though you can get it for free by getting (for example) the free powerpoint viewer from microsoft) for a free font with a full range of characters best bet is stix font which has been 10 years in the making and is currently between beta and http://dejavu.sourceforge.net/ works for me. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
