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
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
[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
[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
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
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
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
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
, 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
- { 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
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
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,
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
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
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
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
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
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,
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
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
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
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.
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.
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
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 {- = -}
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
... 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
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
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
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
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
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
- 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
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
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
[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
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
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,
[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
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]
At 2002-05-30 16:51, [EMAIL PROTECTED] wrote:
-Wmissing-protons
Compiles BASIC?
--
Ashley Yakeley, Seattle WA
, predominantly due to the layout rule :-(
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
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
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
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
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
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
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
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
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).
| 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
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
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
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
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
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
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
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
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
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
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
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
77 matches
Mail list logo