Re: the dreaded offside rule
Neil, 1) it is impossible to explain the precise workings of the rule to a class of first years undergraduates Then don't explain it to them. At York in the 3rd year Haskell course it is never explained in detail, I think it might be briefly mentioned in passing that some kind of indentation thing is used, but not focused on. I certainly don't have a clue what the rule is. Well, that of course only works out well if students don't violate the offside rule. As soon as they do (for instance, because they use tabs instead of spaces to lay out their code), they want to know why the compiler rejects their programs. For students that have the right attitude, you can't just say that it has something to do with indentation then, because those will want to know the details then. Regards, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: small extension to `...` notation
Ben, xs `zipWith (+)` ys Another problem is that it's not clear how to declare the fixity of these things. Should they always have the default fixity? Should they be required to have the form `ident args` and use the fixity of `ident`? Neither approach seems very clean. Following Philippa's suggestion to handle nesting, one could again treat `ident` and `non-indent-expr` differently and always assume the latter is given infix 9. Regards, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the dreaded offside rule
On 2006 mrt 09, at 1:54, Lennart Augustsson wrote: I agree with it being complicated. I don't know of any compiler that implements it correctly. Do you say your combinators do? At least we think so. The way to use it is e.g.: pExprPrefix =sem_Expr_Let $ pKey let * pDecls * pKey in pDecls =foldr sem_Decls_Cons sem_Decls_Nil $ pBlock pOCurly pSemi pCCurly pDecl pDecl =sem_Decl_Val$ pPatExprBase * pKey = * pExpr | sem_Decl_TySig $ pVar * pKey :: * pTyExpr in which the pBlock takes care of the offside rule, in cooperation with the scanner. That said, I don't think it can be replaced easily without breaking existing code, so I'm unwilling to change unless someone can show an alternative that handles 99.9% of the existing code. There are solutions to this kind of transitions. Compilers could admit the old rule, and emit a warning when e.g. the --this-is- supposed-to-be-strictly-haskell-prime flag is passed. One might also equip a compiler to transform one's program into the new standard. Doaitse ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: small extension to `...` notation
Hello Doaitse, Thursday, March 9, 2006, 12:01:37 AM, you wrote: DS xs `zipWith (+)` ys i had the same desire several times Possibly `(expr)` ? it will be non-readable. it is better to just prohibit using of backquotes inside backquotes. and fixity can be fixed at 0, imho. at least, my cases was just when i want to use two words inside backquotes instead of just one. and fixity should be 0 because such expression with space inside it should have a small priority because parts of expression too distant from each other (btw, i had (not serious) proposal to raise priority of operations if there is no spaces around it, so that the following: x:xs ++ y:ys translates to (x:xs)++(y:ys) in full accordance with natural reading) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the dreaded offside rule
1) it is impossible to explain the precise workings of the rule to a class of first years undergraduates Try Python copied the offside rule from Haskell, so it must be cool. (*) http://docs.python.org/ref/indentation.html Which is true only morally, e. g. it says here http://www.python.org/doc/faq/general.html#what-is-python that the indentation idea comes from a language ABC: http://homepages.cwi.nl/~steven/abc/ Where does Haskell's rule come come from? (*) Of course the typical undergrad is a part-time web developer, using Zope, and he thinks that Python is cool because it has no static typing, so that programming is much easier than at university where they teach him Haskell. But he soon finds that he can leave out all Haskell type signatures as well, so he thinks that Haskell is going in the right direction... -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: small extension to `...` notation
On Thursday 09 March 2006 08:59, Bulat Ziganshin wrote: Hello Doaitse, Thursday, March 9, 2006, 12:01:37 AM, you wrote: DS xs `zipWith (+)` ys i had the same desire several times Possibly `(expr)` ? it will be non-readable. it is better to just prohibit using of backquotes inside backquotes. and fixity can be fixed at 0, imho. at least, my cases was just when i want to use two words inside backquotes instead of just one. and fixity should be 0 because such expression with space inside it should have a small priority because parts of expression too distant from each other (btw, i had (not serious) proposal to raise priority of operations if there is no spaces around it, so that the following: x:xs ++ y:ys translates to (x:xs)++(y:ys) in full accordance with natural reading) I support this. BTW, it reminds me of the language L, where there are 3 'symbols' for application, each with a different precedence: A sequence of expressions separated by nothing, periods, or spaces denotes an application (function call) where the function is the result of the first expression and the arguments are the results of the remaining expressions. The expressions are computed independently in parallel. No separation has highest precedence, then period separation, then space separation. Parenthesis can be used to override precedence. Example application expressions are: x+2, x.+.2, x + 2, x + 4y, (x + 4)y + foo.bar. (Quoted from http://www-static.cc.gatech.edu/~tony/L/) Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the dreaded offside rule
If you can parse do x == y == z or case 0 of x - x == x == True you're probably ok. I can't tell from your example if this works or not. -- Lennart Doaitse Swierstra wrote: On 2006 mrt 09, at 1:54, Lennart Augustsson wrote: I agree with it being complicated. I don't know of any compiler that implements it correctly. Do you say your combinators do? At least we think so. The way to use it is e.g.: pExprPrefix =sem_Expr_Let $ pKey let * pDecls * pKey in pDecls =foldr sem_Decls_Cons sem_Decls_Nil $ pBlock pOCurly pSemi pCCurly pDecl pDecl =sem_Decl_Val$ pPatExprBase * pKey = * pExpr | sem_Decl_TySig $ pVar * pKey :: * pTyExpr in which the pBlock takes care of the offside rule, in cooperation with the scanner. That said, I don't think it can be replaced easily without breaking existing code, so I'm unwilling to change unless someone can show an alternative that handles 99.9% of the existing code. There are solutions to this kind of transitions. Compilers could admit the old rule, and emit a warning when e.g. the --this-is-supposed-to-be-strictly-haskell-prime flag is passed. One might also equip a compiler to transform one's program into the new standard. Doaitse ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: small extension to `...` notation
Some questions were raised. Let me start withbynoticing that all I am interested in is a very small extensions, without creating more problems than solving, so I could perfectly live with: - no `...` inside `...`. If you really need this you use parentheses - the first element between the `...` should be an identifier, and the operator takes the properties of this identifier. With respect to the last remark: this makes it clear that I am really passing arguments to the identifier, which would otherwise stand alone between the `...`'s. Everything else remains the same, Doaitse On 2006 mrt 09, at 8:59, Bulat Ziganshin wrote: Hello Doaitse, Thursday, March 9, 2006, 12:01:37 AM, you wrote: DS xs `zipWith (+)` ys i had the same desire several times Possibly `(expr)` ? it will be non-readable. it is better to just prohibit using of backquotes inside backquotes. and fixity can be fixed at 0, imho. at least, my cases was just when i want to use two words inside backquotes instead of just one. and fixity should be 0 because such expression with space inside it should have a small priority because parts of expression too distant from each other (btw, i had (not serious) proposal to raise priority of operations if there is no spaces around it, so that the following: x:xs ++ y:ys translates to (x:xs)++(y:ys) in full accordance with natural reading) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the dreaded offside rule
On Thu, Mar 09, 2006 at 04:53:52PM -, 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. However, I think this can be handled by rules like L (n:ts) ((Let:bs,m):bsms) = L ts ((bs,m):bsms) if m = n but like I said, I haven't had time (nor do I expect to have time for H') to work it all out and see if it can actually be made to work. Incidentally, in my head the , in (case x of p - e, 42) acts as a right and left bracketing lexeme, so this expression would still be accepted. At the cost of rejecting more H98 programs you wouldn't have to allow it, of course, although from the user's point of view I'd prefer if it was allowed. (By the way, have the mailing lists started being clever and not sending you messages that look like they are also being sent directly to you?) Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
