- Haskell-prime - Haskell.org

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

31 Jan '06

On 31 January 2006 00:53, Neil Mitchell wrote: >> Second, a warning about "loss of sharing" may befuddle beginners (who >> are usually not taught to write type signatures at the start). > > Are standards documents the place for prescribing which warnings > should be raised, and under what circumstances? Not prescribing, no. It would be a recommendation. The Haskell 98 report already contains recommendations - see the section on pragmas, for example, and I'm sure there are more examples. Cheers, Simon

2 1

~ patterns
by John Hughes 30 Jan '06

30 Jan '06

>>Personally I think ~ patterns are great, and we are now talking about ! >>patterns, a kind of dual to ~ patterns. So at least I think we should >>un-couple the two discussions. >> >> > >I think so too. Removing ~ patterns seems like a fairly poor idea to >me. Sure, they're not very much explicitly used (though everyone uses >them implicitly in pattern bindings), but when you want them, they can >be fairly important. I think perhaps we just need better coverage of ~ >in the tutorials. Now that I think about it, I rather like the idea of >! patterns as well. They make ~ patterns seem more natural by >contrast. Strictness can on occasion be just as important as laziness, >and this notation makes it more convenient to obtain in simple cases. >How to get a similarly pretty notation for more structured strictness >annotations is a bit of a concern. I wonder whether some of the >Control.Parallel.Strategies library should be more strategically >located? :) > > - Cale > 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. I suppose if lazy pattern matching were provided by some other mechanism, say via let bindings, then I should always in principle be able to translate away a ~ pattern. But the translation will often be much more awkward. Actually, I think it's a much bigger wart that pattern matching in let and where is lazy, and everywhere else is strict, than that we have an operator ~ on patterns with a clean compositional semantics. Way back in the Haskell 98 process I tried to get that changed--so that patterns would be matched strictly EVERYWHERE unless you wrote ~ --but I lost that argument. John

2 1

RE: Removal candidates in patterns
by Simon Peyton-Jones 30 Jan '06

30 Jan '06

I agree that if (n+k) patterns go, then so should k patterns. Both are overloaded, and that's the root of their complexity. Personally I think ~ patterns are great, and we are now talking about ! patterns, a kind of dual to ~ patterns. So at least I think we should un-couple the two discussions. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Olaf Chitil | Sent: 26 January 2006 17:01 | To: haskell-prime(a)haskell.org | Subject: Removal candidates in patterns | | | I am very please to see on the Wiki also a list of removal candidates | and that these include n+k patterns and ~ patterns. | | I'd like to add one pattern to this list of removal candiates: k | patterns, that is, numeric literals. | | Why do I want to get rid of these three patterns? Because all three | caused me no end of trouble when implementing the program transformation | of the Haskell tracer Hat. Hat actually still doesn't handle nested ~ | patterns. | | Why are these patterns so hard to implement for Hat? Surely the Haskell | report gives a translation into simple core Haskell. Well, Hat does not | use this translation because it does not want to be an inefficient | pattern matcher (leave that job to the compiler) but produce a trace of | the Haskell program as it is written. However, both n+k and k patterns | cause calls of functions ( (-), (==) etc) that Hat has to record in its | trace. Also ~ patterns do not fit the simple rewriting semantics of the | Hat trace and hence have to be recorded specially. While in simple cases | that occur in practice it is pretty straightforward to remove n+k, k and | ~ patterns from a larger pattern while keeping the rest of the larger | pattern intact, in the general case this is incredibly hard. | | Iff n+k patterns are removed, there is little good use for k patterns | either. Since the introduction of monadic IO the ~ pattern is hardly | used in practice either. In all the simple cases that these three are | currently used in practice, it is easy for the programmer to define | their function in an alternative way. | | So get rid of these three and pattern matching becomes so much more simple. | | Ciao, | Olaf | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

8 11

RE: module system/namespaces: separate with/use, allow local "use"
by Simon Peyton-Jones 30 Jan '06

30 Jan '06

| > 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. Simon

5 4

RE: what's the goal of haskell-prime?
by Simon Peyton-Jones 30 Jan '06

30 Jan '06

| My original understanding of the Haskell' effort was that it was *not* | intended as going for "Haskell 2", but rather as an update of Haskell 98. | | In other words, the target is Haskell 2005: | | - anything that was tried and tested by the end of 2005 is a potential | candidate for inclusion in Haskell 2005. nothing else is. | | this would necessarily exclude much of the discussion here I think that the main justification for such discussion is this is one of the rare times when it's arguably OK to make non-upward-compatible changes Such changes tend not to be tried-and-tested precisely because they break H98. We can flirt with many such changes, but we should probably only adopt ones for which the case seems very strong. Simon

