- Haskell-prime - Haskell.org

RE: The dreaded M-R
by Simon Marlow 02 Feb '06

02 Feb '06

On 31 January 2006 17:48, Andrew Pimlott wrote: > On Tue, Jan 31, 2006 at 10:17:57AM -0000, Simon Marlow wrote: >> On 30 January 2006 21:49, Andrew Pimlott wrote: >>> In the present case, people aren't (only) opposing the M-R out of >>> principle, but because they actually use overloaded variable >>> definitions and (at least sometimes) want to leave off the >>> signature. >>> >>> So I don't see how one could claim, as on the wiki, the warning >>> "wouldn't happen much". I suspect it would happen, and annoy >>> people, and defeat the reason that people want to remove the M-R. >> >> The assertion that it "wouldn't happen much" is based on the >> observation earlier in this thread that it was actually difficult to >> write some code that illustrated the problem. > > This indicates that the warning "wouldn't happen much" _when you want > sharing_. But it would happen all the time when you don't want > sharing, eg. in the case Malcolm Wallace just posted. So you either add a type signature, or turn off the warning. What's the problem? I suspect you're saying that you don't want a warning by default, and you don't want the langage to recommend that compilers issue a warning by default, right? If so, your objection is duly noted and I'll add the point to the wiki. Cheers, Simon

2 1

ClassMethodTypes
by Ross Paterson 01 Feb '06

01 Feb '06

As I read it, the POPL'05 paper cited by the wiki page asserts that there is a problem, but does not explain what it is. Is there a better reference?

2 1

RE: Test performance impact (was: The dreaded M-R)
by Simon Marlow 01 Feb '06

01 Feb '06

