March 2006 - Haskell-prime

Re[2]: darcs patch: add Data.Set.notMember and Data.Map.notMember
by Bulat Ziganshin 10 Mar '06

10 Mar '06

Hello Christian, Friday, March 10, 2006, 2:32:02 PM, you wrote: >> f x | not (x `Set.member` map) && foo = ... >> is hard to read. btw, (x `not.Set.member` map), as proposed by Doaitse Swierstra, will look better in this case -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Strictness standardization/description
by Henk-Jan van Tuyl 10 Mar '06

10 Mar '06

L.S., Much has already been said about strictness, but what I haven't seen discussed sofar, and what am missing in the Haskell Report, is a description of the strictness of parameters of functions and operators. It is often important to know the strictness to prevent space leaks and even for the correctness of a program. A description of strictness in the Haskell' report would not only enable more reliable design of Haskell programs, but also prevent difference in strictness between the compilers/interpreters. -- Best regards, Henk-Jan van Tuyl -- http://members.chello.nl/hjgtuyl -- Using Opera's revolutionary e-mail client: https://secure.bmtmicro.com/opera/buy-opera.html?AID=789433

3 2

RE: the dreaded offside rule
by Simon Marlow 10 Mar '06

10 Mar '06

On 10 March 2006 11:02, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> wrote: > >> Here's another couple that just occurred to me: >> >> f x | let y = x = y >> f x = case x of _ | let y = x -> y >> >> granted these are unlikely to occur in practice. > > Are these Haskell'98? I'm afraid I don't understand how a let binding > (without "in") can occur in a guard for a function decl or case > branch. In Ben's examples, the vertical bar was not a guard, but the > separator in a comprehension (although he omitted to show the > surrounding brackets...) > > [ ... | let x, y :: T > x = 3 > y = 4, > ... ] > > [ ... | let x = 3, ... ] Right, they're not Haskell 98, they all require pattern guards. Cheers, Simon

1 0

RE: the dreaded offside rule
by Simon Marlow 10 Mar '06

10 Mar '06

On 09 March 2006 22:56, Ian Lynagh wrote: > On Thu, Mar 09, 2006 at 04:53:52PM -0000, Simon Marlow wrote: >> On 09 March 2006 14:40, Simon Marlow wrote: >> >>> But ISTR I later discovered a reason that counting brackets wouldn't >>> work so well, but for now it escapes me. I'll try to dig it up. >> >> I remember now: the problem is that 'let' does not always have a >> matching 'in', e.g. when it is used in 'do', pattern guards or list >> comprehensions. So you can't consistently treat let/in as brackets. >> I don't know a way around this. > > Right, I mentioned that in my earlier mail. So you did, sorry, I skimmed it too quickly. Ben's mail pretty much covers the problems with this idea, I think. It's unfortunate, because it almost works. Here's another couple that just occurred to me: f x | let y = x = y f x = case x of _ | let y = x -> y granted these are unlikely to occur in practice. Cheers, Simon

2 1

RE: the dreaded offside rule
by Simon Marlow 10 Mar '06

10 Mar '06

On 09 March 2006 14:40, Simon Marlow wrote: > On 09 March 2006 14:33, Ian Lynagh wrote: > >> On Wed, Mar 08, 2006 at 10:27:48PM +0100, Doaitse Swierstra wrote: >>> It is with some hesitation that I want to bring up another point, in >>> which Haskell' could be an improvement above Haskell: the offside >>> rule. >> >> This is something I would have brought up too, except I don't think >> I'll have time to look into it properly in the advertised timescale. >> >> I conjecture that with a suitable set of bracketing keywords and >> symbols (if/then, let/in, [/], ...) the "parse error => close >> implicit block" rule could be dropped without significantly altering >> the set of acceptable programs (just rejecting programs that people >> really oughtn't be writing anyway (IMNSHO), like Lennart's examples). > > I once conjectured this too, and I even went so far as to measure how > many times the parse-error rule was actually used, as opposed to > simple bracketting, in all the code I could get my hands on. > Conclusion: it was a handful of times in several 10000 LOC, mostly > for things like '(case x of p -> e, 42)'. > > But ISTR I later discovered a reason that counting brackets wouldn't > work so well, but for now it escapes me. I'll try to dig it up. I remember now: the problem is that 'let' does not always have a matching 'in', e.g. when it is used in 'do', pattern guards or list comprehensions. So you can't consistently treat let/in as brackets. I don't know a way around this. Cheers, Simon

3 2

RE: the dreaded offside rule
by Simon Marlow 09 Mar '06

09 Mar '06