1 0

Polymorphic record update
by Einar Karttunen 30 Jan '06

30 Jan '06

Hello Here is a proposal to allow polymorphic record update for the existing record system. I think it makes sense if the current record system is kept. Given a record like: data Foo a = Foo { bar :: a } it would be nice to be able to update it like: f = Foo { bar = 'a' } g = f { bar = False } constructing the new record by hand is quite tedious for records with many fields and one ends up writing helper functions to do this. - Einar Karttunen

4 3

RE: ~ patterns
by Simon Peyton-Jones 30 Jan '06

30 Jan '06

| BTW if let and where were strict-by-default, just as lambda and case | are, then there would be no need for ! patterns, would there? | | John Yes, absolutely there would, but really only on variables. f (!x, !y) = e (Dually, you could argue that with let lazy-by-default there is no need for ~ patterns.) Simon

2 1

how to create proposals and document consensus
by Isaac Jones 30 Jan '06

30 Jan '06

Greetings! I've just opened up the ticket tracking system to "guest" users so that you can all create and edit proposals and make formal requests via the ticket tracking system. The ticket tracking system is attached to the wiki. Important notes: The purpose of this is for the community at large to be able to make requests / proposals that the committee promises to respond to. Stuff on the mailing list can too easily taper off without any consensus. Please use the ticket tracking system to create proposals based on mailing list discussion. The committee may move such proposals to the wiki itself. -= Some Guidelines =- Use the mailing list for _discussion_ and to reach a consensus. Use the tickets to _document_ the consensus as a proposal. You may want to post the wiki page you create back to the thread so that the thread participants can review and edit it. If you get no support on the mailing list for an idea, please think twice about whether or not to create a ticket for it. It is just fine to have conflicting points of view in a ticket, but no back-and-forth discussion (use the mailing list for that). Create "pros" and "cons" sections in the ticket. Edit the ticket rather than adding "comments". Link this ticket with wiki pages or other tickets which are related, or for which this is a counter-proposal. Be sure to set the "component" field as "Proposal" and leave the Adopt field alone. -= Example =- So for instance, there's a proposal that we modify the comment syntax. After some time for discussion on the list, Thomas (cc'd) should create a new ticket if he still believes in his suggestion. The ticket should have component:proposal. The pros are that it's going to be simpler for students, more consistent with the block comment syntax, and easier to implement in editors. The cons are that we lose a group of possible operators, --> for instance, and this in turn may cause some code to break. Put your email address on the tickets so we know who to ask if we have any questions. To create a ticket, go to the wiki and log in. The user name is guest and the password is haskell'. If you think you'll be doing a lot of ticket work, email me for a guest account so that your name will automatically appear on the changes. Email me if you have any questions. peace, isaac

1 0

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

30 Jan '06

An example where loss of sharing leads to exponential time: fib n = fst (fib' n) fib' :: (Num a, Num b) => Integer -> (a,b) fib' 0 = (0,1) fib' n = (snd p,fst p+snd p) where p :: (Num a, Num b) => (a,b) p = fib' (n-1) Here you need BOTH type signatures, since otherwise the one stated for p is too general (needs polymorphic recursion). Maybe it's obvious from the two type variables that sharing will be lost-- but the example below only has one, and is still exponential time under Hugs (GHC optimises it to linear). fib2 n = fst (fib2' n) fib2' :: Num a => Integer -> (a,a) fib2' 0 = (0,1) fib2' n = (snd p,fst p+snd p) where p :: Num a => (a,a) p = fib2' (n-1) In this case, provided you write the type signature on fib2' (thus permitting polymorphic recursion), then the type signature I wrote on p is the one that would be inferred, were it not for the M-R--and thus this program risks running in exponential time. Same applies to fib' above: if you write the type signature on fib', then but for the M-R, the type signature on p is the one that would be inferred, and you get exponential time behaviour. It would be undesirable for adding a type signature to a function (such as fib' above) to risk making its performance exponentially worse, because of consequential loss of sharing in a binding somewhere else. Wouldn't it? John

5 8

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

30 Jan '06

From: Marcin 'Qrczak' Kowalczyk <qrczak(a)knm.org.pl> John Hughes <rjmh(a)cs.chalmers.se> writes: >> 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. > > Local definitions are rarely used polymorphically. Perhaps without a type signature the definition should be polymorphic and recomputed if it's global, and monomorphic and shared if it's local. Probably this is normally what you want--but oh, how confusing it would be! I'd like to be able to give a simple answer to the question "Is this binding shared or not?", not an answer that begins with "Is there a type signature?", "What does the type signature look like?", and "Is it local or global?"! This would open for very confusing behaviour when refactoring code, to move bindings between top-level and a local scope. John

1 0