On 2019-04-29 3:54 a.m., 佐藤玄基 wrote:
Hello,
I found that the layout interpretation algorithm in Section 10.3 of
Report 2010
produces parse-error when applied to the following code snippet:
[Snippet 1 : The code that fails to be parsed by Report]
main = print t where { t = s where s = 1
Hello,
I found that the layout interpretation algorithm in Section 10.3 of Report
2010
produces parse-error when applied to the following code snippet:
[Snippet 1 : The code that fails to be parsed by Report]
main = print t where { t = s where s = 1 :: Int }
[/Snippet 1]
GHC 8.4.4 and GHC 8.6.4
Hi,
the layout language options are hard to find (at least in the user
guide). Therefore I try to give an overview here. The relevant options
I've found by using ghc-7.10.3 with option --supported-languages are:
NondecreasingIndentation
DoAndIfThenElse
RelaxedLayout
AlternativeLayoutRule
presence of {n} in the input to L).
However, if you accept this interpretation of nested context, then the second
sentence and example of Note 1 do not seem to make sense. That is, there does
not seem to be a case where the test for the layout error described in Note 1
would be met. Indeed
On 1 Apr 2013, at 01:21, Seth Lastname wrote:
Note 2 says, If the first token after a 'where' (say) is not indented more
than the enclosing layout context, then the block must be empty, so empty
braces are inserted.
It seems that, in Note 2, the first token necessarily refers to a lexeme
I'm sure I'm missing something, but I'm having difficulty parsing or
reconciling Note 1 and Note 2 of Section 10.3 (Layout) of the Haskell 2010
Language Report.
http://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3
Can somebody point me in the right direction
It seems my suggestion isn't getting too much traction.
It occurs to me this may be because I jumped right into layout rules and
didn't first give some simple motivating examples to get the idea across.
SHORT VERSION:
Assume '\' is a grouping construct. I proposed always interpreting
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
#5923: closure_flags[] contains wrong _BTM data (whether the layout is bitmap
or
pointer first)
-+--
Reporter: nomeata | Owner:
Type: bug | Status: new
#5923: closure_flags[] contains wrong _BTM data (whether the layout is bitmap
or
pointer first)
-+--
Reporter: nomeata | Owner:
Type: bug | Status: new
#5923: closure_flags[] contains wrong _BTM data (whether the layout is bitmap
or
pointer first)
---+
Reporter: nomeata | Owner:
Type: bug | Status: closed
#5923: closure_flags[] contains wrong _BTM data (whether the layout is bitmap
or
pointer first)
--+-
Reporter: nomeata | Owner:
Type: bug | Status: new
#5923: closure_flags[] contains wrong _BTM data (whether the layout is bitmap
or
pointer first)
--+-
Reporter: nomeata | Owner:
Type: bug | Status: new
#3984: Handle multiline input in GHCi history
---+
Reporter: aavogt| Owner:
Type: feature request | Status: new
Priority: normal|
#3645: Layout and pragmas
+---
Reporter: igloo | Owner:
Type: feature request| Status: new
Priority: normal | Milestone: 7.4.1
On 18:12 Sat 09 Jul , Tom Murphy wrote:
Hi,
I've found good explanations of the HaskellDB combinators, but I
can't find good information about how to correctly define the database
layout. Can anyone point me to a resource, or give a quick example?
Thanks!
Tom
Hello,
I wrote
On 18:12 Sat 09 Jul , Tom Murphy wrote:
Hi,
I've found good explanations of the HaskellDB combinators, but I
can't find good information about how to correctly define the database
layout. Can anyone point me to a resource, or give a quick example?
Thanks!
Tom
Hi,
I've found good explanations of the HaskellDB combinators, but I
can't find good information about how to correctly define the database
layout. Can anyone point me to a resource, or give a quick example?
Thanks!
Tom
___
Haskell-Cafe mailing
#3984: interpret layout in GHCi
--+-
Reporter: aavogt | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.2.1
On 25/05/11 10:00, Jonas Almström Duregård wrote:
As an equivalent to:
f (x a) (y b) (z c)
Of course my intention is that the new keyword should initiate layout
syntax so we can write this:
f applied to
x a
y b
z c
Here's a (tongue-in-cheek) trick that allows for layout close
On Thursday 26 May 2011 14:35:41, Neil Brown wrote:
foo is the function we want to apply, and eg shows how to apply it in
do-notation with an argument on each line. I couldn't manage to remove
the r$ at the beginning of each line, which rather ruins the whole
scheme :-( On the plus side,
That's a useful operator! Unfortunately it does not play nice with $. Of
less importance: some syntactic constructs can not appear in the arguments
without parenthesis, let bindings for instance (although lambda abstraction
works parenthesis-free).
Also I'm not sure this can be used for defining
On Thursday 26 May 2011 17:22:10, Jonas Almström Duregård wrote:
Unfortunately it does not play nice with $.
Yes.
Also I'm not sure this can be used for defining trees or nested function
application since a nesting of the operator inevitably require
parenthesis.
It can't be nested, like ($)
2011/5/26 Daniel Fischer daniel.is.fisc...@googlemail.com
As far as I'm concerned, a left-associative version of ($) would sometimes
be nice (on the other hand, right-associativity of ($) is sometimes also
nice), but usually, I don't find parentheses too obnoxious.
I have a whole set of
Hi,
Would it be possible to allow this in Haskell (where applied to is some
new operator or keyword):
f applied to {x a;y b;z c}
As an equivalent to:
f (x a) (y b) (z c)
Of course my intention is that the new keyword should initiate layout syntax
so we can write this:
f applied to
x a
y
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
Would it be possible to allow this in Haskell (where applied to is some
new operator or keyword):
f applied to {x a;y b;z c}
Sounds like idiom brackets to me.
___
Haskell-Cafe mailing
I don't see the similarity (from reading this:
http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is
just a way of using layout to avoid parenthesis.
/J
2011/5/25 Brandon Allbery allber...@gmail.com:
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
Would
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
I don't see the similarity (from reading this:
http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is
just a way of using layout to avoid parenthesis.
This is exactly the applicative style, where idiom brackets come
Hi Alexander,
This is exactly the applicative style, where idiom brackets come from.
I disagree. Layout has at least two advantages over applicative here:
1) Applicative costs (at least) three additional characters per function
parameter.
2) You can not have arbitrary infix operators
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
Hi Alexander,
This is exactly the applicative style, where idiom brackets come from.
I disagree. Layout has at least two advantages over applicative here:
1) Applicative costs (at least) three additional characters per function
#3645: Layout and pragmas
+---
Reporter: igloo | Owner:
Type: feature request| Status: new
Priority: normal | Milestone: 7.2.1
., a HAppStack plugin that makes writing web apps in Haskell
just as easy as it is for the Java community to write web services.
I've just added Haskell code templates (*) to EclipseFP and, in the process,
encountered the distinct lack of layout autoindentation. I'm sure it used to
exist, but it doesn't
the distinct lack of layout autoindentation. I'm sure it used to
exist, but it doesn't exist today. I've looked at the Emacs haskell-mode.el
indentation style, which I'm inclined to port over.
Are there other layout autoindentation styles that other people prefer and
believe should be supported
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: feature request| Status: patch
Priority: normal |Milestone: 7.0.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: feature request| Status: patch
Priority: normal |Milestone: 7.0.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: feature request| Status: patch
Priority: normal |Milestone: 7.0.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: feature request| Status: patch
Priority: normal |Milestone: 7.0.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: feature request| Status: patch
Priority: normal |Milestone: 7.0.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: feature request| Status: new
Priority: normal |Milestone: 7.0.1
#1060: GHC accepts program with incorrect layout
+---
Reporter: igloo | Owner:
Type: bug| Status: closed
Priority: normal
#3984: interpret layout in GHCi
--+-
Reporter: aavogt | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.0.1
There's also an underlying semantic issue, which is not yet resolved.
The GHC implementation of mdo (following Levent and John's paper)
performs a dependency analysis on the statements in the mdo to apply
mfix to the shortest possible subsegments of statements. For example,
mdo
a - f b
- g b }
putChar c
return b
it does spoil the nice layout - it would be nice to just be able to
write (which does not parse)
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care that the only recursive statements are #2,#3 -
I just want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/21/10 13:18 , John Lask wrote:
it does spoil the nice layout - it would be nice to just be able to write
(which does not parse)
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care
I think this would just require the lex layout rules already in place for
do/let in GHC; my guess is that your example would work if the body were
indented past the r of rec.
for the record ...
t2 =
do rec
a - getChar
b - f c
c - g b
putChar c
return b
- g b }
putChar c
return b
it does spoil the nice layout - it would be nice to just be able to
write (which does not parse)
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care that the only recursive statements are #2,#3 -
I just want
On 22 June 2010 03:18, John Lask jvl...@hotmail.com wrote:
I just want my nice neat layout back. I have just spent an inordinate amount
of time updating code when if the parser recognised do rec as a recursive
group it would have been a drop in replacement and taken me one tenth of the
time
On Jun 21, 2010, at 10:18 AM, John Lask wrote:
do rec
a - getChar
b - f c
c - g b
putChar c
return b
I don't particularly care that the only recursive statements are
#2,#3 - I just want my nice neat layout back. I have just spent an
inordinate amount of time updating code
On Jun 20, 2010, at 6:24 PM, Alexander Solla wrote:
do a - getChar
let b = c = return . f
let c = b = return . g
c = putChar
b
Correction: by your construction, f and g are already in the Kliesli
category, so you don't need the return compositions. I still
On Sunday 20 June 2010 9:24:54 pm Alexander Solla wrote:
Why can't you just use let notation do deal with the recursion? I
thought lets in do blocks were just a little bit of syntactic sugar
for regular let expressions, which do allow mutual recursion. I
could be totally wrong though. I'm
On 20/06/2010 6:32 PM, Alexander Solla wrote:
in your example c will not be in scope in the expression (let b = c =
return . f) - that's the purpose of the recursive do construct (mdo, now
do .. rec ..)
jvl
On Jun 20, 2010, at 6:24 PM, Alexander Solla wrote:
do a - getChar
let b = c =
#3984: interpret layout in GHCi
--+-
Reporter: aavogt | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 6.14.1
#3984: interpret layout in GHCi
--+-
Reporter: aavogt | Owner: igloo
Type: feature request | Status: closed
Priority: normal | Milestone: 6.14.1
#3984: interpret layout in GHCi
-+--
Reporter: aavogt|Owner: igloo
Type: feature request | Status: patch
Priority: normal|Milestone: 6.14.1
#3984: interpret layout in GHCi
-+--
Reporter: aavogt|Owner:
Type: feature request | Status: patch
Priority: normal|Milestone: 6.14.1
#3984: interpret layout in GHCi
-+--
Reporter: aavogt|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 6.14.1
#3984: interpret layout in GHCi
-+--
Reporter: aavogt|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 6.14.1
#3984: interpret layout in GHCi
-+--
Reporter: aavogt|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 6.14.1
#3984: interpret layout in GHCi
-+--
Reporter: aavogt| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
#3984: interpret layout in GHCi
-+--
Reporter: aavogt| Owner:
Type: feature request | Status: new
Priority: normal| Component: GHCi
#3645: Layout and pragmas
+---
Reporter: igloo | Owner:
Type: feature request| Status: new
Priority: normal | Milestone: 6.14.1
#3645: Layout and pragmas
+---
Reporter: igloo | Owner:
Type: bug| Status: new
Priority: normal | Milestone: 6.14.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: bug| Status: new
Priority: normal |Milestone: 6.14.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: bug| Status: new
Priority: normal |Milestone: 6.14.1
#3645: Layout and pragmas
--+-
Reporter: igloo |Owner:
Type: bug| Status: new
Priority: normal |Milestone: 6.14.1
)
Ideally, I'd want something even more light-weight, but I can't think of
anything backwards-compatible that satisfies the bracket-matching
requirement (which I also care about, as I don't particularly want to hack
my editor for this layout proposal either).
* For the magic uncurried-function
Hello Jimmy,
Wednesday, September 23, 2009, 11:11:58 AM, you wrote:
How about this (which I believe to be backwards compatible):
brilliant!
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
Haskell-Cafe
http://www.haskell.org/haskellwiki/Accessible_layout_proposal
I see two main problems with such a proposal (other than the particular
details of the syntax chosen for it):
- layout is not very well supported by most of the text editors,
contrary to parens/brackets/braces.
- more importantly
I am a bit puzzled here.
This seems to mean something like
If you take readable code using an operator you can
make it less readable, and when you do that you create
another problem as well, and an even less readable hack
can fix that.
I know an old lady who swallowed a fly...
where records were declared using
layout (but not sum-of-product types) not unlike this.
Here we have newline overloaded to mean or (Empty or
Fork) and and (key and value and left and right).
It could *work*, and it would be less typing for the
*author*, but what would it do for the *reader
I am in love with this proposal:
http://www.haskell.org/haskellwiki/Accessible_layout_proposal
However, after some Google searching and contacting its original author, I
have still not found any implementation or project to implement it. Are
there any I'm missing? And, if not, who would be
On Tue, Sep 22, 2009 at 10:01 AM, Jimmy Hartzell j...@shareyourgifts.net
wrote:
I am in love with this proposal:
http://www.haskell.org/haskellwiki/Accessible_layout_proposal
I'm not sure whether I like the idea in general or not. It looks a bit
odd. The suggestion on the talk page (
On Sep 22, 2009, at 8:01 PM, Jimmy Hartzell wrote:
I am in love with this proposal:
http://www.haskell.org/haskellwiki/Accessible_layout_proposal
I hadn't read it before. Now that I have, I really do not like
it. Syntactic sugar causes cancer of the semicolon as Alan
Perlis once said, and
. Meanwhile, you
have to format your code very awkwardly, as the closing bracket can't be
in the left-most column, and, all in all, you have lots and lots of commas
cluttering up your otherwise clean-looking layout.
You get humans reading the code based off of the physical layout, while
the computer
of my coding time finagling the layout to look
sensible, and I don't think anyone would claim that I just shouldn't use
records or ADTs.
I see your point but remain not liking the proposal.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
Daniel Fischer wrote:
Or, what I do:
concat
[ (
, str
, )
]
This is a lot better, true, but it still takes a lot of typing, and the
first element is now special-cased, preventing easy copy-and-paste
(although, admittedly, much less opportunity for mistake). On a more
hello)
because it looks very much as if enter and exit exist only
to be passed (with suitable parameters) to bracket_.
But I would *still* rather have:
with a = bracket_ $#
enter a
exit a
Layout is easier to read than parentheses.
It all depends on size (small things being easy pretty
it is hard, then improving the library to handle
layout extensions would be a nice side-effect even if the preprocessor
never became widely popular.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
layout
proposal. That's
not a lot.
first element is now special-cased, preventing easy copy-and-paste
Making it slightly harder. Copy-Paste-Cursor to beginning-delete-comma.
No big deal. Besides, how often does one need to copy the beginning of one list
into the
middle of another?
(although
Richard O'Keefe wrote:
After all, someone might have started with
(
( ++
str ++
)
)
and ended up with
(
( ++
str ++
) -- (oops, no ++!)
lineEnd -- forgot I needed this
)
I asked for the trailing
On Sep 23, 2009, at 3:04 PM, Evan Laforge wrote:
It would be so much better if we could discuss a _real_
example.
Or implement one.
I really did mean EXAMPLES. Examples of code which would
be improved *more* by the proposal than by adopting an
alternative style within the existing
On Sep 23, 2009, at 3:40 PM, James Hartzell wrote:
I asked for the trailing comma in Erlang for _social_ reasons,
not because I believed it would fix all problems of this type.
What do you mean, for social reasons?
The proposal is http://www.erlang.org/eeps/eep-0021.html
The abstract says
? Per line it's two keystrokes more than with the accessible layout
proposal. That's not a lot.
first element is now special-cased, preventing easy copy-and-paste
Making it slightly harder. Copy-Paste-Cursor to beginning-delete-comma.
No big deal. Besides, how often does one need to copy
Am Mittwoch 23 September 2009 04:06:11 schrieb Jimmy Hartzell:
Daniel Fischer wrote:
Or, what I do:
concat
[ (
, str
, )
]
You're right: my objections to this seem mostly to be matters of taste --
as I think about it, I find fewer and fewer practical reasons for
On Thu, 2009-03-19 at 11:50 +0100, Johannes Waldmann wrote:
Thanks. Now the 00-index.tar.gz works.
When studying the access log of my web server,
I found that the cabal client (cabal-install/0.6.0)
does not want $pkg/$ver/$pkg-$ver.tar.gz
but uses packages/$pkg-$ver/tarball instead
(yes,
On Wed, 2009-03-18 at 22:24 +0100, Johannes Waldmann wrote:
Hello.
I wonder what is the required layout of directories
and files on a server that supplies packages for cabal-install.
I figure 00-index.tar.gz contains the *.cabal files.
Right. The directory layout within the index
Thanks. Now the 00-index.tar.gz works.
When studying the access log of my web server,
I found that the cabal client (cabal-install/0.6.0)
does not want $pkg/$ver/$pkg-$ver.tar.gz
but uses packages/$pkg-$ver/tarball instead
(yes, packages and tarball are constant strings).
That's strange, since
Hello.
I wonder what is the required layout of directories
and files on a server that supplies packages for cabal-install.
I figure 00-index.tar.gz contains the *.cabal files.
(The cabal files have to be on the server as well, unpacked?)
Each $dir/$foo.cabal (in the archive) contains a Version
I think it'd be nice if we just replaced the if with a question mark :)
--
_jsn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
.
The question I imagine you're asking involves layout mode:
do
if n5 then
putStrLn big
else
putStrLn small
this is shorthand for
do { if n 5 then putStrLn big ; else putStrLn small }
which is a syntax error. A statement in a do block cannot begin with the
keyword else.
If you
Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
I think Hugs is violating the Haskell98 layout rules.
One could argue that GHC should, too.
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting
' is apparently going to include a hack to permit this case. I
think that's a poor decision, because including a hack to the layout
rule makes it harder to understand and explain the layout rule.
There's no need to hack the layout rule, you're even giving pointers to
the solution. Something like
Achim Schneider [EMAIL PROTECTED] wrote:
if i knew how to do it
Sorry, apparent mistake, besides confusing b (bool) with p (predicate):
if p _ c = do
(_, _, a) - get
put (p, c, a)
mzero
--
(c) this sig last receiving data processing entity. Inspect headers
for
On Wed, 24 Sep 2008, leledumbo wrote:
consider this partial program:
if n5 then
putStrLn big
else
putStrLn small
this works fine in hugs, but in ghc I must change it to:
if n5
then
putStrLn big
else
putStrLn small
maybe related
http://www.haskell.org/haskellwiki/If-then-else
consider this partial program:
if n5 then
putStrLn big
else
putStrLn small
this works fine in hugs, but in ghc I must change it to:
if n5
then
putStrLn big
else
putStrLn small
--
View this message in context:
http://www.nabble.com/if---then---else-layout-tp19663006p19663006
else
putStrLn small
Except in a do, the else must be indented beyond the start of the
if. I think Hugs is violating the Haskell98 layout rules.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL
layout rules.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon university
KF8NH
___
Haskell
Mon Apr 14 12:04:30 PDT 2008 Simon Marlow [EMAIL PROTECTED]
* add John Meacham's layout proposal
M ./status.hs +2
View patch online:
http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414190430-8214f-810333212d57fcd21f9e15177ea4ebe551c00bd9.gz
Hi,
I understand that many people like using
layout in their code, and 99% of all
Haskell examples use some kind of layout
rule. However, sometimes, I would like
not to use layout, so I can find errors
easier (and maybe convert it to layout for
presentation after all problems are solved).
So, I
1 - 100 of 271 matches
Mail list logo
