A bandaid suggestion: longFunctionName various and sundry arguments = f where f | guard1 = body1 f | guard2 = body2 | ... where declarations (Disclaimer: untested) As I understand it, there can be guards on the definition of f even if it takes no arguments. Those guards can reference your the various and sundry arguments. On 7/26/07, Stefan O'Rear wrote:

On Thu, Jul 26, 2007 at 02:56:57PM -0400, anon wrote:

...

...

longFunctionName various and sundry arguments | guard1 = body1 | guard2 = body2 | ... where declarations That is, with guards and where clauses indented to the same level as

Greetings, I wish to be able to indent my code like so: the function name.

This seems like a perfectly reasonable indentation style to me. It also happens to be the preferred style in Clean, another layout-sensitive functional language. I believe it is not uncommon in ML dialects as well. So why is it that I'm not allowed to use it in Haskell?

Because in Haskell everything that is lined up is a new logical line. Haskell requires all continuation lines to be indented:

longFunctonName various and sundry arguments | guard1 = body1 | guard2 = body2 | .. where declarations

As for "why", it's just a matter of Haskell Committee taste. Nothing too deep, just an arbitrary set of rules.

Stefan

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGqPS5FBz7OZ2P+dIRAgwbAKCl3ssl6X42VqSZJnhgKVH7WSzRXwCaA3x5 Ze0lGvx17IDrFXxBEvVxGeI= =5/To -----END PGP SIGNATURE-----

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Whoops, read too fast. Sorry for the noise. On 7/26/07, Stefan O'Rear wrote:

On Thu, Jul 26, 2007 at 02:58:21PM -0500, Nicolas Frisby wrote:

...

A bandaid suggestion:

longFunctionName various and sundry arguments = f where f | guard1 = body1 f | guard2 = body2 | ... where declarations

(Disclaimer: untested)

As I understand it, there can be guards on the definition of f even if it takes no arguments. Those guards can reference your the various and sundry arguments.

Eh? Mine doesn't use up a where clause and doesn't use a f noise symbol. Why do you need a band-aid?

"longFunctionName\32=\n\32|\32guard\32=\32body\n\32|\32guard\32=\32body\n\32..."

Stefan

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGqP3jFBz7OZ2P+dIRAgGhAKC3X7hV/vLElQelqCtjZ7XlZQDvdACfftJc R2g03ScWG33jSzGJ8yxJvUM= =rq9Y -----END PGP SIGNATURE-----

On Thu, Jul 26, 2007 at 05:34:32PM -0400, anon wrote:

2007/7/26, Stefan O'Rear :

...

As for "why", it's just a matter of Haskell Committee taste. Nothing too deep, just an arbitrary set of rules. That's not much of an explanation, is it? I imagine someone must have given the matter some thought before describing the layout rule in great details in the language report. Perhaps there was a perfectly good reason to preclude this kind of code, but I'm afraid I do need a reason if I am to understand why. And if it turns out that there really is no such reason, would it be terribly presumptuous of me to suggest that the rules be changed to accomodate this particular style in Haskell' or a future revision of the language? I guess it would, but one can always hope.

Why do you think it should be allowed? The current rules are arbitrary, but they are quite simple; we don't want to add an ad-hoc exception just for this. Out of curiousity, what do you find objectionable about (legal): function argument argument2 | guard = body | guard = body as compared to (currently illegal): function argument argument2 | guard = body | guard = body Stefan

On 7/27/07, Neil Mitchell wrote:

Personally, I have no problem with the current way (and would consider anything other than 4 leading spaces in the first example to be evil). However, if you are using a text editor which doesn't automatically indent the start of following lines, it might be a bit more annoying. Of course, if your editor is that bad you should consider changing to virtually anything which isn't notepad.