On 01 February 2006 11:42, Nils Anders Danielsson wrote: > However, to stand on more solid ground I suggest that someone runs > some performance tests, with and without > -fno-monomorphism-restriction, to see whether the M-R has any great > impact in practice. There are some performance test suites based on > real code out there, right? Nofib? Results below (ignore runtime differences, I was averaging over 5 runs but most of these benchmarks run too quickly to get any reasonable measurements). Summary: 2 programs failed to compile due to type errors (anna, gg). One program did 19% more allocation, a few other programs increased allocation very slightly (<2%). ------------------------------------------------------------------------ -------- Program Size Allocs Runtime ------------------------------------------------------------------------ -------- anna ----- ----- ----- ansi +0.00% +0.00% 0.00 atom +0.00% +0.00% -2.92% awards +0.00% +0.00% 0.00 banner +0.00% +0.00% 0.00 bernouilli -0.23% +0.00% -7.44% boyer +0.00% +0.00% 0.00 boyer2 +0.00% +0.00% 0.01 bspt +0.00% +0.00% 0.02 cacheprof +0.14% +0.00% -9.86% calendar +0.00% +0.00% 0.00 cichelli +0.00% +0.00% +0.99% circsim +0.00% +0.00% -0.93% clausify +0.00% +0.00% 0.01 comp_lab_zift +0.00% +0.00% +1.86% compress +0.00% +0.00% -5.58% compress2 +0.00% +0.00% -7.63% constraints +0.00% +0.00% -9.03% cryptarithm1 +0.00% +0.00% -6.27% cryptarithm2 +0.00% +0.00% 0.03 cse +0.00% +0.00% 0.00 eliza +0.00% +0.00% 0.00 event +0.00% +0.00% -7.04% exp3_8 +0.00% +0.00% -10.84% expert +0.00% +0.00% 0.00 fem +0.35% +1.76% 0.06 fft +0.00% +0.00% 0.08 fft2 +0.00% +0.00% 0.15 fibheaps +0.00% +0.00% 0.08 fish +0.00% +0.00% 0.03 fluid +0.12% +0.04% 0.02 fulsom -0.14% +0.00% -2.10% gamteb +2.47% +0.56% 0.15 gcd +0.00% +0.00% -5.88% gen_regexps +0.00% +0.00% 0.00 genfft +0.00% +0.00% 0.04 gg ----- ----- ----- grep +0.00% +0.00% 0.00 hidden +0.00% +0.00% -12.48% hpg +0.00% +0.00% -7.92% ida +0.00% +0.00% -12.50% infer +0.00% +0.00% 0.13 integer +0.00% +0.00% -9.81% integrate +0.00% +0.00% -5.47% knights +0.19% +0.00% 0.01 lcss +0.00% +0.00% -7.42% life +0.75% +0.00% -16.22% lift +0.00% +0.00% 0.00 listcompr +0.00% +0.00% -9.76% listcopy +0.00% +0.00% -8.33% maillist +0.00% +0.03% 0.06 mandel +0.00% +0.00% +0.00% mandel2 +0.00% +0.00% 0.02 minimax +0.00% +0.00% 0.01 mkhprog +0.00% +0.00% 0.00 multiplier +0.00% +0.00% -10.43% nucleic2 +0.61% (stdout) (stdout) para +0.00% +0.00% -2.51% paraffins +0.00% +0.00% -10.07% parser +0.00% +0.00% 0.06 parstof +0.00% +0.00% 0.01 pic +0.28% +19.27% 0.02 power +0.29% +0.00% -11.62% pretty +0.00% +0.00% 0.00 primes +0.00% +0.00% 0.13 primetest +0.00% +0.00% +0.77% prolog +0.00% +0.00% 0.00 puzzle +0.00% +0.00% -5.03% queens +0.00% +0.00% 0.06 reptile +0.00% +0.00% 0.03 rewrite +0.00% +0.00% 0.00 rfib +0.00% +0.00% 0.04 rsa +0.00% +0.00% 0.06 scc +0.00% +0.00% 0.00 sched +0.00% +0.00% 0.05 scs +0.54% +0.06% -11.14% simple +1.70% +0.00% -4.68% solid +0.00% +0.00% -2.03% sorting +0.00% +0.00% 0.00 sphere +0.06% +0.00% -1.74% symalg +0.00% +0.00% 0.13 tak +0.00% +0.00% 0.02 transform +0.00% +0.00% -7.73% treejoin +0.00% +0.00% -2.70% typecheck +0.00% +0.00% -1.29% veritas +0.12% +0.00% 0.00 wang +0.00% +0.00% -18.99% wave4main +0.00% +0.00% -9.04% x2n1 +0.00% +0.00% -2.84% ------------------------------------------------------------------------ -------- Min -0.23% +0.00% -18.99% Max +2.47% +19.27% +1.86% Geometric Mean +0.08% +0.23% -6.71%

3 2

RE: ~ patterns
by Simon Marlow 31 Jan '06

31 Jan '06

On 27 January 2006 10:50, John Hughes wrote: > I'd be fairly horrified at the removal of ~ patterns. I've used them > to fix very serious space-leaks that would have been awkward to fix > in any other way. You use them to *fix* space leaks? Can you give an example? I'm genuinely surprised and interested - I don't think I've ever seen a case of this before, but I've seen the opposite many times (lazy pattern matching being the cause of space leaks). The reasoning behind removing ~ patterns, for me, is that the number of times they are used doesn't justify stealing the ~ symbol and the extra complexity in the language design, when you can get the same effect with let bindings. With pattern guards there's even less justification for keeping ~, eg. f (a, ~(x:xs)) = e turns into f (a,b) | let (x:xs) = b = e you can translate any equation this way. I would probably write the second form in prefernce to the first, because the strict pattern matches are clearly separated from the lazy. I admit to being slightly biased though, in the type of Haskell programming I do I have almost never needed to use ~. Very occasionally when doing cyclic programming, is all. Cheers, Simon

4 3

RE: The dreaded M-R
by Simon Marlow 31 Jan '06

31 Jan '06

