- Haskell-prime - Haskell.org

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

09 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

partial type signatures/annotations/declarations..
by Claus Reinke 07 Mar '06

07 Mar '06

when trying to look up the state of this proposal, I noticed: - there seem to be two parallel versions (probably signatures is an older form, and all references ought to point to annotations instead?): http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions points to: http://hackage.haskell.org/trac/haskell-prime/wiki/PartialTypeSigs http://hackage.haskell.org/trac/haskell-prime/ticket/40 whereas http://hackage.haskell.org/trac/haskell-prime/report/9 points to: http://hackage.haskell.org/trac/haskell-prime/wiki/PartialTypeAnnotations http://hackage.haskell.org/trac/haskell-prime/ticket/86 - the proposal focusses on using "_" as a place holder for unspecified parts of a type or context, without discussing the alternative I'd favour: instead of introducing holes in types and contexts to leave parts of a declaration unspecified, why not use type subsumption? the idea being, that instead of declaring the precise type, one would declare an upper bound on the type, and the precise type inferred needs to be subsumed by the one declared. type and context syntax would remain unchanged, but in addition to "::" for precise type annotations, there'd be ":::" (or "::<", or whatever) to indicate the difference in intended semantics. pro: would easily allow for omission of type details or parts of context (a type with more context, or with more specific type components, is subsumed by the declaration) cons: as long as we only specify an upper bound, the inferred type could be more specific than we'd like (we can't say that we don't want context, or that some type variable must not be instantiated) cheers, claus

2 2

Re: Export lists in modules
by Ketil Malde 03 Mar '06

03 Mar '06

Wolfgang Jeltsch <wolfgang(a)jeltsch.net> writes: >> Personally, I would greatly prefer to have libraries that do not clash >> with common Prelude functions. > I would solve this problem by reducing the Prelude to just a core. List > function could go, for example, (mostly) into Data.List. If this means that you must import Data.List almost everywhere, this won't change anything - only add yet another import to every file. I know most - if not all - of my modules use lists, but just in case, I checked with the darcs sources - 95 of 107 source files appear to use lists. Ignoring the : and ++ operators (looking for null, map, and filter) the count is 76 files. >> If you always have to qualify it, what's the advantage of >> Data.Set.empty over emptySet again? At least with 'emptySet' I know >> what to grep for. > I would import Data.Set as Set. So I would use Set.empty instead of > emptySet. The problem is that I might import Data.Set as S. Joe would import it as something else, and Frank would use yet another prefix. > The advantage is that Set.empty is more structured. I'm not sure why that is such an advantage. To me, structure sounds like a means rather than an end. If it made things simpler, I'd be all for it, but IMO it doesn't - and it makes some things more difficult. > You can easily distinguish the kind of operation (empty) and the > type you are working with (Set). Only by convention - i.e. I must manually rename the module in a way that is meaningful with respect to the type. (As an aside, 'empty' is a rather poor example, as it is not a Prelude function. Take 'null' or 'map' or - why not - '(:)' instead) Don't get me wrong, I don't want to go back to the old ways of prefixing *every* identifier with a module abbreviation. But I resent having to add a multi-line half-standardized set of imports to over 90% of my source files. In short, I'm fairly comfortable with the scope of the Prelude¹ and I don't mind modules like e.g. Data.Map and Data.Set, which are similar in many ways to recycle some of their identifiers. However, I think minimizing the number of name clashes should be a goal, and modules that are intended to be used together, should try to avoid using the same identifiers. And this implies that Prelude identifiers should *not* be recycled, unless you intend to replace the Prelude. -k ¹ I might want to shove some of the association list stuff into Data.List, but certainly not all list functionality. -- If I haven't seen further, it is by standing in the footprints of giants

12 29

Re: Collections (was: Arrays)
by Robert Dockins 02 Mar '06

02 Mar '06

On Mar 2, 2006, at 1:57 PM, Alson Kemp wrote: >> This doesn't address Bags, Heaps, Finite Relations >> or 'cons'able >> sequences. > True. > > Perhaps my listing was incomplete, in which case this > might fix it: >>> Collection >>> .Array > * * .Bag > * * .FiniteRelations -- Maps? Finite Relations are to Finite Maps as Bags are to Sets. Each key can be associated with multiple elements. > * * .Heap >>> .Map >>> .Set >>> .Tree >>> .Binary >>> .Rose >>> Data >>> . ... >>> . Int >>> . ... > > What is an example of a cons-able sequence? (aside > from []) See http://www.eecs.tufts.edu/~rdocki01/docs/edison/index.html Edison contains about 8 or 9 different concrete implementations of sequences with varying time complexity for the core operations. > Or, perhaps as a non-math-geared programmer, I've > missed something. I come at this from "make Haskell > more useful to more programmers" rather than from > "make Haskell a mathematically beautiful language" (I > slept through Discrete Mathematics). That said, if > you can point me towards a paper, I'd be happy to read > up and try to encompass the "mathematically beautiful" > perspective, too. (Especially since the proposal will > probably get rejected without a component of > mathematical beauty! ;) ) I don't know of any papers of the top of my head. I guess I just wanted to point out that the landscape of abstract data structures is wider than "Array, Set, Map". Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

1 0

Collections (was: Arrays)
by Alson Kemp 02 Mar '06

02 Mar '06

Following on an earlier e-mail about refactoring Arrays... In noodling around with collections, sets, maps, arrays, I seem to have duplicated (a very small piece of) some of SPJ's work in "Bulk types with class"... from 9 years ago... In particular, Section 4 lays out the beginning steps of how to use multiparameter classes to implement a consistent set of Collections and subclasses. I know that I floated something similar a couple of weeks ago, but, based on the above, I thought that I'd float a more specific proposal: ------------ In Haskell', "collection"-style classes will be moved from the Data module and to the Collection module. Modules would be organized something like as follows: Collection .Array .Map .Set .Tree .Binary .Rose Data . ... . Int . ... Backwards compatibility can be maintained by leaving deprecated Data classes. -------- If there's no objection, I'll create a proposal ticket and flesh out the proposal more clearly. - Alson

2 1