Re: [Haskell-cafe] The Layout Rule

2012-06-21 Thread Tillmann Rendel
Hi Michael, Michael D. Adams wrote: I am looking for background material on how GHC and other Haskell compilers implement the layout rule. In the context of our work on syntactic extensibility, we have implemented a declarative and extensible mechanism to specify and implement layout rules

[Haskell-cafe] The Layout Rule

2012-06-19 Thread Michael D. Adams
I am looking for background material on how GHC and other Haskell compilers implement the layout rule. Are there any papers, documentation, commentary, etc. that discus the actual implementation of this rule (even if only a paragraph or two)? I've already looked at the parsing code in GHC

RE: New Layout Rule take 2

2006-12-20 Thread Simon Marlow
[EMAIL PROTECTED] wrote: I have made some improvements to the algorithm, and I am happy to say that with some minor tweaks, it correctly lays out the programs in the nofib suite. the algorithm is not much more complicated than the current one in the report, but doesn't have the parse-error

[Haskell-cafe] RE: New Layout Rule take 2

2006-12-20 Thread Simon Marlow
[EMAIL PROTECTED] wrote: I have made some improvements to the algorithm, and I am happy to say that with some minor tweaks, it correctly lays out the programs in the nofib suite. the algorithm is not much more complicated than the current one in the report, but doesn't have the parse-error

[Haskell-cafe] New Layout Rule take 2

2006-12-09 Thread John Meacham
I have made some improvements to the algorithm, and I am happy to say that with some minor tweaks, it correctly lays out the programs in the nofib suite. the algorithm is not much more complicated than the current one in the report, but doesn't have the parse-error rule. it does require a single

New Layout Rule

2006-12-08 Thread John Meacham
Motivated by some recent discussion, I thought I would explore the possibilty of formalizing the haskell layout rule without the dreaded parse-error clause, as in, one that can be completly handled by the lexer. motivated by that I have written a little program that takes a haskell file

Re: New Layout Rule

2006-12-08 Thread John Meacham
On Fri, Dec 08, 2006 at 03:26:30PM +, Ian Lynagh wrote: On Fri, Dec 08, 2006 at 02:33:47AM -0800, John Meacham wrote: Motivated by some recent discussion, I thought I would explore the possibilty of formalizing the haskell layout rule without the dreaded parse-error clause, as in, one

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

2006-03-07 Thread Daniel Fischer
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

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

2006-03-06 Thread Malcolm Wallace
, 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

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

2006-03-06 Thread Malcolm Wallace
- { 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

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

2006-03-06 Thread Brian Hulley
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

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

2006-03-04 Thread Daniel Fischer
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,

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

2006-03-04 Thread Brian Hulley
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

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

2006-03-03 Thread 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

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

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

2006-03-02 Thread 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

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

2006-03-02 Thread 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

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

2006-03-02 Thread 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,

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

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

2006-03-01 Thread Brian Hulley
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

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

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

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.

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

2006-03-01 Thread Ben Rudiak-Gould
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.

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

2006-03-01 Thread Ben Rudiak-Gould
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

[Haskell-cafe] Re: Layout rule

2006-03-01 Thread Ben Rudiak-Gould
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 {- = -}

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

2006-03-01 Thread Duncan Coutts
On Wed, 2006-03-01 at 22:58 +, 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

Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewreque st)

2006-03-01 Thread Steve Schafer
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

