| while :: IO Bool -> IO () -> IO () | | while test action = do res <- test | if res then do action | while test action | else return ()
Haskell uses "layout" to reduce the need for parentheses. For your code to parse, "if" should align with "res" vertically, as in:
... = do res <- test if res ...
The "layout" rules drive me nuts. You might prefer using parentheses and semicolons, as I do: -- (not tested) while :: IO Bool -> IO () -> IO (); while test action = do { res <- test; if res then do { action; while test action; } else return (); }; -- ...and then you can put the whitespace wherever you want. -- Ashley Yakeley, Seattle WA
Hi, Ashley Yakeley wrote: | The "layout" rules drive me nuts. You might prefer using parentheses and | semicolons, as I do: I guess the point behind the layout rules is that anything violating such rules is considered bad programming style. I agree that Haskell compilers/interpreters should give more helpful error messages though (e.g. adding something like "Do you mean to align 'foo' with 'bar'?"). - Zhanyong
On Sat, 2002-01-05 at 05:03, Zhanyong Wan wrote:
Hi,
Ashley Yakeley wrote:
| The "layout" rules drive me nuts. You might prefer using parentheses and | semicolons, as I do:
I guess the point behind the layout rules is that anything violating such rules is considered bad programming style. I agree that Haskell compilers/interpreters should give more helpful error messages though (e.g. adding something like "Do you mean to align 'foo' with 'bar'?").
- Zhanyong
Here here. I think that the poor compiler error messages in Haskell are a very major hurdle to learning the language. I threw in the towel 6 months or so ago basically because I couldn't see my way through to debugging my programmes. But here i am back again. A glutton for punishment. Tom
On Monday 07 January 2002 1:22 am, Tom Bevan wrote:
On Sat, 2002-01-05 at 05:03, Zhanyong Wan wrote:
Hi,
Ashley Yakeley wrote: | The "layout" rules drive me nuts. You might prefer using parentheses | and semicolons, as I do:
I guess the point behind the layout rules is that anything violating such rules is considered bad programming style. I agree that Haskell compilers/interpreters should give more helpful error messages though (e.g. adding something like "Do you mean to align 'foo' with 'bar'?").
- Zhanyong
Here here. I think that the poor compiler error messages in Haskell are a very major hurdle to learning the language.
Which compiler are you talking about? Bad error messages are not a valid critisism of the Haskell Language IMHO. I think the error messages produced by ghc are pretty good myself (though it's not very helpful wrt to syntax errors I must admit, but they're easy to find and fix anyway). As for prefering {;} to layout, that's just daft. I don't think I've ever had a layout related error. Not one. But I get plenty of errors caused by incorrect nesting of {} or missing ; in C (unless I layout the code properly of course :-) Regards -- Adrian Hey
Zhanyong Wan:
Here here. I think that the poor compiler error messages in Haskell are a very major hurdle to learning the language.
Adrian Hey:
Which compiler are you talking about? Bad error messages are not a valid critisism of the Haskell Language IMHO.
But there are language features in Haskell that makes it hard to produce good error messages. Implicit typing, for instance: in an explicitly typed language it is clear where in the code a type error occurs, but with implicit typing there are often many possibilities and it is not always evident where the culprit is. (Haskell compilers seem simply to report the line where the unification fails. Am I right?) Furthermore, semantically distant expressions can be syntactically close in Haskell, so a syntax error actually gives a syntactically correct expression. Often this yields a type error instead, which then may show up as an error message for some totally different part of the code... Higher-orderness increases the risk. An example is inadvertently writing "f g y" for "f (g y)" which then is interpreted as "(f g) y" and will yield incorrect constraints on the types of f, g, and y. Is there any work being done on "intelligent" error messages for higher-order implicitly typed languages? One could perhaps come up with search strategies that tries to find a minimal number of program transformations ("edit distance") that yields a syntactically correct and well-typed program. For instance, in the case of type errors one could try to search for the minimal number of definitions that have to be removed to make the remaining program well-typed, and then report the removed definitions as likely sources of the errors. Has anyone done this? Björn Lisper
Bjorn Lisper wrote:
... Is there any work being done on "intelligent" error messages for higher-order implicitly typed languages? One could perhaps come up with search strategies that tries to find a minimal number of program transformations ("edit distance") that yields a syntactically correct and well-typed program. For instance, in the case of type errors one could try to search for the minimal number of definitions that have to be removed to make the remaining program well-typed, and then report the removed definitions as likely sources of the errors. Has anyone done this?
Quite a number of people have published work on helping the programmer to locate the source of type errors in Hindley-Milner typed languages. I presented a paper about this subject at last ICFP. Mainly my paper is about a way of viewing the types of arbitrary subexpressions of a program. Note that you can only attach a type to an expression such as "f x" if you know the types of "f" and "x". However, "f x" may appear in the definition body of "f". You don't want cyclic explanations of types... I propose to have the user either browse freely through the typings of arbitrary expressions, or use a method called algorithmic debugging to locate the source of a type error. The algorithmic debugger asks the user if certain typings for certain expressions are correct according to his/her intentions. After some yes/no answers the debugger gives the location of the error. Other people have developed methods for more "intelligent" error messages, although not exactly in the way you propose. Have a look at the Related Work Section of my paper. You can get it from my web page (URL below). I am a bit doubtful about the practical usefulness of "intelligent" error messages. It is easy to create examples where a program can be made type correct by one of many rather different small transformations, all of similar complexity. I believe such examples do occur in practise and hence knowledge of the intended semantics is necessary to locate errors. However, with all the many proposals for better error location, there is definitely a lack of practical evaluation. Basically for each proposed method there exists only a toy implementation for a toy language, each method for a different language (and most of these implementations don't even seem to be available). I want to extend my prototype, replacing the type inference phase of nhc98, but I haven't yet had the time... Ciao, Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767
participants (6)
-
Adrian Hey -
Ashley Yakeley -
Bjorn Lisper -
Olaf Chitil -
Tom Bevan -
Zhanyong Wan