On 26 January 2006 16:07, John Hughes wrote: > Simon Marlow wrote: > >> I wonder if there's an alternative solution along these lines: >> >> - We use ParialTypeSignatures to make bindings monomorphic: >> >> >> http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/PartialTyp >> eSigs >> >> eg. >> >> x :: _ >> x = (+1) >> >> - we make it a static error for a variable bound by a simple pattern >> binding ("x = e") to be overloaded, unless a type signature is >> given. The error message would explain the problem, and how to >> fix it. Alternatively, we make it a strong warning. >> >> It seems to me that the partial type signatures extension provides a >> lot of bang for the buck - it gives us a way out of the MR in >> addition to partial type signatures. >> > I don't like this. Once students start dropping type signatures (which > they do > pretty soon for local variables in where-clauses), they would > sometimes-- unpredictably as far as they're concerned--get an error > message telling them they must put one back in again, but it's enough > to write x :: _. Can > you imagine > explaining to an average student in the first year why they MUST put > in a type signature, but it doesn't need to include a type??? Understood, but what about when the student writes '=' instead of ':=' by mistake - most of the time it'll work! But occasionally they fall foul of the reason we had the MR in the first place. Presumably the compiler should emit a noisy warning, but continue anyway? Won't that be confusing? How about an even simpler solution: *All* pattern and variable bindings are monomorphic unless a type signature is given. I wonder how much code this would break? It can't be too bad, because John is suggesting using := for variable bindings everywhere as a starting point. Also, SML users live with something very similar. How often do we really need polymorphism in a variable or pattern binding? I'm guessing probably not that often, because by far the most common use of polymorphism is in functions. You lose if you write mymap = map or mynil = [] and then try to use those at more than one type, but I'm guessing that's quite rare, and you can still give a type signature. I'd be very interested to tweak this in GHC and see how much code still passes the type checker. Cheers, Simon

13 14

RE: The dreaded M-R
by Simon Marlow 31 Jan '06

31 Jan '06

On 30 January 2006 21:49, Andrew Pimlott wrote: > On Mon, Jan 30, 2006 at 04:45:56PM -0000, Simon Marlow wrote: >> Given the new evidence that it's actually rather hard to demonstrate >> any performance loss in the absence of the M-R with GHC, I'm >> attracted to the option of removing it in favour of a warning. > > I caution against the hope that warnings will contribute to the > solution, whichever side you're on. This is a general argument: > Either the warning is on by default or off. If off, it does no harm, > but doesn't help much either. If on, it either triggers only on code > that is almost certainly wrong (or easily disambiguated), or it > sometimes triggers on perfectly good code. In the former case, it > would be better to make it illegal (or require the disambiguation). > In the latter, nobody likes disabling warnings, so they'll grumble > and change the code instead. > > In the present case, people aren't (only) opposing the M-R out of > principle, but because they actually use overloaded variable > definitions and (at least sometimes) want to leave off the signature. > > So I don't see how one could claim, as on the wiki, the warning > "wouldn't happen much". I suspect it would happen, and annoy people, > and defeat the reason that people want to remove the M-R. The assertion that it "wouldn't happen much" is based on the observation earlier in this thread that it was actually difficult to write some code that illustrated the problem. Nevertheless, I didn't mean to imply that the language would mandate a warning, I'll change the wiki to make this more clear. Cheers, Simon

2 1

Re: The dreaded M-R
by John Hughes 31 Jan '06

31 Jan '06

"Simon Marlow" <simonmar(a)microsoft.com> writes: >> Given the new evidence that it's actually rather hard to demonstrate any >> performance loss in the absence of the M-R with GHC, I'm attracted to >> the option of removing it in favour of a warning. > > As another data point, today for the first time I received an error (not a warning) from ghc about the M-R: Ambiguous type variable `a' in the constraint: `Ord a' arising from use of `Data.Set.insert' at Pretty.hs:28:11-20 Possible cause: the monomorphism restriction applied to the following: addToSet :: a -> Data.Set.Set a -> Data.Set.Set a (bound at Pretty.hs:28:0) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction So, without the M-R or a type signature, my code is OK. The proposal to accept this code but produce an optional warning is (I think) better than the current error. Regards, Malcolm Well, is it OK? From the type-checker's point of view, yes, But have you lost sharing? Have you introduced a space leak, because a seq on one of the occurrences of your variable only forces one instance? Those are the dangers of following the advice to put a type signature in. John

