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
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)
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 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:
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 review request)
On 28/02/06, Brian Hulley [EMAIL PROTECTED] wrote: Why? Surely typing one tab is better than having to hit the spacebar 4 (or 8) times? I'm really puzled here. I've been using tabs to indent my C++ code for at least 10 years and don't see the problem. The only problem would be if someone mixed tabs with spaces. Since it has to be either tabs only or spaces only I'd choose tabs only to save keystrokes. I suppose though it is always going to be a matter of personal taste... It's easy to configure most editors (vim and emacs included of course) to treat multiple spaces as if they were tabs, but to only save spaces into your file. This is what I do, as it ensures that the way that the code looks to me in my editor is exactly what it looks like to the compiler. Quite often, if it looks better, I will align things past a tab stop with a few extra spaces (which only has to be done once, if your editor will start the next line at the same indentation as the previous). - Cale ___ 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 review request)
On Wednesday 01 March 2006 02:36, Brian Hulley wrote:
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
Here is my proposed layout rule:
1) All layout keywords (where, of, let, do) must either be
followed by a single element of the corresponding block type, and
explicit block introduced by '{', or a layout block whose first
line starts on the *next* line
I wouldn't have much trouble adapting to that.
and whose indentation is accomplished *only* by tabs
You can't be serious. This would cause far more problems than the
current rule.
Why? Surely typing one tab is better than having to hit the spacebar
4 (or 8) times?
What kind of editor are you using? Notepad?
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.
TAB characters in program text should be forbidden by law. As well as
editors that by default insert a tab char instead of spaces.
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)
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 review request)
Am Mittwoch, 1. März 2006 11:57 schrieb Benjamin Franksen: TAB characters in program text should be forbidden by law. As well as editors that by default insert a tab char instead of spaces. As founding member of the church of The only good Tabbing involves Michaela, I wholeheartedly agree. 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 reviewreque st)
On Wed, 1 Mar 2006 12:35:44 -, Brian Hulley [EMAIL PROTECTED] wrote: The only thing then is what happens when you type backspace or left arrow to get back out to a previous indentation? The Borland IDEs have long supported various smart indentation features, which can each be individually turned on or off (see the third one for the answer to your specific question): * Auto indent mode - Positions the cursor under the first nonblank character of the preceding nonblank line when you press ENTER in the Code Editor. * Smart tab - Tabs to the first non-whitespace character in the preceding line. If Use tab character is enabled, this option is off. * Backspace unindents - Aligns the insertion point to the previous indentation level (outdents it) when you press BACKSPACE, if the cursor is on the first nonblank character of a line. There are a number of other tab-related options as well. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)
Brian Hulley wrote:
Here is my proposed layout rule:
1) All layout keywords (where, of, let, do) must either be followed by a
single element of the corresponding block type, and explicit block
introduced by '{', or a layout block whose first line starts on the
*next* line
I wouldn't have much trouble adapting to that.
and whose indentation is accomplished *only* by tabs
You can't be serious. This would cause far more problems than the current rule.
I would also make it that explicit braces are not allowed to switch off
the layout rule (ie they can be used within a layout),
I don't understand. What does used within a layout mean?
multiline strings would not be permitted,
They aren't now, except with \ escapes. A stray will be caught on the same
line unless the line happens to end with \ and the next line happens to
begin with \, which is exceedingly unusual.
and multiline comments would not be permitted
(pragmas could easily be used just by using --#)
But --# doesn't introduce a comment. And this would make UNPACK pragmas
rather inconvenient to use.
1) When you see a ';' you could immediately tell which block it belongs
to by looking backwards till the next '{'
I guess that might be helpful, but it doesn't seem easier than looking left
to the beginning of the current line and then up to the first less-indented
line.
2) Variable width fonts can be used,
They can be used now, if you adhere to a certain style, but not everyone
likes that style. I wrote in C++ with a variable width font and tabs at one
time, but eventually went back to fixed width. One reason was that I
couldn't use comment layout conventions that tend (in my experience) to
improve readability more than monospacing hurts it. Another reason was that
glyph widths appropriate to natural languages didn't work all that well for
source code. Spaces are much more important in source code than in natural
language, for example. A proportional font designed for source code would be
nice, but I haven't found one yet. Stroustrup used a mixture of proportional
and monospaced glyphs in _The C++ Programming Language_ and it worked well.
or different font faces to
represent different sorts of identifier eg class names, tycons, value
constructors, operators like `seq` as opposed to seq etc
Lots of editors do this with monospaced fonts; I think it's orthogonal to
the layout issue.
3) Using only tabs ensures that vertical alignment goes to the same
position on the screen regardless of the font and tabs could even have
different widths just like in a wordprocessor
Requiring tabs is a really bad idea. Just forget it. Seriously.
4) Any keypress has a localised effect on the parse tree of the buffer
as a whole ( { no longer kill everything which follows and there would
be no {- )
I don't understand why this is an advantage. If you have an editor that
highlights comments in green, then large sections of the program will flash
green while you type a {- -} comment, which might be annoying, but it also
means you'll never forget to close the comment, so the practical benefit of
forbidding {- -}, as opposed to simply not typing it yourself, seems nil.
5) It paves the way for a much more immersive editing environment, but I
can't say more about this at the moment because I haven't finished
writing it yet and it will be a commercial product :-)))
I guess everything has been leading up to this, but my reaction is that it
renders the whole debate irrelevant. The only reason layout exists in the
first place is to make source code look good in ordinary text editors. If
you have a high-level source code editor that manipulates the AST, then you
don't need layout, or tabs, or any of that silly ASCII stuff. The only time
you need to worry about layout is when interoperating with implementations
that use the concrete syntax, and then there's nothing to stop you from
exporting in any style you like. And when importing, there's no reason to
place restrictions on Haskell's layout rule, because the visual layout you
display in the editor need have no connection to the layout of the imported
file.
Using my self-imposed layout rule I'm currently editing all my Haskell
code in a standard text editor using tabs set to 4 spaces and a variable
width font and have no problems.
Which is the best argument for keeping the current rule! If it were changed
as you propose, then someday Hugh Briley would come along and complain that
Haskell's layout syntax squandered screen space---but he *wouldn't* be able
to program in his preferred style, because it would no longer be allowed.
Religious freedom is a good thing.
{- 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 review request)
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
Here is my proposed layout rule:
1) All layout keywords (where, of, let, do) must either be followed
by a single element of the corresponding block type, and explicit
block introduced by '{', or a layout block whose first line starts
on the *next* line
I wouldn't have much trouble adapting to that.
and whose indentation is accomplished *only* by tabs
You can't be serious. This would cause far more problems than the
current rule.
Why? Surely typing one tab is better than having to hit the spacebar 4 (or
8) times?
I would also make it that explicit braces are not allowed to switch
off the layout rule (ie they can be used within a layout),
I don't understand. What does used within a layout mean?
I meant that {;} would be used just like any other construct that has to
respect the layout rule so you could write
let
a = let { b = 6; z = 77;
h = 99;
p = 100} in b+z+h + p
etc but not:
let
a = let { b = 6; z = 77;
h = 99; -- this binding would be part of the outermost
'let'
p = 100} in b+z+h + p
multiline strings would not be permitted,
They aren't now, except with \ escapes. A stray will be caught on
the same line unless the line happens to end with \ and the next line
happens to begin with \, which is exceedingly unusual.
and multiline comments would not be permitted
(pragmas could easily be used just by using --#)
But --# doesn't introduce a comment. And this would make UNPACK
pragmas rather inconvenient to use.
-- # but I hadn't thought about UNPACK...
The motivation in both points is to make it easy for an editor to determine
which lines need to be re-parsed based on the number of leading tabs alone.
1) When you see a ';' you could immediately tell which block it
belongs to by looking backwards till the next '{'
I guess that might be helpful, but it doesn't seem easier than
looking left to the beginning of the current line and then up to the first
less-indented line.
There was an example posted on another thread where someone had got into
confusion by using ; after a let binding in a do construct with an explicit
brace after the 'do' but not after the 'let' (sorry I can't find it again).
Also the current layout rule uses the notion of an implicit opening brace
which is a to be regarded as a real opening brace as far as ';' in concerned
but an unreal non-existent opening brace as far as '}' is concerned. Thus I
think it is a real mix-up.
2) Variable width fonts can be used,
They can be used now, if you adhere to a certain style, but not
everyone likes that style. I wrote in C++ with a variable width font and
tabs
at one time, but eventually went back to fixed width. One reason was
that I couldn't use comment layout conventions that tend (in my
experience)
to improve readability more than monospacing hurts it. Another reason
was that glyph widths appropriate to natural languages didn't work
all that well for source code. Spaces are much more important in
source code than in natural language, for example. A proportional
font designed for source code would be nice, but I haven't found one
yet. Stroustrup used a mixture of proportional and monospaced glyphs
in _The C++ Programming Language_ and it worked well.
or different font faces to
represent different sorts of identifier eg class names, tycons, value
constructors, operators like `seq` as opposed to seq etc
Lots of editors do this with monospaced fonts; I think it's
orthogonal to the layout issue.
For example on Windows Trebuchet MS is a very nice font, also Verdana, both
of which are not monospaced. But yes I agree it's not a major issue and I
just see the option of being able to use them as a nice side-effect.
3) Using only tabs ensures that vertical alignment goes to the same
position on the screen regardless of the font and tabs could even
have different widths just like in a wordprocessor
Requiring tabs is a really bad idea. Just forget it. Seriously.
I'm really puzled here. I've been using tabs to indent my C++ code for at
least 10 years and don't see the problem. The only problem would be if
someone mixed tabs with spaces. Since it has to be either tabs only or
spaces only I'd choose tabs only to save keystrokes. I suppose though it is
always going to be a matter of personal taste...
4) Any keypress has a localised effect on the parse tree of the
buffer as a whole ( { no longer kill everything which follows and
there would be no {- )
I don't understand why this is an advantage. If you have an editor
that highlights comments in green, then large sections of the program
will flash green while you type a {- -} comment, which might be
annoying, but it also means you'll never forget to close the comment,
so the practical benefit of forbidding {- -}, as opposed to simply
not typing it yourself,
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)
On Wed, 1 Mar 2006, Brian Hulley wrote: Ben Rudiak-Gould wrote: Brian Hulley wrote: Here is my proposed layout rule: snip and whose indentation is accomplished *only* by tabs You can't be serious. This would cause far more problems than the current rule. Why? Surely typing one tab is better than having to hit the spacebar 4 (or 8) times? Not when it prevents me from ever exhibiting the slightest shred of style in my code. I use that control for readability purposes in my code. -- [EMAIL PROTECTED] My religion says so explains your beliefs. But it doesn't explain why I should hold them as well, let alone be restricted by them. ___ 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 review request)
BH Why? Surely typing one tab is better than having to hit the spacebar 4 (or 8) BH times? PC Not when it prevents me from ever exhibiting the slightest shred of style PC in my code. I use that control for readability purposes in my code. [snip] BH I'm really puzled here. I've been using tabs to indent my C++ code for at BH least 10 years and don't see the problem. At least two reasons: 1. C++ doesn't care about any whitespace (except to separate tokens). Haskell cares about leading whitespace (which it is clear you are thinking a lot about...) but 2. as Philippa mentioned, Haskell programmers care a ton about inter-line, inter-word layout/alignment, for example, lining up = signs and arguments to functions in pattern matches, etc. C++ does not invite this style of declarative programming so it is not surprising that it wasn't an issue: aside from the indentation, I rarely type fancy whitespace inside a giving line of C++ code to align elements with those on a preceding line. In Haskell, this unofficial layout style doesn't affect the machine-parsing of the code, but rather the human-parsing of the code. (In fact, it's one of my favorite things about Haskell.) If you want to see what can be accomplished with variable width fonts and complex layouts (not just beginning of lines but rather inter-line, inter-word alignment) you should checkout lhs2TeX. They accomplish all their magic with spaces. BH The only problem would be if BH someone mixed tabs with spaces. Since it has to be either tabs only or BH spaces only I'd choose tabs only to save keystrokes. BTW, tab doesn't type the tab character (at least in emacs and I think vim) but instead moves the left edge of the current line by adding or deleted spaces (or trying to ident the right amount). This usually means you don't have to type 4 or 8 spaces. (And anyway, I would just hold the key down if I had to type more than one spacebar, etc.) [snip] For example on Windows Trebuchet MS is a very nice font, also Verdana, both of which are not monospaced. But yes I agree it's not a major issue and I just see the option of being able to use them as a nice side-effect. Very few programmers I know would go to variable width fonts just to use some Microsoft font to edit code... (BTW I like Trebuchet and Verdana too.) To each his/her own! Cheers, Jared. -- 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
Brian Hulley [EMAIL PROTECTED] writes:
You can't be serious. This would cause far more problems than the
current rule.
Why? Surely typing one tab is better than having to hit the spacebar 4
(or 8) times?
What you type depends on your editor. I hit tab, and the editor
inserts an appropriate number of spaces. (I thought all editors did
this now?)
There was an example posted on another thread where someone had got
into confusion by using ; after a let binding in a do construct with
an explicit brace after the 'do' but not after the 'let' (sorry I
can't find it again).
If you allow {- everything becomes a lot
more complicated and who needs them anyway?
Multi line comments are nice for commenting out blocks of code. It is
much less intrusive, in particular if you're using version control.
back to editing a function at the top of a file. Things like {- would
mean that all the parse trees for everything after it would have to be
discarded. Also, flashing of highlighting on this scale could be very
annoying for a user, so I'd rather just delete this particular
possibility of the user getting annoyed when using my software :-)
Couldn't your editor just be a little bit smarter? E.g. count the {-s
and -}s, and only comment-hilight them if there are two of them?
Retain a history of old parse trees, so that it is quick to return to
a previous one?
Haskell, which in turn might lead to more people understanding and
therefore using the language, more libraries, more possibilities for
You forget one thing:
Avoid success at all costs
:-)
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