On 09 March 2006 14:33, Ian Lynagh wrote: > On Wed, Mar 08, 2006 at 10:27:48PM +0100, Doaitse Swierstra wrote: >> It is with some hesitation that I want to bring up another point, in >> which Haskell' could be an improvement above Haskell: the offside >> rule. > > This is something I would have brought up too, except I don't think > I'll have time to look into it properly in the advertised timescale. > > I conjecture that with a suitable set of bracketing keywords and > symbols (if/then, let/in, [/], ...) the "parse error => close > implicit block" rule could be dropped without significantly altering > the set of acceptable programs (just rejecting programs that people > really oughtn't be writing anyway (IMNSHO), like Lennart's examples). I once conjectured this too, and I even went so far as to measure how many times the parse-error rule was actually used, as opposed to simple bracketting, in all the code I could get my hands on. Conclusion: it was a handful of times in several 10000 LOC, mostly for things like '(case x of p -> e, 42)'. But ISTR I later discovered a reason that counting brackets wouldn't work so well, but for now it escapes me. I'll try to dig it up. > Things are slightly complicated by things like [ ... | ... ] and "let" > not always being closed by "in" (so you just have to have it > implicitly closed when you want to insert a ; in a "do" block), but I > haven't thought of anything that'll actually break it. Then again, I > haven't thought too hard about it or tried it out yet. > > I'm not sure how much easier this will make it to explain the rule to > people - if you just explain the gist using the simple examples of > bracketing, like if/then, then I think it would be significantly > simpler, but if you'd want to explain all the niggly details then it > might end up also being too complex. > > The main advantage is it would make layout a separate pass between > lexical analysis and parsing. Yes, and that's a big win. Cheers, Simon

3 2

the dreaded offside rule
by Doaitse Swierstra 09 Mar '06

09 Mar '06

It is with some hesitation that I want to bring up another point, in which Haskell' could be an improvement above Haskell: the offside rule. Although I manage to live with it, I encountered many problems with it in the past: 1) it is impossible to explain the precise workings of the rule to a class of first years undergraduates This is extremely demotivating. I do not want to teach using the following utterances: "If you write your programs in the same style as I do on my slides, you will usually get away with it". Students are perfectly happy to accept that complicated things are complicated, but are not very willing to buy complicated explanations for things which ought to be simple. I furthermore think it is waist of time to to have to go into this in my lectures. I do not think the alternative, in which you always have to write { ; ; } is an option. A language in which every let is followed by a { is plain stupid; just like in Pascal, where each procedure, function, const, var and begin keyword has to be preceded by a (thus superfluous) semicolon. 2) it has created havoc among students for years, with Hugs complaining about improper semicolons, whereas the student has not typed a single semicolon in his program. many students think Haskell is a complicated language, mainly because of offside rules, (and the monomorphism restriction of course) 3) it is formulated in an implementation oriented way, prohibiting proper tool support for parser generation With our parser combinator library we have created very efficient error-correcting parsers (far more efficient that Parsec based ones) for quite a few languages (including Haskell). Creating one for Haskell however became a nightmare, although we have managed to encapsulate the problem in a special offside parser combinator. Our parsers perform error-correction automatically, and this is simply not compatible with a prescription in the language definition as to how certain parse errors should be dealt with (especially that they are not errors). We had to put parser-brain-surgery into place in order to cope with the description of the offside rule. Although the problem is solved by the introduction of the offside combinator now, I think it is a sign of unhealthiness of the formulation, which is too implementation dependent. 4) based on many examples my claim is that almost no Haskell programmer can always correctly apply to offside rule We might go back to something simpler, like e.g. the Miranda(tm) rule, in which declarations have to start in the same column, and a declaration extends to the lower right of its first character. Doaitse Swierstra

7 8

small extension to `...` notation
by Doaitse Swierstra 09 Mar '06

09 Mar '06

In Haskell we write `f` in order to infixify the identifier f. In ABC the stuff between backquotes is not limited to an identifier, but any expression may occur there. This would allow one to write e.g. xs `zipWith (+)` ys In general <expr1> `<expr2>` <expr3> => (<expr2>) <expr1> <expr3> I think it is a small extension to Haskell, which does not break anything existing, and provides yet another opportunity to beautify one programs, especially in combination with programs like lhs2TeX. Doaitse Swierstra

6 6

If you really care, make sure it gets on the wiki (how to create a proposal)
by isaac jones 08 Mar '06

08 Mar '06

I'm sure you've noticed that there is a lot of traffic on this list. I want to emphasize that if you really care about an idea, you should make sure it gets on the wiki in one way or another, or it may get lost in the mass of traffic on the mailing list: http://hackage.haskell.org/trac/haskell-prime/wiki/CreateProposal How to create a proposal If you have an idea: 1. Post it to the MailingList. Use the MailingList for discussion and to reach a consensus. 2. If you don't have a wiki account, Log in with username guest and password haskell' to create and edit tickets. 3. after some discussion, create a new ticket (or modify an existing one) to document the consensus as a proposal. See WikiGuidelines. 4. 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. 5. Watch for threads that outlive their usefulness as a discussion. Document the disagreements on the wiki. How to modify an existing proposal 1. if the proposal is in a ticket, modify it directly 2. otherwise, if you don't have write access to the wiki, discuss your change request on the mailing list 3. or just modify the ticket that references that wiki page, requesting the change be made there. peace, isaac -- isaac jones <ijones(a)galois.com>

2 1

partial application syntax
by Wolfgang Jeltsch 08 Mar '06

08 Mar '06

Hello, there was some proposal for introducing a special syntax where f x _ z or f x ? z means \y -> f x y z. Is there some information on the Haskell' trac site about this? Best wishes, Wolfgang

2 1