Or pico. :-) You'd be amazed the number of undergraduates I taught who refused to learn to use gvim, emacs, or any other *programming* editor, and instead spent 75% of their time battling the editor. <sigh> I must say, I agree about the indentation question. My experience is that if you use 4 space indentation and run out of columns, then it's time to refactor, and think more about how your logical structure is working (you may recall, this list recently introduced me to the Maybe monad transformer for exactly this reason). It's actually a pretty effective rule of thumb. cheers, T. -- Dr Thomas Conway drtomc@gmail.com Silence is the perfectest herald of joy: I were but little happy, if I could say how much.

On Thu, Jul 26, 2007 at 08:17:06PM -0400, anon wrote:

2007/7/26, Stefan O'Rear :

...

Out of curiousity, what do you find objectionable about (legal):

function argument argument2 | guard = body | guard = body

as compared to (currently illegal):

function argument argument2 | guard = body | guard = body

The extra space, obviously :-) I'm well aware that this is an issue of vanishingly small consequence, but one could likewise dismiss the entire layout business as a needlessly complicated way to save a few keystrokes if one were so inclined. If language complexity is the chief concern, why not dispense with layout altogether (and a few more things beside)? Perhaps fuzzy notions of aesthetics and intuitiveness should weigh into the equation as well unless you don't mind programming in the unadorned lambda calculus.

Definitely, and Haskell *was* designed to be aesthetic. I suppose what I'm really trying to ask is *why* you think the second should be legal. To me it just seems like an ugly ad-hoc generalization, and ad-hoc generalizations are something Haskell tries to avoid. (There's a bit of background on the syntax design process in SPJ's History of Haskell paper, page 10 of http://research.microsoft.com/~simonpj/papers/history-of-haskell/history.pdf). Stefan

2007/7/26, ok :

The Fundamental Law of Indentation is "If major syntactic unit X is a proper part of major syntactic unit Y, then every visible character of X is strictly to the right[%] of the leftmost[%] visible character of Y." [%] If you are using a right-to-left script, switch "left" and "right" in that sentence.

What makes this a law? If you notice a pattern where beginners trip against this rule because they don't indent the arms of conditionals properly inside do blocks, should strict adherence to this principle take precendence over the intuition of prospective users of the language? Oddly enough, members of the Haskell' committee seem to think we should amend the rules for the benefit of programmers rather the other way around, but I guess they never heard of the Fundamental Law of Indentation.

That is how indentation makes structure visible, and if you break that, you just plain aren't indenting. This isn't fuzzy, and it isn't aesthetic, it's simply that if you start things in the same column you are making it obvious to the reader than neither is part of the other. In the example about, that's not true. You might as well go around ending sentences with

I see what you did there. But you really might as well end sentences with prepositions. Or begin them with conjunction. Or indent your code whichever way seems most natural and elegant because to do otherwise is just prescriptivism for its own sake. In general, people don't much care for arbitrary rules; they like to understand the rationale behind them before they get on board, which is all I'm really asking for here.

On Fri, 27 Jul 2007 00:33:17 -0400, you wrote:

What makes this a law? If you notice a pattern where beginners trip against this rule because they don't indent the arms of conditionals properly inside do blocks, should strict adherence to this principle take precendence over the intuition of prospective users of the language?

What exactly are you proposing as an alternative rule? If you're suggesting that _any_ line at the same level of indentation as the previous line be treated as a continuation of that line, then how would one go about indicating that a line is _not_ a continuation of the previous line? On the other hand, if you're suggesting that only certain things be recognized as being a continuation of the previous line (e.g., guard clauses), then it seems to me that you're replacing a brain-dead simple and straightforward rule with one that is inherently more complex and thus more likely to cause angst among beginners. Or are you proposing to get rid of layout altogether and rely on punctuation? I just can't think of a rule that would be easier to understand (and quicker to assimilate) than the current one. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/

On 27 Jul 2007, at 4:33 pm, anon wrote:

2007/7/26, ok :

...

The Fundamental Law of Indentation is "If major syntactic unit X is a proper part of major syntactic unit Y, then every visible character of X is strictly to the right[%] of the leftmost[%] visible character of Y." [%] If you are using a right-to-left script, switch "left" and "right" in that sentence.

What makes this a law

