Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Benjamin Franksen wrote: [snip] I am used to hitting TAB key and get the correct number of spaces, according to how I configured my editor (NEdit) for the current language mode. The only thing then is what happens when you type backspace or left arrow to get back out to a previous indentation? If the TAB character inserts spaces, there's no problem going from left to right but it would seem more complicated to go back out again ie without having to type backspace 4 times and try to hope when outdenting more that I haven't typed backspace 23 times instead of 24 times by mistake thus not getting to the column I expected. This is my only reason for wanting to keep tab characters in the text, and certainly it does give some disadvantages when trying to line up '|' '=' etc vertically - at the moment I admit my layouts do end up a bit contrived as I have to use more newlines to ensure I can use tabs only to accomplish the line-up... So any solutions welcome :-) Regards, Brian. "... flee from the Hall of Learning. This Hall is dangerous in its perfidious beauty, is needed but for thy probation. Beware, Lanoo, lest dazzled by illusive radiance thy soul should linger and be caught in its deceptive light." -- Voice of the Silence stanza 33 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
On Wednesday 01 March 2006 13:35, Brian Hulley wrote: > Benjamin Franksen wrote: > > [snip] > > I am used to hitting TAB key and get the correct number of spaces, > > according to how I configured my editor (NEdit) for the current > > language mode. > > The only thing then is what happens when you type backspace or left > arrow to get back out to a previous indentation? If the TAB character > inserts spaces, there's no problem going from left to right but it > would seem more complicated to go back out again ie without having to > type backspace 4 times and try to hope when outdenting more that I > haven't typed backspace 23 times instead of 24 times by mistake thus > not getting to the column I expected. With NEdit, hitting backspace /right after/ hitting the tab key deletes all the whitespace that were inserted, be it a tab character or multiple spaces. (This works also if the line was auto-indented to the same indentation depth as the previous one. That is, hit enter and then backspace, and you are at previous indentation level minus one.) If, however, you press any other key (e.g. any arrow keys), subsequent backspace will only delete a single space. Other behaviors can be easily implemented by writing a macro and binding it to the backspace key. The same is most probably true for emacs. The upshot is: Any decent modern text editor allows to map keys like tab and backspace to almost any action desired, depending on context, language mode, whatever. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Brian Hulley wrote: [snip] So any solutions welcome :-) Thank to everyone who replied to my queries about this whole layout issue. One other thing I've been wanting to ask (not to change! :-)) for a while is: how is the following acceptable according to the rules in the Haskell98 report where "where" is one of the lexemes, which when followed by a line more indented than the line the layout-starting-lexeme is on, should start an implicit block: module M where data T = .-- not indented! According to my understanding of the layout algorithm, the above code would have to be written: module M where data T = Can anyone shed some light on what the formal rule is that allows the first (and very useful) way of laying out code to be ok? Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Layout only applies when something is less indented than previous lines, I believe... e.g. > do > c <- getContents "filename" > putStrLn "blah" or >do >x <- getContents "filename" >putStrLn "ok" works fine but > do > c <- blahAction > putStrLn "blah" obviously won't work Jared. On 3/2/06, Brian Hulley <[EMAIL PROTECTED]> wrote: > Brian Hulley wrote: > [snip] > > So any solutions welcome :-) > > Thank to everyone who replied to my queries about this whole layout issue. > > One other thing I've been wanting to ask (not to change! :-)) for a while > is: how is the following acceptable according to the rules in the Haskell98 > report where "where" is one of the lexemes, which when followed by a line > more indented than the line the layout-starting-lexeme is on, should start > an implicit block: > >module M where >data T = .-- not indented! > > According to my understanding of the layout algorithm, the above code would > have to be written: > >module M where > data T = > > Can anyone shed some light on what the formal rule is that allows the first > (and very useful) way of laying out code to be ok? > > Thanks, Brian. > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- http://www.updike.org/~jared/ reverse ")-:" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Brian Hulley wrote:
Brian Hulley wrote:
One other thing I've been wanting to ask (not to change! :-)) for a
while is: how is the following acceptable according to the rules in
the Haskell98 report where "where" is one of the lexemes, which when
followed by a line more indented than the line the
layout-starting-lexeme is on, should start an implicit block:
module M where
data T = .-- not indented!
According to my understanding of the layout algorithm, the above code
would have to be written:
module M where
data T =
Can anyone shed some light on what the formal rule is that allows the
first (and very useful) way of laying out code to be ok?
The solution (as someone pointed out to me in an email) is that the layout
block only *finishes* when the current indentation is *less* than the
indentation of the lines in the layout block (rather than *starting* only
when the current indentation is *more* than the indentation of the line
containing the "where" etc).
However I think there is an error in the description of this in section 2.7
of the Haskell98 report, which states:
"If the indentation of the non-brace lexeme immediately following a where,
let, do or of is less than or equal to the current indentation level, then
instead of starting a layout, an empty list "{}" is inserted, and layout
processing occurs for the current level ..."
I dispute the "or equal" in the above statement, since it seems to be
clearly in contradiction to what is actually being done.
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Am Freitag, 3. März 2006 19:21 schrieb Brian Hulley:
> Brian Hulley wrote:
> > Brian Hulley wrote:
> > One other thing I've been wanting to ask (not to change! :-)) for a
> > while is: how is the following acceptable according to the rules in
> > the Haskell98 report where "where" is one of the lexemes, which when
> > followed by a line more indented than the line the
> > layout-starting-lexeme is on, should start an implicit block:
> >
> > module M where
> > data T = .-- not indented!
> >
> > According to my understanding of the layout algorithm, the above code
> > would have to be written:
> >
> > module M where
> > data T =
> >
> > Can anyone shed some light on what the formal rule is that allows the
> > first (and very useful) way of laying out code to be ok?
>
> The solution (as someone pointed out to me in an email) is that the layout
> block only *finishes* when the current indentation is *less* than the
> indentation of the lines in the layout block (rather than *starting* only
> when the current indentation is *more* than the indentation of the line
> containing the "where" etc).
>
> However I think there is an error in the description of this in section 2.7
> of the Haskell98 report, which states:
>
> "If the indentation of the non-brace lexeme immediately following a where,
> let, do or of is less than or equal to the current indentation level, then
> instead of starting a layout, an empty list "{}" is inserted, and layout
> processing occurs for the current level ..."
>
> I dispute the "or equal" in the above statement, since it seems to be
> clearly in contradiction to what is actually being done.
>
> Regards, Brian.
>
AFAICT, the description in the report is correct, *except for the 'where' in
module LayOut where*.
Consider
module LayOut
where
fun x y = bum x y + y 4
where
bum x y = y x
a) the module-where is at indentation level 0, accepted here, but nowhere
else, even if I indent fun and bum, fun's where must be indented further than
fun itself.
b) bum's definition is top-level now, but in
module LayOut
where
fun x y = bum x y + y 4
where
bum x y = y x
it is local (bum is indented more than fun, but less than where), in perfect
accord with the report.
Even
module LayOut
( fun,
bum)
where
fun x y = bum x y + y 4
where
bum x y = y x
is accepted.
So my guess is that layout-processing is applied only to the module-body, not
to the module head and probably that should be mentioned in the report.
BTW, when I read about layout in the report, this irritated me, too, so thanks
for asking.
Cheers,
Daniel
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Daniel Fischer wrote: Am Freitag, 3. März 2006 19:21 schrieb Brian Hulley: Brian Hulley wrote: Brian Hulley wrote: [snip] AFAICT, the description in the report is correct, *except for the 'where' in module LayOut where*. [snip] So my guess is that layout-processing is applied only to the module-body, not to the module head and probably that should be mentioned in the report. Thanks - that's quite a relief because my incremental parser absolutely relies on the indentation of a child block to be more than that of it's parent in the AST... Perhaps a future incarnation of Haskell could just omit the keyword "where" in the module head to avoid all this confusion. Also, all the tutorials (and book) I've read only mention the layout rule in passing somewhere deep inside the text and usually give a rather unsatisfactory hand-waving description that omits to mention the special case for "where" in the module head and/or the need for the sub-block to be indented more than the parent block, so I think depending on what tutorials people have read, putting this together with the module "where", a lot of confusion is floating about... Perhaps a wiki page is indicated? Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Brian Hulley wrote:
> However I think there is an error in the description of this in
> section 2.7 of the Haskell98 report, which states:
>
> "If the indentation of the non-brace lexeme immediately following a
> where, let, do or of is less than or equal to the current indentation
> level, then instead of starting a layout, an empty list "{}" is
> inserted, and layout processing occurs for the current level ..."
>
> I dispute the "or equal" in the above statement, since it seems to be
> clearly in contradiction to what is actually being done.
Section 2.7 does say that it is an informal description, so although it
is correct, it is not complete. In the case of the module header, the
question is really "what is the current indentation level?" (that we
must be strictly greater than). The answer can be found in the formal
definition of the layout rule in section 9.3. At the beginning of the
module, there is _no_ current indentation level - thus the fourth
equation of L applies.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Am Montag, 6. März 2006 12:30 schrieb Malcolm Wallace:
> Brian Hulley wrote:
> > However I think there is an error in the description of this in
> > section 2.7 of the Haskell98 report, which states:
> >
> > "If the indentation of the non-brace lexeme immediately following a
> > where, let, do or of is less than or equal to the current indentation
> > level, then instead of starting a layout, an empty list "{}" is
> > inserted, and layout processing occurs for the current level ..."
> >
> > I dispute the "or equal" in the above statement, since it seems to be
> > clearly in contradiction to what is actually being done.
>
> Section 2.7 does say that it is an informal description, so although it
> is correct, it is not complete. In the case of the module header, the
> question is really "what is the current indentation level?" (that we
> must be strictly greater than). The answer can be found in the formal
> definition of the layout rule in section 9.3. At the beginning of the
> module, there is _no_ current indentation level - thus the fourth
> equation of L applies.
>
> Regards,
> Malcolm
I think, the third from last equation of L applies, since
"If the first lexeme of a module is _not_ { or module, then it is preceded by
{n} where n is the indentation of the lexeme.", so we start L with
L ('module':ts) [].
Another thing that irritates me:
in section 9.5, we have the production
body-> { impdecls; topdecls }
| { impdecls }
| { topdecls }
The first line seems to suggest that import declaraions were admissible also
after topdecls, but any attempt to place an impdecl after a topdecl leads
--fortunately-- to a parse error in hugs and ghc, shouldn't the production be
body-> { impdecls }; { topdecls } ?
Cheers,
Daniel
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Daniel Fischer <[EMAIL PROTECTED]> wrote:
> > At the beginning of the module, there is _no_ current indentation
> > level - thus the fourth equation of L applies.
>
> I think, the third from last equation of L applies, since
> "If the first lexeme of a module is _not_ { or module, then it is
> preceded by {n} where n is the indentation of the lexeme.", so we
> start L with L ('module':ts) [].
Indeed, and thus, when we get to the end of the first 'where' token, the
stack of indentation contexts is still empty. Hence my remark about the
fourth equation.
> body -> { impdecls; topdecls }
> | { impdecls }
> | { topdecls }
>
> The first line seems to suggest that import declaraions were
> admissible also after topdecls, but any attempt to place an impdecl
> after a topdecl leads --fortunately-- to a parse error in hugs and
> ghc, shouldn't the production be
>
> body -> { impdecls }; { topdecls } ?
I think you have mis-read the brace characters as if they were the EBNF
meta symbols for repetition. They do in fact mean the literal brace
symbol, which may be explicitly present in the source, or inserted by
the layout rule. Thus, topdecls must follow impdecls, and be at the
same indentation level if layout matters.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Malcolm Wallace wrote:
Brian Hulley wrote:
However I think there is an error in the description of this in
section 2.7 of the Haskell98 report, which states:
"If the indentation of the non-brace lexeme immediately following a
where, let, do or of is less than or equal to the current
indentation level, then instead of starting a layout, an empty list
"{}" is inserted, and layout processing occurs for the current
level ..."
I dispute the "or equal" in the above statement, since it seems to be
clearly in contradiction to what is actually being done.
Section 2.7 does say that it is an informal description, so although
it is correct, it is not complete. In the case of the module header,
the question is really "what is the current indentation level?" (that
we must be strictly greater than). The answer can be found in the
formal definition of the layout rule in section 9.3. At the
beginning of the module, there is _no_ current indentation level -
thus the fourth equation of L applies.
Thanks. However I do think the fact that there is a special case for the
module head would merit a mention in section 2.7, because at the moment it's
a bit like looking at a stack of chocolate cookies and defining the top one
to be vanilla - it works but who'd ever have thought of it for themselves
just looking at the visual indentation on the screen?
On the subject of 9.3, I'm puzzled by:
"For the purposes of the layout rule, Unicode characters in a source program
are considered to be of the same, fixed, width as an ASCII character.
However, to avoid visual confusion, programmers should avoid writing
programs in which the meaning of implicit layout depends on the width of
non-space characters."
Surely almost all Haskell programs rely on the width of every non-space
character to be the same as the width of a space (ie monospaced font where
one character == one glyph) as in
let a = 3
b = 5
I'd suggest that the word "non-space" should be replaced by "multi-glyph"
and perhaps there could be a recommendation to avoid the use of multi-glyph
characters in the first place (otherwise an editor would have to be smart
enough to maintain the correct multi-glyph spaces in the columns under
them...)
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Am Montag, 6. März 2006 16:52 schrieb Malcolm Wallace:
> Daniel Fischer <[EMAIL PROTECTED]> wrote:
> > > At the beginning of the module, there is _no_ current indentation
> > > level - thus the fourth equation of L applies.
> >
> > I think, the third from last equation of L applies, since
> > "If the first lexeme of a module is _not_ { or module, then it is
> > preceded by {n} where n is the indentation of the lexeme.", so we
> > start L with L ('module':ts) [].
>
> Indeed, and thus, when we get to the end of the first 'where' token, the
> stack of indentation contexts is still empty. Hence my remark about the
> fourth equation.
>
Aha, I read 'At the beginning of the module' as 'at the very beginning',
whereas you meant 'At the beginning, after the module-where', sorry to have
misunderstood.
> > body-> { impdecls; topdecls }
> >
> > | { impdecls }
> > | { topdecls }
> >
> > The first line seems to suggest that import declaraions were
> > admissible also after topdecls, but any attempt to place an impdecl
> > after a topdecl leads --fortunately-- to a parse error in hugs and
> > ghc, shouldn't the production be
> >
> > body-> { impdecls }; { topdecls } ?
>
> I think you have mis-read the brace characters as if they were the EBNF
> meta symbols for repetition. They do in fact mean the literal brace
> symbol, which may be explicitly present in the source, or inserted by
> the layout rule. Thus, topdecls must follow impdecls, and be at the
> same indentation level if layout matters.
Ah, damn, fonts are too similar in my browser. And since I've never used
explicit braces at the top level, I didn't expect literal brace-characters
there.
>
> Regards,
> Malcolm
Thanks,
Daniel
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
