Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)

2006-03-03 Thread Cale Gibbard
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 review request)

2006-03-01 Thread Daniel Fischer
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 review request)

2006-03-01 Thread Benjamin Franksen
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 review request)

2006-03-01 Thread Duncan Coutts
On Wed, 2006-03-01 at 01:36 +, Brian Hulley wrote:

> Currently all the ASCII editors I know of only do keyword highlighting, or 
> occasional ("wait a second while I'm updating the buffer") identifier 
> highlighting.

hIDE and Visual Haskell use the ghc lexer and get near-instantaneous
syntax highlighting. Because they use a proper lexer they get fully
accurate highlighting, not your ordinary "fairly close" regex-based
highlighting. They also only re-lex the bits needed. They keep the lexer
state for the start of each line and when a line changes, start
re-lexing from the beginning of that line and keep going until the lexer
ends up in the same state as a previously saved state on a line. I may
be wrong but I think there is an optimisation to not lex beyond the end
of the current screen until it is scrolled. This means that even when
someone types "{-"m you never have to re-lex & re-highlight more than a
screen full.

> What I'm trying to get however is complete grammatical 
> highlighting and type checking that is instantaneous as the user types code, 
> so this means that the highlighter/type checker needs a complete AST (with 
> 'gap' nodes to represent spans of incomplete/bad syntax) to work from.

With hIDE and Visual Haskell we have found it sufficient to do a
complete parse rather than do it incrementally. We wait for a second or
so after the user has stopped typing (since highlighting errors as
you're actually typing would just be annoying) and then run the ghc
front end. This is sufficiently fast (except perhaps on very large
modules).

> However it is way too expensive to re-parse the whole of a big buffer after 
> every keypress (I tried it with a parser written in C++ to parse a variant 
> of ML and even with the optimized build and as many algorithmic 
> optimizations as I could think of it was just far too slow, and I wasn't 
> even trying to highlight duplicate identifiers or do type inference)

It may be possible to do some more caching to speed things up without
going to a full incremental parser. For example the editor could
maintain a buffer of lexed symbols and have a traditional parser use
that. It may also be possible to just re-parse parts of the file.

> Thus to get a fast responsive editing environment which needs to maintain a 
> parse of the whole buffer to provide effective grammatical highlighting and 
> not just trivial keyword highlighting it seems (to me) to be essential to be 
> able to limit the effect of any keystroke especially when the user is just 
> typing text from left to right but where there may be more stuff after the 
> cursor eg if the user has gone 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 
> :-) thus my hopeless attempts to convince everyone that {- is bad news all 
> round :-)))

As I mentioned, it is possible to limit the effect of a {- to a screen
full of re-lexing. I grant you that it's likely to do worse things to
your incremental parser.

Duncan

___
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)

2006-02-28 Thread Jared Updike
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 (was Re: PrefixMap: code review request)

2006-02-28 Thread Philippa Cowderoy
On Wed, 1 Mar 2006, Brian Hulley wrote:

> Ben Rudiak-Gould wrote:
> > Brian Hulley wrote:
> > > Here is my proposed layout rule:
> > > 

> > > 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)

2006-02-28 Thread Brian Hulley

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 yourse

[Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)

2006-02-28 Thread Ben Rudiak-Gould

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