Re: [Haskell-cafe] hackage version scheme survey
On Saturday, 23.05.09 at 21:10, wren ng thornton wrote: > I hear they're looking for someone to write a program to check for API > changes in order to detect and enforce the policy :) Care to help? Yeah, I'm looking into it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage version scheme survey
br...@lorf.org wrote: On Saturday, 23.05.09 at 17:26, Don Stewart wrote: > http://haskell.org/haskellwiki/Package_versioning_policy ? That helps a lot. I should have found that. But putting the policy on a web page doesn't seem to be working; there are a lot of non-compliant packages. I guess I'm surprised thah 'cabal check' doesn't complain about it and HDB doesn't reject them. I hear they're looking for someone to write a program to check for API changes in order to detect and enforce the policy :) Care to help? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage version scheme survey
On Saturday, 23.05.09 at 17:26, Don Stewart wrote: > http://haskell.org/haskellwiki/Package_versioning_policy ? That helps a lot. I should have found that. But putting the policy on a web page doesn't seem to be working; there are a lot of non-compliant packages. I guess I'm surprised thah 'cabal check' doesn't complain about it and HDB doesn't reject them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
On Sat 23/05/09 2:51 PM , Duncan Coutts duncan.cou...@worc.ox.ac.uk sent:
> On Sat, 2009-05-23 at 13:31 -0400, Mario Blažević wrote:
> ...
>> So the function is not strict, and I don't understand
>> why GHC should evaluate the arguments before the call.
>
> Right, it's lazy in the first and strict in the second argument. As far
> as I can see we have no evidence that is is evaluating anything before
> the call.
When I look at the Core definition of `test', it begins with
\ (n1axl::integer:GHCziIntegerziInternals.Integer)
(n2axn::integer:GHCziIntegerziInternals.Integer) ->
%let as1sU :: integer:GHCziIntegerziInternals.Integer =
base:DataziList.prod1
(main:Main.factors2
(base:DataziList.prod1
(base:GHCziNum.upzulist main:Main.lvl main:Main.lvl n1axl)
base:DataziList.lvl1))
base:DataziList.lvl1
%in %case integer:GHCziIntegerziInternals.Integer
(ghczmprim:GHCziPrim.parzh
@
integer:GHCziIntegerziInternals.Integer
as1sU)
%of (dsapq::ghczmprim:GHCziPrim.Intzh)
To my untrained eyes, this looks like it's evaluating
> product $ factors $ product [1..n1])
which is the first argument to `parallelize'. I assume that %case in
Core evaluates the argument to WHNF, just like case in Haskell.
Then again, I could be completely misinterpreting what Core is, because
I can't find any call to `parallelize' before or after that. It appears
to be inlined in Core, regardless of whether the pragma
> {-# INLINE parallelize #-}
is there or not. Actually, I can't see any effect of that pragma in the
core files whatsoever, but it certainly has effect on run time.
>> Does anybody know of a pragma or another way to make a
>> function *non-strict* even if it does always evaluate its argument?
>> In other words, is there a way to selectively disable the strictness
>> optimization?
>
> Yes, which is what pseq and par already do.
>
> If there's a bug, we need to reproduce it and report it. I cannot
> reproduce it.
If you mean that you can't reproduce anything that's contrary to the
specification, that's not saying much: there are practically no guarantees on
what `par' is supposed to accomplish. If you mean you can't reproduce anything
you wouldn't expect, pray explain what is going on, because everybody else seems
to be surprised. Or do you mean to say that *your* installation of GHC behaves
the same when the function `parallelize' is defined in the same module and when
it's imported?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage version scheme survey
brian: > Maybe most of the a.b people are thinking major.minor, and most of the > a.b.c people are thinking breaking.feature.implementation like the > "rational" RubyGems scheme described in > http://rubygems.org/read/chapter/7#page24 , but I don't know. It makes > it hard to describe dependencies. Will there be a standard versioning > scheme sometime? http://haskell.org/haskellwiki/Package_versioning_policy ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hledger 0.5 released
I'm pleased to announce the hledger 0.5 release on hackage. hledger is a (mostly) text-mode double-entry accounting tool that generates precise activity and balance reports from a plain text journal file. It is a partial clone, in haskell, of John Wiegley's excellent ledger. hledger implements a subset of ledger's commands and options, and also provides some new ones. For basic use you can use hledger and ledger pretty much interchangeably on the same data files. For screenshots, live demo, docs etc. see http://hledger.org . Release notes are at http://hledger.org/NEWS , and below. To install: cabal install hledger [-fvty] [-fhapps]. I'd like to hear feedback, especially if you are having trouble getting started. Happy tracking! - Simon (sm on #ledger) 2009/05/23 hledger 0.5 released --- Changes: * the vty flag is disabled by default again, to ease installation on windows * use ledger 3 terminology: a ledger contains transactions which contain postings * new "add" command prompts for transactions interactively and adds them to the ledger * new "convert" command transforms bank CSV exports to ledger format, with rule-based cleanup * new "histogram" command shows transaction counts per day or other reporting interval * most commands now work properly with UTF8-encoded text (Sergey Astanin) * invoking as "hours" is now less different: it just uses your timelog, not your ledger * --quarterly/-Q option summarises by quarter * --uncleared/-U option looks only at uncleared transactions * be more accurate about checking balanced amounts, don't rely on display precision * enforce balancing for bracketed virtual postings * fix bug in eliding of posting amounts * don't show trailing spaces on amountless postings * parse null input as an empty ledger * don't treat comments as part of transaction descriptions * require some postings in ledger transactions * require a non-empty description in ledger transactions * don't fail when matching an empty pattern, as in "not:" * make the web server handle the null path * code, api and documentation updates * add a contributor agreement/list Release contributors: * Simon Michael * Sergey Astanin Release stats: * Days since last release: 51 * Committers: 2 * Commits: 101 * Lines of non-test code: 2795 * Known errors: 0 * Tests: 76 * Performance: || hledger-0.4 | hledger-0.5 | ledger =++=+=+=== -f sample.ledger balance ||0.01 |0.01 | 0.06 -f 1000.ledger balance ||1.33 |1.46 | 0.53 -f 1.ledger balance || 15.28 | 16.35 | 4.67 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: haddock could be a pretty-printer?
2009/5/22 Maurício : >>> The new version of haddock makes use of GHC parser. How much >>> of effort would take to make haddock generate pretty-print >>> of the source code itself, (...) > >> (...) Is this what you want or is there some reason why you >> want the code to be pretty-printed? > > I usually have to resort to braces or bad indenting to get > code to parse, but I like to give it good presentation before > publishing. > > I used to pretty-print my code using haskell-src-exts with > great result, but that kills documentation. I think the plan is to extend haskell-src-exts to retain comments. But if you want something that works now, you could use the GHC API. It has support for getting the token stream of a module, which contains the comments as tokens. Using Haddock to do this is not a good idea, better use the GHC API directly. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage version scheme survey
2009/5/24 : > Maybe most of the a.b people are thinking major.minor, and most of the > a.b.c people are thinking breaking.feature.implementation like the > "rational" RubyGems scheme described in > http://rubygems.org/read/chapter/7#page24 , but I don't know. It makes > it hard to describe dependencies. Will there be a standard versioning > scheme sometime? We have one already: http://www.haskell.org/haskellwiki/Package_versioning_policy David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hackage version scheme survey
It's not good to specify open version ranges in cabal build-depends like foo >= 1.1 because the foo maintainer will eventually release 2.0, containing API-breaking changes, and the build will fail. If you depend on foo 1.1, you can specify == 1.*, no problem. But if you depend on a package that uses a version scheme like 1.2.3 or 1.2.3.4, it's not clear (at least to me) where the major/minor division is. I did a survey of version schemes in 'cabal list': 484 packages use a.b. 630 packages use a.b.c. 180 packages use a.b.c.d. The rest: two packages use just one field for their versions; one uses five; one uses six. Maybe most of the a.b people are thinking major.minor, and most of the a.b.c people are thinking breaking.feature.implementation like the "rational" RubyGems scheme described in http://rubygems.org/read/chapter/7#page24 , but I don't know. It makes it hard to describe dependencies. Will there be a standard versioning scheme sometime? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
On Sat 23/05/09 4:15 PM , Alexander Dunlap alexander.dun...@gmail.com sent: >>> Does anybody know of a pragma or another way to make a >>> function *non-strict* even if it does always evaluate its >>> argument? In other words, is there a way to >>> selectively disable the strictness optimization? >> >> parallelize a b | False = (undefined, undefined) >> | otherwise = a `par` (b `pseq` (a, b)) >> >> might do, unless strictness analysis is smart enough to >> know that the False guard is always, well, False. >> ___ > > GHC.Prim.lazy? It's GHC.Exts.lazy nowadays, and it doesn't have any effect. Neither does the `| False' guard. The only way I found to disable the eager argument evaluation is to pass them in as functions: > parallelize :: Num t => (t -> a) -> (t -> b) -> (a, b) > parallelize a b = let a' = a 1 > b' = b 1 > in (a' `par` (b' `pseq` (a', b'))) Then it can be imported and called like this: > test n1 n2 = let (p1, p2) = parallelize >(\n0-> product $ factors $ product [n0..n1]) >(\n0-> product $ factors $ product [n0..n2]) This solution is incredibly fragile. If the declared type of parallelize is modified by replacing t by Integer, the evaluation becomes eager again. Also, the argument functions can't simply take () for argument which would make this solution reasonable. If this is all the strictness optimizer's fault, I'm awed by how difficult it is to trick it into not doing its job. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
On Sat, 2009-05-23 at 13:31 -0400, Mario Blažević wrote:
> >>> You could probably see exactly what's happening in
> >>> more detail by going through the Core output.
> >>
> >> Thank you, this advice helped. The Core output indicates
> >> that function `test' evaluates the arguments to
> >> `parallelize' before it calls it. In other words, the
> >> call to `parallelize' is optimized as a strict function
> >> call -- which it is. The problem is that this
> >> optimization evaluates the arguments sequentially.
> >> Compiling with optimizations turned off regains the
> >> parallel execution.
> >>
> >> I guess I will report this as a GHC bug. Or is it a
> >> feature request?
> >
> > As Duncan suggessted, try with GHC head (grab a snapshot). `par` et al
> > are much improved.
>
> I already have, with the snapshot from 21st of April. It behaves the same
> as 6.8.2, except it runs for twice as long.
>
> I'd like to take back a part of what I said before, though: `parallelize'
> should
> be strict only in its second argument.
parallelize a b = a `par` (b `pseq` (a, b))
GHC infers that strictness of parallelize. It thinks that it is lazy in
both args (you can check this yourself using ghc --show-iface). That's
because the definitions of par and pseq use the function 'lazy':
-- The reason for the strange "lazy" call is that it fools
-- the compiler into thinking that pseq and par are non-strict in
-- their second argument (even if it inlines pseq at the call site).
-- If it thinks pseq is strict in "y", then it often evaluates
-- "y" before "x", which is totally wrong.
pseq x y = x `seq` lazy y
par x y = case (par# x) of { _ -> lazy y }
So GHC thinks that par is lazy in both arguments, while it thinks pseq
is strict in the first and lazy in the second.
> Its strictness in the first argument should be the same as with `par`.
Yes, which it is.
> Even though `parallelize x y' always evaluates both x and y,
Be careful about what you mean. Yes, it starts the evaluation of x in
parallel with y, but that does not mean it is strict in x, as you notice
with your example of undefined below.
> the following test works fine with optimizations even if `parallelize'
> is imported:
>
> main = putStrLn (snd $ parallelize undefined "Hello, World!")
>
> So the function is not strict, and I don't understand why GHC should evaluate
> the
> arguments before the call.
Right, it's lazy in the first and strict in the second argument. As far
as I can see we have no evidence that is is evaluating anything before
the call.
> Does anybody know of a pragma or another way to make a function *non-strict*
> even
> if it does always evaluate its argument? In other words, is there a way to
> selectively disable the strictness optimization?
Yes, which is what pseq and par already do.
If there's a bug, we need to reproduce it and report it. I cannot
reproduce it.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern match question in HAXML code
On 24 May 2009, at 01:19, Max Cantor wrote:
Going through the instances for HTypeable (http://www.haskell.org/HaXml/HaXml/src/Text/XML/HaXml/TypeMapping.html#toHType
) I saw the following instance for Either a b.
My question is, why doesn't the pattern match in the where clause
always fail? If (Left x) = m does not fail, doesn't that imply that
m is a Left x and therefore the (Right y) = m should fail?
It does; at least one of x and y is (_|_). However, toHType function
doesn't really need it's argument; all that is needed is the type of
an argument. Therefore, toHType is quite happy to receive (_|_) as an
argument - so, hx and hy are well-defined.
thanks, max
instance (HTypeable a, HTypeable b) => HTypeable (Either a b) where
toHType m = Defined "Either" [hx, hy]
[ Constr "Left" [hx] [hx] {-Nothing-}
, Constr "Right" [hy] [hy] {-Nothing-}]
where (Left x) = m
(Right y) = m
hx = toHType x
hy = toHType y
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Computer Language Benchmarks Game: pidigits
That's fixed in GHC 6.10.2 + though, IIRC. arnaud.payement: > By the way, I did submit my solution. It improved the score a bit but it > is still very memory hungry. > > > - Original Message - From: "Don Stewart" > To: "Matthias Görgens" > Cc: "Arnaud Payement" ; > > Sent: Saturday, May 23, 2009 10:16 PM > Subject: Re: [Haskell-cafe] The Computer Language Benchmarks Game: pidigits > > >> matthias.goergens: >>> Hi, >>> >>> By the way: Would it be considered good style to include QuickTest >>> properties into the pidigit submission? >>> >> >> Not in the submission, no. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Computer Language Benchmarks Game: pidigits
By the way, I did submit my solution. It improved the score a bit but it is still very memory hungry. - Original Message - From: "Don Stewart" To: "Matthias Görgens" Cc: "Arnaud Payement" ; Sent: Saturday, May 23, 2009 10:16 PM Subject: Re: [Haskell-cafe] The Computer Language Benchmarks Game: pidigits matthias.goergens: Hi, By the way: Would it be considered good style to include QuickTest properties into the pidigit submission? Not in the submission, no. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 119 - May 23, 2009
--- Haskell Weekly News http://sequence.complete.org/hwn/20090523 Issue 119 - May 23, 2009 --- Welcome to issue 119 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements GHC porting works again. Ian Lynagh [2]announced that the [3]instructions for porting GHC to a new architecture now work again with the HEAD. If you get stuck when trying to do a port, feel free to ask on cvs-ghc at haskell.org or in #ghc on freenode. 6.10.4 plans. Ian Lynagh [4]announced plans for a 6.10.4 bugfix release of GHC. If you know of any bugs that you think should be looked into for 6.10.4, please let the development team know. The Timber compiler 1.0.3. Johan Nordlander [5]announced the release of version 1.0.3 of the Timber compiler. Timber is a modern language for building event-driven systems, based around the notion of reactive objects. It is also a purely functional language derived from Haskell, although with a strict evaluation semantics. 1.0.3 is a bug fix release, paving the way for future feature releases. mathlink-2.0.0.3. Tracy Wadleigh [6]announced the release of [7]mathlink, a library for writing Mathematica packages in Haskell. One simply writes some functions of type (MLGet a, MLPut b) => a -> IO b and provides a package specification in a simple DSL; the result is a program that exposes functions that can be called from Mathematica. text 0.2, fast and comprehensive Unicode support using stream fusion. Bryan O'Sullivan [8]announced the availability of [9]text 0.2, an efficient Unicode text library that uses stream fusion. New and notable in this release is support for lazy, chunked text, so you can process text files far larger than memory using a small footprint. Haskell Hackathon in Philadelphia. Brent Yorgey [10]announced Hac phi, a Haskell hackathon to be held in Philadelphia in July. Check out the [11]wiki page and add your name if you are interested in attending! More details to follow soon. feed2twitter 0.2 & hackage2twitter 0.2.1. Tom Lokhorst [12]announced the first release of [13]feed2twitter, a library for sending posts from a news feed to Twitter. EsotericBot 0.0.1. spoon [14]announced the release of [15]Esotericbot, a sophisticated, lightweight IRC bot, written in Haskell. atom 0.0.4. Tom Hawkins [16]announced a new release of [17]atom; this version adds an array datatype (A a). Hieroglyph-2.21 and buster, buster-gtk, and buster-network-2.0. Jeff Heard [18]announced new releases of [19]Hieroglyph, [20]buster, [21]buster-gtk, and [22]buster-network, with tons of changes; read Jeff's original announcement for details. TxtSushi 0.1. Keith Sheppard [23]announced the first version of [24]TxtSushi, a collection of command line utilities for processing tab-delimited and CSV files. It includes a utility for doing SQL SELECTs on flat files. Discussion Should exhaustiveness testing be on by default? Don Stewart started a [25]discussion, prompted by a [26]recent blog post, on whether coverage checking should be on by default, and other issues relating to compiler warnings and coding style. Proposal on the platform API policy question. Duncan Coutts [27]proposed a general policy for Haskell Platform release cycles and versioning, based on input from previous discussions. the problem of design by negation. Michael Mossey began a [28]discussion on software design philosophies. "Design by negation" considered harmful? Haskell in 3 Slides. John Van Enk [29]asked for ideas on a 3 to 4 slide introduction to Haskell. What do YOU think should be on those slides? Blog noise [30]Haskell news from the [31]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Bryan O'Sullivan: [32]Streaming Unicode support for Haskell: text 0.2. * Alex McLean: [33]Haskell hack. Music generation in Haskell. * Well-Typed.Com: [34]Building plugins as Haskell shared libs. A sneak preview of building Haskell shared libraries on Linux. * LHC Team: [35]New release: LHC 0.8. * Mark Wassell: [36]Grapefruit And Glade. * Conal Elliott: [37]The C language is purely functional. * >>> Will Donnelly: [38]Haskell: A Pretty Nice Language. * FP-Syd: [39]Sydney FP Group: FP-Syd #14.. * Dan Piponi (sigfpe): [40]Trace Diagrams with Monads. Quotes of the Week * roconnor: Damn it, I don't know how to make this as slow as python. * koeien: Let's register it [monomorphismrestriction.com] to prevent it from being used ;) * Elly: Rule 1 of malloc is the same as rule 1 of air travel: &quo
[Haskell-cafe] Pattern match question in HAXML code
Going through the instances for HTypeable (http://www.haskell.org/HaXml/HaXml/src/Text/XML/HaXml/TypeMapping.html#toHType
) I saw the following instance for Either a b.
My question is, why doesn't the pattern match in the where clause
always fail? If (Left x) = m does not fail, doesn't that imply that m
is a Left x and therefore the (Right y) = m should fail?
thanks, max
instance (HTypeable a, HTypeable b) => HTypeable (Either a b) where
toHType m = Defined "Either" [hx, hy]
[ Constr "Left" [hx] [hx] {-Nothing-}
, Constr "Right" [hy] [hy] {-Nothing-}]
where (Left x) = m
(Right y) = m
hx = toHType x
hy = toHType y
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Computer Language Benchmarks Game: pidigits
matthias.goergens: > Hi, > > By the way: Would it be considered good style to include QuickTest > properties into the pidigit submission? > Not in the submission, no. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ICFP Participation
At Sat, 23 May 2009 19:31:42 +0200, Matthias Görgens wrote: > > Hello, > > Please pardon my naive question: Is there a way to sign on for ICFP > 09? The homepage (http://www.cs.nott.ac.uk/~gmh/icfp09.html) only > seems to mention how to submit papers. Is there a way to attend as a > mere participant? I believe the ICFP 2009 programming competition this year is going to be to implement the attendee registration page... - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Computer Language Benchmarks Game: pidigits
Hi, By the way: Would it be considered good style to include QuickTest properties into the pidigit submission? Matthias. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ICFP Participation
matthias.goergens: > > Registration will be open soon. > > Thanks. > > (I could have written an Experience Report about how I am using > Haskell at Deutsche Bahn, but that deadlines had already passed.) You could add a brief abstract to: http://haskell.org/haskellwiki/Haskell_in_industry As a starting point. And apply to give a talk at CUFP (actually, the deadline has passed :/) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ICFP Participation
> Registration will be open soon. Thanks. (I could have written an Experience Report about how I am using Haskell at Deutsche Bahn, but that deadlines had already passed.) Matthias. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
On Sat, May 23, 2009 at 11:34 AM, Max Rabkin wrote: > On Sat, May 23, 2009 at 7:31 PM, Mario Blažević wrote: >> Does anybody know of a pragma or another way to make a function *non-strict* >> even >> if it does always evaluate its argument? In other words, is there a way to >> selectively disable the strictness optimization? > > parallelize a b | False = (undefined, undefined) > | otherwise = a `par` (b `pseq` (a, b)) > > might do, unless strictness analysis is smart enough to know that the > False guard is always, well, False. > > --Max > ___ GHC.Prim.lazy? Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Extensible Exceptions and IO
On Sat, May 23, 2009 at 9:09 AM, Ian Lynagh wrote: > On Sat, Apr 25, 2009 at 11:18:43AM -0700, Alexander Dunlap wrote: >> In the extensible exceptions paper[1], which I believe is the guide >> behind the current Control.Exception in GHC 6.10, a SomeIOException >> type is discussed so that it would be possible to use the nice >> interface for IOExceptions. Is this implemented anywhere? In the GHC >> libraries, all I see is the old interface just plugged into a simple >> wrapper, so you have to use guard . isDoesNotExistError (for example) >> with catchJust to catch a certain type of exception. If not, are there >> any plans to implement it? > > I'm not aware of anyone currently working on putting the various core > libs' exceptions into a sensible hierarchy, but it would be great if > someone was to do so! > > I'd suggest that the best way to do this would be initially a > combination of discussions on the mailing list (if anything is > non-obvious) and building a design (and, if appropriate, rationale) on a > wiki page, and ending with a library submissions proposal once you have > a design worked out: > > http://www.haskell.org/haskellwiki/Library_submissions > > > Thanks > Ian > > I'm moving this from the GHC users' mailing list to the haskell-cafe mailing list because I think the discussion probably involves the entire Haskell community. Hi all, We have this new exception hierarchy in GHC base-4 and a lot of new machinery for dealing with it. Other libraries also seem to be springing up to provide alternative methods of dealing with these new exceptions. However, I have found that in most of my programming, the new exception functionality cannot be used to its fullest extent because the exceptions in the core libraries are not part of any sensible "tree" of exceptions, even though having this giant exception tree seems to be one of the premises of the new exception library. For example, there is an ArithException type in Control.Exception which records various arithmetic exceptions. However, there are two problems: (1) in order to fit in with the extensible exceptions theme, the type ought to be called SomeArithException and all of the types of ArithExceptions ought to be sub-exceptions of it, and (2) to my knowledge, this exception type doesn't seem to be thrown by anything in the base libraries. I think the biggest culprit is the IOException type, which also happens to be probably the most commonly-used exception type, since exceptions from IOException cannot really be anticipated and prevented. The current design of IOException is as follows. There is an abstract type called IOException. This can be queried with functions like isDoesNotExistError (which determines if the exception is because a file did not exist). Furthermore, to make an IOException, one has to use the mkIOError function, which takes a value of type IOErrorType, which is again an abstract type. I believe the reason for the abstract types is to allow implementations to extend the range of exceptions. Unfortunately, this has even more problems. For example, the error returned by using readFile on a directory cannot be determined using any Haskell98 function, meaning that code that wants to detect this error cannot be portable to compilers that don't have the new InappropriateType IO exception. The biggest problem with the current design of IOException, however, is that it doesn't play very nicely with the main hierarchy. Like with ArithExceptions, there should be a SomeIOException type. http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf, which was the original paper on extensible exceptions, recommends having a class for IOExceptions that would allow us to get standard information from any specific IOException. I asked the GHC-users mailing list about this and Ian Lynagh recommended starting a discussion about how to put all of the core library exceptions into a sensible hierarchy. I think the goals here ought to be to make our new hierarchy as backward-compatible as possible. In particular, since many programs rely on the isWhateverError functionality, it would be nice to keep these in place. For IOExceptions, I think it would be nice to have a more multi-layered hierarchy than just SomeIOException and its subtypes. For example, I could see a hierarchy for IOExceptions looking something like this: SomeIOException - SomeCouldNotOpenException - AlreadyExists, NoSuchThing, PermissionDenied, InappropriateType - SomeResourceException - ResourceBusy, ResourceExhausted, ResourceVanished etc. I'm not all that familiar with the various exceptions and how they are used, so I'm not really able to propose a complete hierarchy for all the exceptions. I guess the purpose of this email was just to start off a discussion about what our exception hierarchy ought to look like. Thanks for reading this (admittedly long) message. Alex ___ Haskell-Cafe mailing list Haskell-Caf
Re: [Haskell-cafe] Data.Binary suboptimal instance
Khudyakov Alexey schrieb: On Saturday 23 May 2009 02:55:17 Antoine Latter wrote: Or you could go for the compromise position, where the list can be part of a complex data structure so you're not relying on EOF to find the end. Interesting solution however it does not perform very nice. I wrote microbenchmark xs :: [Word32] xs = [1..(10^6)] Writing chunked list of Word32 B.writeFile "chunked" . toLazyByteString . putList putWord32be $ xs real0m4.311s user0m3.272s sys 0m0.096s Reading chunked list of Word32 print . last . runGet (getList getWord32be) =<< B.readFile "chunked" real0m0.634s user0m0.496s sys 0m0.012s Writing stream of Word32 B.writeFile "stream" . encodeStream $ xs real0m0.391s user0m0.252s sys 0m0.020s Reading stream of Word32 print . (last :: [Word32] -> Word32) . decodeStream =<< B.readFile "stream" real0m0.376s user0m0.248s sys 0m0.020s I didn'd do any profiling so I have no idea why writing is so slow. If you use top-level definition 'xs' the program might cache the list and second write is faster. You may change the order of tests in order check, whether that is the cause. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary suboptimal instance
Khudyakov Alexey schrieb:
> On Saturday 23 May 2009 20:00:25 Henning Thielemann wrote:
>> I think the list should be avoided at all costs, because it is so slow.
>> I don't know if it is fused away by clever optimizer rules in the binary
>> package. Anyway, you can treat a Builder like a list. Just replace (++)
>> by 'mappend' and [] by 'mempty'.
>>
>> It should work like this:
>>
>>do a <- getWord8
>> b <- getWord8
>> return $ Builder.singleton a `mappend` Builder.singleton b
>>
>
> It worked for me pretty well. Profiling shown that in my program
> {get,put}Stream functions takes less than 1% of execution time.
> I don't know which tricks ghc used.
>
> I think code with list is more clear. Another problem that you can't use
> existing Binary instances with Builder.
You can since there is
http://hackage.haskell.org/packages/archive/binary/0.5.0.1/doc/html/Data-Binary-Put.html#v%3AexecPut
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
On Sat, May 23, 2009 at 7:31 PM, Mario Blažević wrote: > Does anybody know of a pragma or another way to make a function *non-strict* > even > if it does always evaluate its argument? In other words, is there a way to > selectively disable the strictness optimization? parallelize a b | False = (undefined, undefined) | otherwise = a `par` (b `pseq` (a, b)) might do, unless strictness analysis is smart enough to know that the False guard is always, well, False. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ICFP Participation
matthias.goergens: > Hello, > > Please pardon my naive question: Is there a way to sign on for ICFP > 09? The homepage (http://www.cs.nott.ac.uk/~gmh/icfp09.html) only > seems to mention how to submit papers. Is there a way to attend as a > mere participant? > Registration will be open soon. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ICFP Participation
Hello, Please pardon my naive question: Is there a way to sign on for ICFP 09? The homepage (http://www.cs.nott.ac.uk/~gmh/icfp09.html) only seems to mention how to submit papers. Is there a way to attend as a mere participant? Thanks, Matthias. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
>>> You could probably see exactly what's happening in >>> more detail by going through the Core output. >> >> Thank you, this advice helped. The Core output indicates >> that function `test' evaluates the arguments to >> `parallelize' before it calls it. In other words, the >> call to `parallelize' is optimized as a strict function >> call -- which it is. The problem is that this >> optimization evaluates the arguments sequentially. >> Compiling with optimizations turned off regains the >> parallel execution. >> >> I guess I will report this as a GHC bug. Or is it a >> feature request? > > As Duncan suggessted, try with GHC head (grab a snapshot). `par` et al > are much improved. I already have, with the snapshot from 21st of April. It behaves the same as 6.8.2, except it runs for twice as long. I'd like to take back a part of what I said before, though: `parallelize' should be strict only in its second argument. Its strictness in the first argument should be the same as with `par`. Even though `parallelize x y' always evaluates both x and y, the following test works fine with optimizations even if `parallelize' is imported: main = putStrLn (snd $ parallelize undefined "Hello, World!") So the function is not strict, and I don't understand why GHC should evaluate the arguments before the call. Does anybody know of a pragma or another way to make a function *non-strict* even if it does always evaluate its argument? In other words, is there a way to selectively disable the strictness optimization? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary suboptimal instance
On Saturday 23 May 2009 20:00:25 Henning Thielemann wrote:
> I think the list should be avoided at all costs, because it is so slow.
> I don't know if it is fused away by clever optimizer rules in the binary
> package. Anyway, you can treat a Builder like a list. Just replace (++)
> by 'mappend' and [] by 'mempty'.
>
> It should work like this:
>
>do a <- getWord8
> b <- getWord8
> return $ Builder.singleton a `mappend` Builder.singleton b
>
It worked for me pretty well. Profiling shown that in my program
{get,put}Stream functions takes less than 1% of execution time.
I don't know which tricks ghc used.
I think code with list is more clear. Another problem that you can't use
existing Binary instances with Builder.
--
Best regards Khudyakov Alexey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Data.Binary suboptimal instance
On Saturday 23 May 2009 02:55:17 Antoine Latter wrote: > Or you could go for the compromise position, where the list can be > part of a complex data structure so you're not relying on EOF to find > the end. > Interesting solution however it does not perform very nice. I wrote microbenchmark > xs :: [Word32] > xs = [1..(10^6)] Writing chunked list of Word32 > B.writeFile "chunked" . toLazyByteString . putList putWord32be $ xs real0m4.311s user0m3.272s sys 0m0.096s Reading chunked list of Word32 > print . last . runGet (getList getWord32be) =<< B.readFile "chunked" real0m0.634s user0m0.496s sys 0m0.012s Writing stream of Word32 > B.writeFile "stream" . encodeStream $ xs real0m0.391s user0m0.252s sys 0m0.020s Reading stream of Word32 > print . (last :: [Word32] -> Word32) . decodeStream =<< B.readFile "stream" real0m0.376s user0m0.248s sys 0m0.020s I didn'd do any profiling so I have no idea why writing is so slow. -- Best regard Khudyakov Alexey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
mblazevic:
>
> On Fri 22/05/09 10:51 AM , John Lato jwl...@gmail.com sent:
> > Hi Mario,
> >
> > It looks like the parallelize function is getting inlined when it's in
> > the same file, but not when it's in a separate file.
> >
> > Adding a {-# INLINE parallelize #-} pragma to the module with
> > parallelize recovers all the performance for me.
> >
> > You could probably see exactly what's happening in more detail by
> > going through the Core output.
>
>
> Thank you, this advice helped. The Core output indicates that function `test'
> evaluates the arguments to `parallelize' before it calls it. In other words,
> the
> call to `parallelize' is optimized as a strict function call -- which it is.
> The
> problem is that this optimization evaluates the arguments sequentially.
> Compiling
> with optimizations turned off regains the parallel execution.
>
> I guess I will report this as a GHC bug. Or is it a feature request?
As Duncan suggessted, try with GHC head (grab a snapshot). `par` et al
are much improved.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary suboptimal instance
Khudyakov Alexey schrieb: > On Friday 22 May 2009 23:34:50 Henning Thielemann wrote: >>> So lately I've been working on a little program to generate trippy >>> graphics. (Indeed, some of you may remember it from a few years back...) >>> Anyway, getting to the point, I just restructured my program. As part of >>> the restructuring, I got rid of all the jiggery-pokery with >>> Data.Array.Storable and so forth and decided to use Data.Binary. >>> >>> My first problem was quite simple. I want to write a program that reads >>> an item from the input file, processes it, writes it to the output file, >>> and repeats until the input file is empty. Data.Binary doesn't appear to >>> provide any obvious way to do this. You can't be in the Get and Put >>> monads simultaneously, and I can't figure out how to interleave them. >> You can! - It's again time to point out that Put shouldn't be a monad, but >> a monoid. But as it is, Put is a Writer monad on top of the Builder >> monoid. Better use that Builder monoid directly. > > Could you elaborate? I didn't quite understand. > > > Anyway I had similar problem and simply wrote few functions. They > encode/decode values of same type element by element. It's lazy enough so > code > could be written in following style: > >> process :: [Foo] -> [Bar] >> >> foo = readFile name >>>>= writeFile out . encodeStream . process . decodeProcess > > There is a code. It is fast and worked for me without a problem. > >> -- | Decode records in repetition >> decodeStream :: Binary a => ByteString -> [a] >> decodeStream = runGet (getStream get) >> >> -- | Encode list of records as bytestring >> encodeStream :: Binary a => [a] -> ByteString >> encodeStream = runPut . putStream put I think the list should be avoided at all costs, because it is so slow. I don't know if it is fused away by clever optimizer rules in the binary package. Anyway, you can treat a Builder like a list. Just replace (++) by 'mappend' and [] by 'mempty'. It should work like this: do a <- getWord8 b <- getWord8 return $ Builder.singleton a `mappend` Builder.singleton b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A problem with par and modules boundaries...
duncan.coutts:
> On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote:
> > Answer recorded at:
> >
> > http://haskell.org/haskellwiki/Performance/Parallel
>
> I have to complain, this answer doesn't explain anything. This isn't
> like straight-line performance, there's no reason as far as I can see
> that inlining should change the operational behaviour of parallel
> evaluation, unless there's some mistake in the original such as
> accidentally relying on an unspecified evaluation order.
>
> Now, I tried the example using two versions of ghc and I get different
> behaviour from what other people are seeing. With the original code, (ie
> parallelize function in the same module) with ghc-6.10.1 I get no
> speedup at all from -N2 and with 6.11 I get a very good speedup (though
> single threaded performance is slightly lower in 6.11)
>
> Original code
> ghc-6.10.1, -N1 -N2
> real0m9.435s0m9.328s
> user0m9.369s0m9.249s
>
> ghc-6.11, -N1 -N2
> real0m10.262s 0m6.117s
> user0m10.161s 0m11.093s
>
> With the parallelize function moved into another module I get no change
> whatsoever. Indeed even when I force it *not* to be inlined with {-#
> NOINLINE parallelize #-} then I still get no change in behaviour (as
> indeed I expected).
>
> So I view this advice to force inlining with great suspicion (at worst
> it encourages people not to think and to look at it as magic). That
> said, why it does not get any speedup with ghc-6.10 is also a mystery to
> me (there's very little GC going on).
>
> Don: can we change the advice on the wiki please? It currently makes it
> look like a known and understood issue. If anything we should suggest
> using a later ghc version.
Please do so. Especially if GHC HEAD *does the right thing*. Then the
advice should be first: upgrade to GHC HEAD.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell programmers in São Carlo s - SP - Brazil?
Hey, we have enough people for a São Paulo Haskell User Group. Anyone else interested? Best regards, Daniel Yokomizo 2009/5/21 Fernando Henrique Sanches : > São Caetano, SP, Brazil - right next to São Paulo. UFABC Student. > > Fernando Henrique Sanches > > > 2009/5/19 Maurício >> >> Anybody else around here? >> >> Best, >> Maurício >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A problem with par and modules boundaries...
Am Samstag 23 Mai 2009 13:06:04 schrieb Duncan Coutts: > On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote: > > > That's great, thank you. I am still baffled, though. > > I'm baffled too! I don't see the same behaviour at all (see the other > email). > > > > Must every exported function that uses `par' be INLINEd? Does every > > > exported caller of such a function need the same treatment? > > It really should not be necessary. > > > > Is `par' really a macro, rather than a function? > > It's a function. > > > As far as I understand, par doesn't guarantee that both arguments are > > evaluated in parallel, it's just a suggestion to the compiler, and if > > whatever heuristics the compiler uses say it may be favourable to do > > it in parallel, it will produce code to calculate it in parallel > > (given appropriate compile- and run-time flags), otherwise it produces > > purely sequential code. > > > > With parallelize in a separate module, when compiling that, the > > compiler has no way to see whether parallelizing the computation may > > be beneficial, so doesn't produce (potentially) parallel code. At the > > use site, in the other module, it doesn't see the 'par', so has no > > reason to even consider producing parallel code. > > I don't think this is right. As I understand it, par always creates a > spark. It has nothing to do with heuristics. Quite possible. I was only guessing from the fact that sometimes par evaluates things in parallel and sometimes not, plus when thinking what might cause the described behaviour, cross-module inlining came to mind, I tried adding an INLINE pragma and it worked - or so it seemed. Then I threw together an explanation of the observed behaviour. That explanation must be wrong, though, see below. > > Whether the spark actually gets evaluated in parallel depends on the > runtime system and whether the spark "fizzles" before it gets a chance > to run. Of course when using the single threaded rts then the sparks are > never evaluated in parallel. With the threaded rts and given enough > CPUs, the rts will try to schedule the sparks onto idle CPUs. This > business of getting sparks running on other CPUs has improved > significantly since ghc-6.10. The current development version uses a > better concurrent queue data structure to manage the spark pool. That's > probably the underlying reason for why the example works well in > ghc-6.11 but works badly in 6.10. I'm afraid I'm not sure of what > exactly is going wrong that means it doesn't work well in 6.10. I have tried with 6.10.3 and 6.10.1, with parallelize in the same module and in a separate module - with no pragma - with an INLINE pragma - with a NOINLINE pragma 6.10.1 did not parallelize in any of these settings 6.10.3 parallelized in all these settings except "separate module, no pragma". Then I tried a few other settigns with 6.10.3, got parallel evaluation if there's an INLINE or a NOINLINE pragma on parallelize, or the module header of Main is module Main (main) where, not if Main exports all top level definitions and parallelize is neither INLINEd nor NOINLINEd. Weird. > > Generally I'd expect the effect of par to be pretty insensitive to > inlining. I'm cc'ing the ghc users list so perhaps we'll get some expert > commentary. That would be good. > > Duncan > Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
On Fri 22/05/09 10:51 AM , John Lato jwl...@gmail.com sent:
> Hi Mario,
>
> It looks like the parallelize function is getting inlined when it's in
> the same file, but not when it's in a separate file.
>
> Adding a {-# INLINE parallelize #-} pragma to the module with
> parallelize recovers all the performance for me.
>
> You could probably see exactly what's happening in more detail by
> going through the Core output.
Thank you, this advice helped. The Core output indicates that function `test'
evaluates the arguments to `parallelize' before it calls it. In other words, the
call to `parallelize' is optimized as a strict function call -- which it is. The
problem is that this optimization evaluates the arguments sequentially.
Compiling
with optimizations turned off regains the parallel execution.
I guess I will report this as a GHC bug. Or is it a feature request?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A problem with par and modules boundaries...
On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote: > > That's great, thank you. I am still baffled, though. I'm baffled too! I don't see the same behaviour at all (see the other email). > > Must every exported function that uses `par' be INLINEd? Does every > > exported caller of such a function need the same treatment? It really should not be necessary. > > Is `par' really a macro, rather than a function? It's a function. > As far as I understand, par doesn't guarantee that both arguments are > evaluated in parallel, it's just a suggestion to the compiler, and if > whatever heuristics the compiler uses say it may be favourable to do > it in parallel, it will produce code to calculate it in parallel > (given appropriate compile- and run-time flags), otherwise it produces > purely sequential code. > > With parallelize in a separate module, when compiling that, the > compiler has no way to see whether parallelizing the computation may > be beneficial, so doesn't produce (potentially) parallel code. At the > use site, in the other module, it doesn't see the 'par', so has no > reason to even consider producing parallel code. I don't think this is right. As I understand it, par always creates a spark. It has nothing to do with heuristics. Whether the spark actually gets evaluated in parallel depends on the runtime system and whether the spark "fizzles" before it gets a chance to run. Of course when using the single threaded rts then the sparks are never evaluated in parallel. With the threaded rts and given enough CPUs, the rts will try to schedule the sparks onto idle CPUs. This business of getting sparks running on other CPUs has improved significantly since ghc-6.10. The current development version uses a better concurrent queue data structure to manage the spark pool. That's probably the underlying reason for why the example works well in ghc-6.11 but works badly in 6.10. I'm afraid I'm not sure of what exactly is going wrong that means it doesn't work well in 6.10. Generally I'd expect the effect of par to be pretty insensitive to inlining. I'm cc'ing the ghc users list so perhaps we'll get some expert commentary. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A problem with par and modules boundaries...
On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote:
> Answer recorded at:
>
> http://haskell.org/haskellwiki/Performance/Parallel
I have to complain, this answer doesn't explain anything. This isn't
like straight-line performance, there's no reason as far as I can see
that inlining should change the operational behaviour of parallel
evaluation, unless there's some mistake in the original such as
accidentally relying on an unspecified evaluation order.
Now, I tried the example using two versions of ghc and I get different
behaviour from what other people are seeing. With the original code, (ie
parallelize function in the same module) with ghc-6.10.1 I get no
speedup at all from -N2 and with 6.11 I get a very good speedup (though
single threaded performance is slightly lower in 6.11)
Original code
ghc-6.10.1, -N1 -N2
real 0m9.435s0m9.328s
user 0m9.369s0m9.249s
ghc-6.11, -N1 -N2
real 0m10.262s 0m6.117s
user 0m10.161s 0m11.093s
With the parallelize function moved into another module I get no change
whatsoever. Indeed even when I force it *not* to be inlined with {-#
NOINLINE parallelize #-} then I still get no change in behaviour (as
indeed I expected).
So I view this advice to force inlining with great suspicion (at worst
it encourages people not to think and to look at it as magic). That
said, why it does not get any speedup with ghc-6.10 is also a mystery to
me (there's very little GC going on).
Don: can we change the advice on the wiki please? It currently makes it
look like a known and understood issue. If anything we should suggest
using a later ghc version.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] import qualified?
Am Samstag 23 Mai 2009 08:08:42 schrieb Vasili I. Galchin: > Hi Paulo, > > You are teasing me ;^) So what is the "semantics" of "import qualified > Blah"? > > Regards, > > Vasili The qualified names (Blah.foo, Blah.baz) are in scope, but not the unqualified names foo, baz. If you import qualified Bing.Bong.Blah.Blub as Blub the names of Blub are in scope in the fully qualified form Bing.Bong.Blah.Blub.foo and the shorter Blub.foo without the 'as Blub', only the fully qualified form is in scope. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