2 1

FW: mr
by Simon Peyton-Jones 31 Jan '06

31 Jan '06

I thought you might be interested in this brief exchange between John and myself. (I was starting from Simon Marlow's idea of pattern binding => monomorphic.) Simon -----Original Message----- From: John Hughes [mailto:rjmh@cs.chalmers.se] Sent: 31 January 2006 14:40 To: Simon Peyton-Jones Subject: Re: mr Simon Peyton-Jones wrote: >John > >How about this: > >A binding for a pattern or variable, that lacks a type signature, is >treated as follows: > >* At top level: polymorphic, but illegal if overloaded >* Nested: monomorphic > >The reason for the difference is that at top level there's no context, >so forcing monomorphic is bad. Whereas for nested bindings it seems >like the right thing to force a signature, which will either resolve the >overloading or declare it. > >Simon > > I can see the attraction--it seems to "do the right thing" in each case. But aesthetically, I think it's ghastly. Now to understand a variable definition, one need not look (through the entire module) to see if it has a type signature, but also look to see whether it is top level or not! Refactoring that moves definitions in and out of where blocks (pretty common!) would also risk introducing type errors. That would be a trap for the unwary (and we were all unwary once upon a time). John

1 0

RE: module system/namespaces: separate with/use, allow local "use"
by Simon Marlow 31 Jan '06

31 Jan '06

On 30 January 2006 09:03, Simon Peyton-Jones wrote: >>> With the module system, we should make a distinction between >>> declaring >>> >>> (1) that we want to use a module >>> (2) how to bring the module's names into scope >> >> Perhaps 'import' should be allowed anywhere among definitions. > > Indeed. Requiring the import clauses to be at the top, and the fixity > declarations, makes them easy to find -- but we don't require that for > type signatures or class declarations etc. It'd be more consistent to > allow imports and fixity declarations anywhere. > > This'd be a backward compatible change, but it's an utterly un-forced > one. It's not something that people complain about much. I vaguely remember suggesting this for Haskell 98 or Haskell 1.4 (can't remember which) but nobody saw the need for it back then. In favour: - simplifies the syntax, more consistent - makes it easier to add a temporary import (eg. imagine using 'trace' for debugging, you can put 'import Debug.Trace' right next to the use, rather than at the top of the module where you'll probably forget about it) - simpler for tools that auto-generate code, or annotate existing code (eg. Happy wants to add imports sometimes) Against: - tools that collect imports have to parse the whole file (eg. GHC's dependency analyser) - can't easily see what is imported on balance, I like the way it is now. (fixity decls are currently allowed anywhere in the module, BTW - I think it was in 1.4 they were restricted to being just below the import decls). Cheers, Simon

4 3

Re: The dreaded M-R
by John Hughes 31 Jan '06

31 Jan '06

Lennart Augustsson wrote: >> On the subject of type signatures, I don't want to >> make them mandatory, but I think they should be strongly >> encouraged. I don't buy the argument that they make >> refactoring programs that much harder. It's still >> very easy to do, the type checker will tell you exactly >> where. :) > It can still be in a LOT of places--far too many for comfort. I'm not making this up--I've experienced severe problems in practice caused by this very point. It depends what kind of code you're working with, of course. I'm not saying type signatures are ALWAYS a problem for refactoring, just that they sometimes are--and that it makes sense to leave it up the programmer whether or not to include them. By the way, you leave out a lot of type signatures too. Your Djinn module contains 29 declarations with type signatures--and 17 without. The 17 are local, but local declarations are precisely those where, without the M-R, a lack of sharing would be most likely to bite. John

6 5