PrefixMap: code review request

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Ben Franksen-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code review request)

Daniel Fischer-4
In reply to this post by Ben Franksen-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code review request)

Ben Rudiak-Gould
In reply to this post by Duncan Coutts
Duncan Coutts wrote:
> hIDE and Visual Haskell use the ghc lexer and get near-instantaneous
> syntax highlighting.

Hmm... I just installed Visual Haskell 0.1, and when I type in the editor,
CPU usage rises to about 70% and there's a noticeable delay before each
character appears on the screen. This is a very short module (~100 lines)
and a Pentium M 1600 CPU. Am I doing something wrong?

-- Ben

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule

Ben Rudiak-Gould
In reply to this post by Ketil Malde-3
Ketil Malde wrote:
> Multi line comments are nice for commenting out blocks of code.

They're also nice for comments within a line. E.g. haskell-src-exts contains
the declaration

   data HsQualConDecl
           = HsQualConDecl SrcLoc
               {- forall -} [HsName] {- . -} HsContext {- => -} HsConDecl

Probably half of my uses of {- -} begin and end on the same line.

-- Ben

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code review request)

Ben Rudiak-Gould
In reply to this post by Ben Franksen-2
Benjamin Franksen wrote:
> TAB characters in program text should be forbidden by law.

Well... they are quite useful for lining things up if you're using a
proportional font, and I don't think proportionally-spaced code is a bad
idea. I want them to be optional. But it would be nice if parsers would warn
about (or even reject) programs whose meaning depends on tab width.

-- Ben

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Layout rule (was Re: PrefixMap: code review request)

Duncan Coutts
In reply to this post by Ben Rudiak-Gould
On Wed, 2006-03-01 at 22:58 +0000, Ben Rudiak-Gould wrote:
> Duncan Coutts wrote:
> > hIDE and Visual Haskell use the ghc lexer and get near-instantaneous
> > syntax highlighting.
>
> Hmm... I just installed Visual Haskell 0.1, and when I type in the editor,
> CPU usage rises to about 70% and there's a noticeable delay before each
> character appears on the screen. This is a very short module (~100 lines)
> and a Pentium M 1600 CPU. Am I doing something wrong?

I can't say too much about the internals of VH since I've not see the
code, only the description.

Perhaps that's because they're starting the parser immediately after
every keystroke and/or not killing the parser when the user types
another key. I've been using hIDE on a Pentium M 1600 laptop and on the
size of modules I've tried so far it's quick. The syntax highlighting
updates immediately and the type checker shows up errors a second or so
after I stop typing (which is because we wait about that long before
starting the parser).

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewreque st)

Steve Schafer
In reply to this post by Brian Hulley
On Wed, 1 Mar 2006 12:35:44 -0000, "Brian Hulley" <[hidden email]>
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code review request)

Ben Rudiak-Gould
In reply to this post by Ben Rudiak-Gould
I wrote:
> I just installed Visual Haskell 0.1, and when I type in the
> editor, CPU usage rises to about 70% and there's a noticeable delay
> before each character appears on the screen.

This is no longer happening, so I guess I ran afoul of a bug.

-- Ben

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Brian Hulley
In reply to this post by Brian Hulley
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Jared Updike
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 <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>


--
http://www.updike.org/~jared/
reverse ")-:"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Brian Hulley
In reply to this post by 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.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code review request)

Cale Gibbard
In reply to this post by Brian Hulley
On 28/02/06, Brian Hulley <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Daniel Fischer-4
In reply to this post by Brian Hulley
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Brian Hulley
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Malcolm Wallace
In reply to this post by Brian Hulley
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Daniel Fischer-4
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Malcolm Wallace
Daniel Fischer <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Brian Hulley
In reply to this post by Malcolm Wallace
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Layout rule (was Re: PrefixMap: code reviewrequest)

Daniel Fischer-4
In reply to this post by Malcolm Wallace
Am Montag, 6. März 2006 16:52 schrieb Malcolm Wallace:

> Daniel Fischer <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12