Logical necessity. That is simply what indentation *IS*. That's what it *means* to indent something to show its structure.

If you notice a pattern where beginners trip against this rule because they don't indent the arms of conditionals properly inside do blocks, should strict adherence to this principle take precendence over the intuition of prospective users of the language?

The beginners I have taught Haskell to over the last five or six years have made many mistakes, but that particular one has never been a problem for them. Mind you, that may be because I teach them "don't use 'do' (yet)". While they haven't had any problem with 'if' inside 'do', those of my students who have found 'do' in their textbook and decided to use it have repeatedly run into enormous semantic problems. In particular, pat <- expr LOOKS like an assignment, so they mistakenly expect it to ACT like an assignment. It seems clear, therefore, that the heart of the problem is not the indentation rules, but 'do' in and of itself. Rather than amend the rules, it would be better *for beginners* if 'do' were not in the language at all. Should strict adherence to an indentation principle take precedence over "intuition"? Yes, YES, *YES*, ten thousand times YES. Your "intuition" is my "hopeless obscurity".

On Wed, 2007-08-01 at 16:05 +0200, david48 wrote:

On the topic of indenting, it would be nice if there was a way to tell the compiler the size of the tab characters.

The way it is now, I have to use space characters to indent.

Good! You're doing exactly the right thing according to the Haskell style guide: http://urchin.earth.li/~ian/style/haskell.html :-) Duncan

On 8/1/07, Brandon S. Allbery KF8NH wrote:

On Aug 1, 2007, at 10:05 , david48 wrote:

...

On the topic of indenting, it would be nice if there was a way to tell the compiler the size of the tab characters.

The way it is now, I have to use space characters to indent.

The problem with that is, while there's a standard for the width of a tab on Unix, there isn't on Windows. It's really only safe to use spaces for indentation.

On second thought, I don't even know why I posted this. There's so many things far more important that tabs, and using spaces is truly the only safe way. Sorry for the noise.

On Thursday 26 July 2007, anon wrote:

2007/7/26, Stefan O'Rear :

...

Out of curiousity, what do you find objectionable about (legal):

function argument argument2

| guard = body | guard = body

as compared to (currently illegal):

function argument argument2

| guard = body | guard = body

The extra space, obviously :-) I'm well aware that this is an issue of vanishingly small consequence, but one could likewise dismiss the entire layout business as a needlessly complicated way to save a few keystrokes

On the contrary. Layout, by itself, strictly reduces the number of ways to write any given program. It makes things more consistent across coding styles. That's not an inconsequential benefit.

if one were so inclined. If language complexity is the chief concern, why not dispense with layout altogether (and a few more things beside)? Perhaps fuzzy notions of aesthetics and intuitiveness should weigh into the equation as well unless you don't mind programming in the unadorned lambda calculus.

Jonathan Cast http://sourceforge.net/projects/fid-core http://sourceforge.net/projects/fid-emacs

On Thu, Jul 26, 2007 at 05:34:32PM -0400, anon wrote:

2007/7/26, Stefan O'Rear :

...

As for "why", it's just a matter of Haskell Committee taste. Nothing too deep, just an arbitrary set of rules. That's not much of an explanation, is it? I imagine someone must have given the matter some thought before describing the layout rule in great details in the language report. Perhaps there was a perfectly good reason to preclude this kind of code, but I'm afraid I do need a reason if I am to understand why.

Part of the reason is that the layout rule is supposed to be somewhat independent of the rest of the grammar. It's described as a simple preprocessing state that adds block delimiters { ; } just recongizing a few keywords that open blocks, and otherwise looking at the indentation of the first non-whitespace character on lines. You can allow the syntaxes where something is no less indented than it's containing block by allowing some optional semicolons in the grammar. GHC keeps it's parser in compiler/parser/Parser.y.pp It's a Happy grammar file, it shouldn't be hard to make your change and see how you like it. I think the "gdrh" nonterminal is the one you want to change, add another production that allows ';' '|' quals '=' exp Have fun Brandon Moore