[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

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

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

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

Re: [Haskell-cafe] Layout rule

2006-02-28 Thread Ketil Malde
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

Re: layout rule infelicity

2002-05-31 Thread Ketil Z. Malde
Jon Fairbairn [EMAIL PROTECTED] writes: Why -f anyway? It took me ages to work out what -fallow-overlapping-instances meant -- I wondered how fallow could apply to overlapping instances. I suppose it's a GCCism, where options starting with -f specifiy *f*lags. (Which doesn't seem to apply

Re: layout rule infelicity

2002-05-30 Thread Ashley Yakeley
At 2002-05-30 02:26, Jon Fairbairn wrote: I think this is extremely bad language design! In general I like having layout rules, but ... What's the deal with the whole layout thing anyway? I've never come across it before in another language. Is it an academic thing? It drove me nuts when I

Re: layout rule infelicity

2002-05-30 Thread Ashley Yakeley
At 2002-05-30 02:46, I wrote: What's the deal with the whole layout thing anyway? I've never come across it before in another language. Oh, wait, there's Python and Ruby. For some reason it doesn't bother me so much with them. -- Ashley Yakeley, Seattle WA

Re: layout rule infelicity

2002-05-30 Thread Lennart Augustsson
Ashley Yakeley wrote: At 2002-05-30 02:26, Jon Fairbairn wrote: I think this is extremely bad language design! In general I like having layout rules, but ... What's the deal with the whole layout thing anyway? I've never come across it before in another language. Is it an academic thing?

Re: layout rule infelicity

2002-05-30 Thread D. Tweed
why C++ code isn't compiling only to realise that, whilst indented structurally the semi-colons are missing :-S I suspect using layout rule is forever destined to be controversial... ___cheers,_dave_ www.cs.bris.ac.uk/~tweed/ | `It's no good

Re: layout rule infelicity

2002-05-30 Thread Ashley Yakeley
At 2002-05-30 02:54, Lennart Augustsson wrote: If you look at C ( offspring), it's not the {;} that makes the code readable, it's the indentation that does. So why not acknowledge that? In C, the indentation is an important visual clue, but there are many different indentation styles. It's

Re: layout rule infelicity

2002-05-30 Thread George Russell
I like layout but I think the existing rules are too complicated. Unfortunately it's difficult to do anything with them without breaking vast swathes of existing code, so we'll just have to put up with them. The reason I think layout is better than using {'s and ,'s is that humans use the

Re: layout rule infelicity

2002-05-30 Thread Ketil Z. Malde
Martin Odersky [EMAIL PROTECTED] writes: Redundancy maybe? What's wrong in having both layout and punctuation? Short answer: What's wrong with it is that humans use layout to infer the semantic meaning, compilers use punctuation. Thus it's not really redundancy. -kzm -- If I haven't seen

Re: layout rule infelicity

2002-05-30 Thread Johannes Waldmann
that would allow them declared untyped. of course I know (some of) the `academic' background (type inference, type checking) but what about it from a software engineering point of view? \end{rant} .. I think neither the layout rule nor type inferencing are likely to disappear from Haskell

Re: layout rule infelicity

2002-05-30 Thread Johannes Waldmann
... layout rules somewhat like Haskell's. In our experience it was the single thing that confused students most. same here, for exactly these reasons. students get really confused. on the other hand, students regularily get confused by other things as well, like homework assignments on

Re: layout rule infelicity

2002-05-30 Thread Ashley Yakeley
At 2002-05-30 04:19, Johannes Waldmann wrote: same here, for exactly these reasons. students get really confused. on the other hand, students regularily get confused by other things as well, like homework assignments on formal languages, so that alone is not enough reason to drop the subject

Re: layout rule infelicity

2002-05-30 Thread Ashley Yakeley
At 2002-05-30 03:59, Ketil Z. Malde wrote: Short answer: What's wrong with it is that humans use layout to infer the semantic meaning, No... layout by itself can't be trusted. It's only a clue. One needs to learn the precise Haskell-specific layout rules, and they're not obvious. -- Ashley

Re: layout rule infelicity

2002-05-30 Thread Han Tuong Hau
Hi everyone, I thought I would bring a students perspective into this discussion. Moving from a C background to Haskell, the layout wasn't very intuitive at first. This was mainly due to my hand's on approach (looking at examples and trying to code similar programs). Given that if i read up on

Re: layout rule infelicity

2002-05-30 Thread Jon Fairbairn
too. I wasn't fit enough to follow the earlier discussions of the layout rule, so I'm not sure how this interacts with previous awkward cases. I'd be happiest if we could come up with a rule that didn't involve sticking in braces and semicolons because it won't parse otherwise. Can someone remind

Re: layout rule infelicity

2002-05-30 Thread George Russell
Jon Fairbairn wrote [snip] Well, there's two things to consider: Haskell 98, which probably shouldn't change, and extended Haskell, which probably should. Especially if we can make the rules both simpler and better. [snip] How can I resist? I proposed the following revised layout rule some

Re: layout rule infelicity

2002-05-30 Thread Jon Fairbairn
- 4 ) would be fine. I'd like to see a -fuse-simpler-layout-rule¹ option on the compilers. . . Jón 1. Why -f anyway? It took me ages to work out what -fallow-overlapping-instances meant -- I wondered how fallow could apply to overlapping instances. -- Jón Fairbairn

Re: layout rule infelicity

2002-05-30 Thread Andrew J Bromage
G'day all. On Thu, May 30, 2002 at 01:10:03PM +0200, Johannes Waldmann wrote: Python has it as well (they stole it from Haskell?) Python's layout rule looks more like Occam's than Haskell's, to my eyes. Aside: Was Occam the first language of the post-punched-card era to use layout as syntax

Re: layout rule infelicity

2002-05-30 Thread Alexander V. Voinov
Hi All, Andrew J Bromage wrote: G'day all. On Thu, May 30, 2002 at 01:10:03PM +0200, Johannes Waldmann wrote: Python has it as well (they stole it from Haskell?) Python's layout rule looks more like Occam's than Haskell's, to my eyes. Aside: Was Occam the first language

Re: layout rule infelicity

2002-05-30 Thread Frank Atanassow
[redirected to haskell-cafe] Ashley Yakeley wrote (on 30-05-02 03:18 -0700): At 2002-05-30 02:54, Lennart Augustsson wrote: If you look at C ( offspring), it's not the {;} that makes the code readable, it's the indentation that does. So why not acknowledge that? In C, the indentation is

Re: layout rule infelicity

2002-05-30 Thread Eray Ozkural
On Thursday 30 May 2002 13:43, Frank Atanassow wrote: Anyway, I have the feeling that, for every person on this list who complains about layout being unintuitive, there are 10 people who would say the opposite. Shall we take a poll? It's not unintuitive, it's counter-intuitive. :) The errors

Re: layout rule infelicity

2002-05-30 Thread Abraham Egnor
Just to add my voice to the din... I come from a c/c++/java background, and I taught myself haskell. The layout rules were the part I had the least problem with. I'd prefer that if any change is made it's one that adds options, not removes them. I'm confused as to the source of the problem,

Naming conventions for compiler options [Was: layout rule infelicity]

2002-05-30 Thread oleg
[redirected to haskell-cafe] Jón Fairbairn wrote: 1. Why -f anyway? It took me ages to work out what -fallow-overlapping-instances meant -- I wondered how fallow could apply to overlapping instances. I believe the authors of GHC followed the naming conventions of GCC, which can be gleaned

Re: Naming conventions for compiler options [Was: layout rule infelicity]

2002-05-30 Thread Ashley Yakeley
At 2002-05-30 16:51, [EMAIL PROTECTED] wrote: -Wmissing-protons Compiles BASIC? -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: Naming conventions for compiler options [Was: layout rule infelicity]

2002-05-30 Thread Jay Allen
: Re: Naming conventions for compiler options [Was: layout rule infelicity] At 2002-05-30 16:51, [EMAIL PROTECTED] wrote: -Wmissing-protons Compiles BASIC? -- Ashley Yakeley, Seattle WA

Layout rule (again)

2001-12-11 Thread Ian Lynagh
, predominantly due to the layout rule :-( ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Layout rule

2001-09-30 Thread Ian Lynagh
Hi all The report says The layout rule matches only those open braces that it has inserted in the lexical structure section. However, in the syntax section function L starts L (t:ts) (m:ms) = } : (L (t:ts) ms) if parse-error(t) (Note 1) which AFAICT will implicitly close an explicit open

Re: The dreaded layout rule

1999-08-12 Thread Andreas Rossberg
Simon Marlow wrote: Does it mean that the following expressions would be illegal? if cond then do proc1; proc2 else do proc3; proc4 (case e of Just x - x 0; Nothing - False) Unfortunately, yes. Now one can forget about {} and use layout everywhere. He would no longer be able

Re: The dreaded layout rule

1999-08-03 Thread Christian Sievers
I wrote: lexeme - qvarid | qconid | qvarsym | qconsym | literal | special | reservedop | reservedid Now we could replace qvarsym and qconsym by qop, and have both examples parse in the same way. However, unlike the other change in lexeme's definition, I don't suggest this, I

Re: The dreaded layout rule

1999-08-03 Thread Guy Lapalme
As an author of an Haskell Emacs mode that deals with the layout rule (described in Journal of Functional Programming 8(5) 493-502), I strongly agree that the "parse-error condition" is really a bad idea. For example, in Emacs, no full Haskell parse is done. After all, lay

RE: The dreaded layout rule

1999-08-01 Thread Manuel M. T. Chakravarty
to automatically insert the final '}' before the end of file. Perhaps the layout rule should be restricted to these two cases? Proposal: - replace t by 'in' in the parse-error rule. EOF is already handled by the last clause in the layout spec. My guess is that this would break very

RE: The dreaded layout rule

1999-07-31 Thread Simon Marlow
Does it mean that the following expressions would be illegal? if cond then do proc1; proc2 else do proc3; proc4 (case e of Just x - x 0; Nothing - False) Unfortunately, yes. Now one can forget about {} and use layout everywhere. He would no longer be able to forget or he would have to

Re: The dreaded layout rule

1999-07-30 Thread Wolfram Kahl
Simon Peyton-Jones [EMAIL PROTECTED] writes: In other words, it is a bug (and GHC and Hugs don't do it right - see my previous message; from your comment, I presume HBC also doesn't follow the definition). I think, the only Right Thing is to remove this awful rule (unless

RE: The dreaded layout rule

1999-07-30 Thread Simon Peyton-Jones
In other words, it is a bug (and GHC and Hugs don't do it right - see my previous message; from your comment, I presume HBC also doesn't follow the definition). I think, the only Right Thing is to remove this awful rule (unless somebody comes up with a rule that can be decided locally).

Re: The dreaded layout rule

1999-07-30 Thread Malcolm Wallace
| How about the Carl Witty's | | do a == b == c | | does NHC handle this correctly? It matches ghc and Hugs, reporting Error when renaming: Infix operator at 2:21 is non-associative. Note that this is reported one stage *after* parsing. Because parsing of infix operators is

Re: The dreaded layout rule

1999-07-30 Thread Lennart Augustsson
Malcolm Wallace wrote: Because parsing of infix operators is difficult, all implementations (to my knowledge) leave resolution of fixity and associativity until later. Indeed, the Haskell 98 standard recognises this (in an oblique way) by permitting infix decls to appear *after* the first

RE: The dreaded layout rule

1999-07-30 Thread Simon Marlow
the layout rule should be restricted to these two cases? Proposal: - replace t by 'in' in the parse-error rule. EOF is already handled by the last clause in the layout spec. My guess is that this would break very few programs. A simpler rule might involve automatically inserting

Re: The dreaded layout rule

1999-07-30 Thread Marcin 'Qrczak' Kowalczyk
Fri, 30 Jul 1999 05:12:51 -0700, Simon Marlow [EMAIL PROTECTED] pisze: The main reason for its inclusion was to allow things like let f x = x in ... and also to automatically insert the final '}' before the end of file. Perhaps the layout rule should be restricted to these two

RE: The dreaded layout rule

1999-07-30 Thread Manuel M. T. Chakravarty
Malcolm Wallace [EMAIL PROTECTED] wrote, [...] Simon Marlow replies: GHC and Hugs both make use of yacc-style error recovery, albeit in a very limited form. And nhc uses parser combinators, which give you backtracking on error conditions for free. We actually do almost all layout

RE: The dreaded layout rule

1999-07-29 Thread Simon Marlow
Manuel Chakravarty writes: What kind of implementation did the originators of this clause envision? If the layout rule is really implemented as a filter between the scanner and the parser, it seems extremely awkward to add a dependency on the error condition of the parser - in particular

The dreaded layout rule

1999-07-29 Thread Manuel M. T. Chakravarty
One of our students just pointed out an IMHO rather problematic clause in the layout rule. In Section 2.7 of the Haskell 98 Report it says, A close brace is also inserted whenever the syntactic category containing the layout list ends; that is, if an illegal lexeme is encountered

Re: The dreaded layout rule

1999-07-29 Thread Ian Holyer
This is a multi-part message in MIME format. --F93F7E72348E2F23CC7D1D40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manuel says One of our students just pointed out an IMHO rather problematic clause in the layout rule ... So, I guess (I hope

RE: The dreaded layout rule

1999-07-29 Thread Malcolm Wallace
Manuel Chakravarty writes: What kind of implementation did the originators of this clause envision? If the layout rule is really implemented as a filter between the scanner and the parser, it seems extremely awkward to add a dependency on the error condition of the parser - in particular

Re: The dreaded layout rule

1999-07-29 Thread Mike Thyer
If the scanning stage pairs the tokens it returns with their positions, then scanning can be done once before parsing begins. I've done this with a parser implemented with parser combinators, these combinators then decide whether or not to accept a token based on which token it is and how far it

Layout rule confusion

1998-07-31 Thread Sven Panne
Is the following fragment legal Haskell? Section B.3 of the report is not clear enough in this respect (at least for me :-} foo x = do case x of _ - return '?' If it *is* legal, GHC is wrong and Hugs is correct, otherwise GHC is right and Hugs is too liberal and its library contains

small wart in the Report's description of the layout rule

1997-11-07 Thread Carl R. Witty
The Haskell Report says: To facilitate the use of layout at the top level of a module (an implementation may allow several modules may reside in one file), the keyword module and the end-of-file token are assumed to occur in column 0 (whereas normally the first column is 1). Otherwise, all