tl;dr. Please a take a minute to express your thoughts on
GHC's development priorities via this survey [1].
Hello everyone,
The GHC developers want to ensure that we are working on problems that
of most importance to you, the Haskell community. To this end we are
surveying the community
Hey Sergey,
Sorry for the delay - thanks for all your changes! A few other people
have stepped up. But we still need more help of course. :)
I'm incorporating your changes into the main Git repository as we
speak, and I greatly appreciate it! I'm also incorporating changes
from others. Please
Hello *,
For a while now, I've been wanting to do a facelift on the GHC
homepage, but among many other things it's been a low priority. I'd
like for people to help, so I've tried to get the ball rolling.
The webpages existed in a Darcs repository previously (which wasn't
available online
You can specify the pre-processor in the `ghc-options' field in the
cabal file, e.g.
ghc-options: -pgmPcpphs
Francesco
On 23 December 2014 at 17:14, Brandon Allbery allber...@gmail.com wrote:
On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz domi...@steinitz.org
wrote:
How very clever
I forgot to mention that `cpphs' can mimick gcc's cpp, with the flag
`-cpp'. In Agda we have
ghc-options: -pgmPcpphs -optP--cpp
Francesco
On 24 December 2014 at 10:50, Francesco Mazzoli f...@mazzo.li wrote:
You can specify the pre-processor in the `ghc-options' field in the
cabal file,
Thank you very much everyone. I now have a version of yarr which compiles under
ghc 7.8.3. I have yet to do the conditional compilation hackery to support back
versions but then I can make a release.
What a great community :-)
Dominic Steinitz
domi...@steinitz.org
Ok I have a cut down version of the problem and am cross posting to
glasgow-haskell-users.
To restate the problem: this is from code that has not been changed for 2
years. I get
Examples.hs:42:42: Parse error in pattern: con
Failed, modules loaded: none.
Any help would be very gratefully
years. I get
Examples.hs:42:42: Parse error in pattern: con
Failed, modules loaded: none.
Any help would be very gratefully received.
{-# LANGUAGE TypeFamilies, MultiParamTypeClasses,
FunctionalDependencies #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE
On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz domi...@steinitz.org
wrote:
To restate the problem: this is from code that has not been changed for 2
years. I get
Examples.hs:42:42: Parse error in pattern: con
Failed, modules loaded: none.
I think I see the problem. Are you by any
How very clever of you and thank you very much. Changing ‘ to 1 does fix the
problem.
I would have thought this would work
cabal install --with-gcc=gcc-4.9
But sadly I still got the same error.
Do I need a special version of cpphs?
Dominic Steinitz
domi...@steinitz.org
in pattern: con
Failed, modules loaded: none.
Any help would be very gratefully received.
{-# LANGUAGE TypeFamilies, MultiParamTypeClasses,
FunctionalDependencies #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE EmptyDataDecls #-}
{-# LANGUAGE
On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz domi...@steinitz.org
wrote:
How very clever of you and thank you very much. Changing ‘ to 1 does fix
the problem.
I would have thought this would work
cabal install --with-gcc=gcc-4.9
But sadly I still got the same error.
I think that
about the nominal/representational distinction.
Simon
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Conal Elliott
Sent: 24 April 2014 01:29
To: glasgow-haskell-users@haskell.org; ghc-d...@haskell.org; Richard Eisenberg;
Simon Peyton Jones
Subject: Help
...@haskell.org] *On Behalf Of *Conal Elliott
*Sent:* 24 April 2014 01:29
*To:* glasgow-haskell-users@haskell.org; ghc-d...@haskell.org; Richard
Eisenberg; Simon Peyton Jones
*Subject:* Help with cast error
I'd appreciate help with a cast-related Core Lint error I'm getting with a
GHC plugin I'm
I'd appreciate help with a cast-related Core Lint error I'm getting with a
GHC plugin I'm working on:
Argument value doesn't match argument type:
Fun type:
Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) =
EP (Enc (Vec ('S 'Z) Bool)) - EP (Bool, ())
Arg type:
~R# (Enc (Vec
April 2014 06:00
To: ghc-d...@haskell.org; glasgow-haskell-users@haskell.org
Subject: Help with coercion roles?
I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and
running into trouble with coercions roles. Error message from Core Lint:
Warning: In the expression
(Simple.NTCo:HasIf[0] GHC.Types.Bool_R)))_R
This is one of the problems with roles -- they are *very* fiddly within GHC,
and it's hard for a non-expert in roles to get them right.
Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and
may be of help.
Let me know if I can
(Sym (Simple.NTCo:HasIf[0] GHC.Types.Bool_R)))_R
This is one of the problems with roles -- they are *very* fiddly within
GHC, and it's hard for a non-expert in roles to get them right.
Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles
and may be of help.
Let me know
] GHC.Types.Bool_R)))_R
This is one of the problems with roles -- they are *very* fiddly within GHC,
and it's hard for a non-expert in roles to get them right.
Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and
may be of help.
Let me know if I can help further
of the problems with roles -- they are *very* fiddly within
GHC, and it's hard for a non-expert in roles to get them right.
Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles
and may be of help.
Let me know if I can help further!
Richard
On Apr 14, 2014, at 5:45 AM, Simon
the ability of
GHC's type system.
Of course, I would like to help you with a way forward -- let me know if
there's a way I can.
Richard
On Apr 14, 2014, at 4:12 PM, Conal Elliott co...@conal.net wrote:
Hi Richard,
I'm working on compiling Haskell to hardware, as outlined at
https://github.com
, I would like to help you with a way forward -- let me know if
there's a way I can.
Richard
On Apr 14, 2014, at 4:12 PM, Conal Elliott co...@conal.net wrote:
Hi Richard,
I'm working on compiling Haskell to hardware, as outlined at
https://github.com/conal/lambda-ccc/blob/master/doc
I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and
running into trouble with coercions roles. Error message from Core Lint:
Warning: In the expression:
LambdaCCC.Lambda.lamvP#
@ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool)
@ (Simple.HasIf
Hello all!
I'm extremely happy to report (thanks to invaluable help from Stephen) that
my issues were my own dumb fault : ) — I was using LLVM 3.0's Clang but not
its llc or opt. With some other tweaks to Stephen's above patch[1], we now
have a perfectly working GHC-iOS on OS X 10.9 Mavericks
OK! So just to summarize:
Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap)
on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein
layout-based code along with mixed-tabs-and-spaces code fails to parse
correctly, with issues in hundreds of files in the GHC HEAD
And the truly final word for the moment : ) —
I built a tool to partially automate the indentation workaround for LLVM
3.0 and it yields the same co-processor offset out of range/unsupported
relocation on symbol LCPI65_0 errors LLVM 3.3/3.4 did when it finally gets
to
What if you build a copy of head with the native code gen. Then build the
cross compiler using head on head?
On Sunday, August 11, 2013, Luke Iannini wrote:
And the truly final word for the moment : ) —
I built a tool to partially automate the indentation workaround for LLVM
3.0 and it yields
Hi all,
I tried this — building GHC HEAD configured to use the native code gen, and
then building the cross compiler using that, and got the same errors as
everything else thus far:
https://gist.github.com/lukexi/02366ed57171400b961a
10.9 Mavericks is likely coming out in less than a month,
Further investigation:
I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the
problem still occurred.
The problem only occurs with LLVM 3.0.
It is not related to cross-compilation or Stephen's patches: I tested this
on multiple fresh clones with --with-gcc=clang.
LLVM 3.2,
Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do
not.
On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini lukex...@gmail.com wrote:
Further investigation:
I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the
problem still occurred.
The problem
The Travis folks have decided they want to support Haskell better (multiple
compiler versions):
https://github.com/travis-ci/travis-ci/issues/882#issuecomment-20165378
(Yay!) They're asking for someone to help them up with setup scripts.
They mention their cookbook collection here:
https
Erratum; Of course, I meant that I had expected the different
occurrences of 'x' to have the same uniques. Similarly, the different
occurrences of 'y'. I did *not* expect 'x' and 'y' to have the same
uniques.
Ph.
On Wed, 2013-03-06 at 10:18 +0100, Philip K.F. Hölzenspies wrote:
Dear GHC-ers,
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Philip K.F. Hölzenspies
| Sent: 06 March 2013 10:29
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Need help interpreting renamer trace output
|
| Erratum; Of course, I meant that I had expected the different
I want to vote, too.
I am ok with all of
case of
\case
\of
\case of
For me single arguments are enough. We already have this restriction for 'case'
and I can work around it simply by wrapping arguments in pairs temporarily (cf.
curry $ \case ...).
I vote against LambdaIf, since
Am Freitag, den 13.07.2012, 13:40 +0100 schrieb Ross Paterson:
Remember that there is a \ in arrow notation in addition to proc.
So one might expect any abbreviation for \x - case x of {...}
to mean the same \ thing in arrow notation too.
I completely agree. I had forgotten about the \ in
Am Montag, den 16.07.2012, 21:26 +0300 schrieb Wolfgang Jeltsch:
Am Freitag, den 13.07.2012, 13:40 +0100 schrieb Ross Paterson:
Remember that there is a \ in arrow notation in addition to proc.
So one might expect any abbreviation for \x - case x of {...}
to mean the same \ thing in arrow
Good news everyone. LambdaCase and MultiWayIf are now in HEAD. Thanks
for participating in the final push!
On Thu, Jul 5, 2012 at 9:42 PM, Mikhail Vorozhtsov
mikhail.vorozht...@gmail.com wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being
On Thu, Jul 12, 2012 at 03:13:42PM -0400, Cale Gibbard wrote:
There are of course already lots of ways to create functions which
don't involve \
Well, I think it should be clear that we're talking here about
anonymous functions.
We're not exactly talking about function definitions, so much
Mikhail Vorozhtsov mikhail.vorozht...@gmail.com writes:
Hi.
After 21 months of occasional arguing the lambda-case
proposal(s) is in danger of being buried under its own trac
ticket comments. We need fresh blood to finally reach an
agreement on the syntax. Read the wiki page[1], take a look
On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the
Am Donnerstag, den 12.07.2012, 13:38 -0400 schrieb Cale Gibbard:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and
On Fri, Jul 13, 2012 at 01:21:25PM +0100, Wolfgang Jeltsch wrote:
I’m strongly opposed to the
case of { ... }
syntax, because there seems to be no natural arrow expression analog of
it.
A notation that starts with \ (like “\case”) can be carried over to
arrow expressions by
Quoth Cale Gibbard:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
...
Does anyone else agree?
Yes. I don't see this as an `anonymous function' in any special sense,
Am Freitag, den 13.07.2012, 06:57 -0700 schrieb Donn Cave:
Quoth Cale Gibbard:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
...
Does anyone else agree?
Yes.
On Thu, Jul 12, 2012 at 7:38 PM, Cale Gibbard cgibb...@gmail.com wrote:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
On Fri, Jul 13, 2012 at 9:12 PM, Gábor Lehel illiss...@gmail.com wrote:
On Thu, Jul 12, 2012 at 7:38 PM, Cale Gibbard cgibb...@gmail.com wrote:
case of { ... }
looks much better to me than
\case of { ... }
I also completely agree, but I don't want my opinion to get in the way
of
On 07/12/2012 04:27 AM, Iavor Diatchki wrote:
Hello,
I am late to the discussion and this is not entirely on topic, for which
I apologize, but I like the multi-branch case syntax someone mentioned
earlier:
Writing:
case
| p1 - e1
| p2 - e2
| ...
desugars to:
case () of
_
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as a simple extension of operator
sections to
On Thu, Jul 12, 2012 at 01:38:56PM -0400, Cale Gibbard wrote:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
I don't think that the 'case section syntax' is obvious, because I don't
see the
There are of course already lots of ways to create functions which
don't involve \
I mentioned sections (like (+1) desugaring to (\x - x + 1)) already,
and of course, one can partially apply or compose and transform other
functions without explicit lambdas.
We're not exactly talking about
Hello wagnerdm,
Thursday, July 5, 2012, 7:22:38 PM, you wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is
this reminded me old joke about PL/I: camel is the horse created by committee
i propose to return back and summarize all the requirements we have in
this area.
On 2012-07-12 23:48, Bulat Ziganshin wrote:
another interesting feature may be ruby-style matching defined by
execution of special function `match` instead of pattern matching:
switch var of
1+1 - print var==2
[5..10] - print var in [5..10]
(20) - print var20
where (var `match`
On 13/07/2012 3:08 AM, Cale Gibbard wrote:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as
Hello,
I am late to the discussion and this is not entirely on topic, for which I
apologize, but I like the multi-branch case syntax someone mentioned
earlier:
Writing:
case
| p1 - e1
| p2 - e2
| ...
desugars to:
case () of
_ | p1 - e2
| p2 - e2
| ...
-Iavor
PS: I
On 07/10/2012 01:09 AM, Bardur Arantsson wrote:
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The
pressing
need is really for a
| I strongly favor a solution where lambda-case expressions start with \,
| because this can be generalized to proc expressions from arrow syntax
| simply by replacing the \ with proc.
|
| Take, for example, the following function definition:
|
| f (Left x) = g x
| f (Right y) = h y
|
On 07/10/2012 01:53 PM, Simon Peyton-Jones wrote:
| I strongly favor a solution where lambda-case expressions start with \,
| because this can be generalized to proc expressions from arrow syntax
| simply by replacing the \ with proc.
|
| Take, for example, the following function definition:
|
|
I think it's very helpful if lambdas start with a lambda, which to
me suggests \case.
I'd be interested to hear that explained a little further. To me it isn't
obvious that `case of' is `a lambda', but it's obvious enough what it is
and how it works (or would work) - it's `case' with type a -
On 09/07/2012 17:32, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:49 PM, Simon Marlow wrote:
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
and respectively
\case
P1, P2 - ...
P3, P4 - ...
as sugar for
\x y - case x, y of
P1, P2 - ...
P3, P4 - ...
That looks a bit strange to me,
On 10/07/2012 07:33, Mikhail Vorozhtsov wrote:
On 07/10/2012 01:09 AM, Bardur Arantsson wrote:
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout
Am Dienstag, den 10.07.2012, 08:53 +0100 schrieb Simon Marlow:
On 09/07/2012 17:32, Mikhail Vorozhtsov wrote:
Would you still expect tuples for \case if you didn't see the way
`case x, y of ...` was implemented (or thought that it is a
primitive construct)?
Yes, I still think it's
Am Dienstag, den 10.07.2012, 06:53 + schrieb Simon Peyton-Jones:
I strongly favor a solution where lambda-case expressions start with \,
because this can be generalized to proc expressions from arrow syntax
simply by replacing the \ with proc.
[…]
I think it's very helpful if
On Tue, Jul 10, 2012 at 5:53 AM, Wolfgang Jeltsch
g9ks1...@acme.softbase.org wrote:
If we use \case for functions, we should use proc case for arrows;
if we use \of for functions, we should use proc of for arrows.
By the way, is proc a layout herald already?
No, proc is not a layout herald.
On 07/07/2012 05:08, Tyson Whitehead wrote:
PS: To be fully precise, the modified layout decoder in 9.3 would be
L (n:ts) i (m:ms) = ; : (L ts n (m:ms)) if m = n
= } : (L (n:ts) n ms) if n m
L (n:ts) i ms = L ts n ms
L ({n}:n:ts) i ms = {
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård jonas.dureg...@chalmers.se wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument
versions):
1: Omission: case of. There seems to be some support
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård jonas.dureg...@chalmers.se
wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård jonas.dureg...@chalmers.se
wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The pressing
need is really for a combination of '\' and 'case', that is single-argument so
that we don't have to write parentheses. I think '\case' does the job
perfectly. If you want a
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The
pressing
need is really for a combination of '\' and 'case', that is
single-argument so
that we don't have to write parentheses. I think
Am Samstag, den 07.07.2012, 00:08 -0400 schrieb Tyson Whitehead:
I've thought some more about this and it seems to me that there are
two ways people might intuitively think about doing grouping via
indentation.
1 - the first item is on the same line and subsequent ones are lined
up with
Right, it seems to me that there are basically three reasonable proposals here:
1. \ of with multiple arguments. This is consistent with existing
layout, and seems like a nice generalization of lambda syntax.
2. case of with a single argument. This is consistent with existing
layout, and seems
Am Montag, den 09.07.2012, 21:04 +0700 schrieb Mikhail Vorozhtsov:
Could you express your opinion on the case comma sugar, i.e.
case x, y of
P1, P2 - ...
P3, P4 - ...
as sugar for
case (# x, y #) of
(# P1, P2 #) - ...
(# P3, P4 #) - ...
and respectively
\case
On 07/09/2012 09:49 PM, Simon Marlow wrote:
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård jonas.dureg...@chalmers.se
wrote:
Couldn't we use \\ for multi-case
Am Montag, den 09.07.2012, 10:20 -0600 schrieb Chris Smith:
Right, it seems to me that there are basically three reasonable proposals
here:
1. \ of with multiple arguments. This is consistent with existing
layout, and seems like a nice generalization of lambda syntax.
2. case of with a
On 07/09/2012 11:22 PM, Wolfgang Jeltsch wrote:
Am Montag, den 09.07.2012, 21:04 +0700 schrieb Mikhail Vorozhtsov:
Could you express your opinion on the case comma sugar, i.e.
case x, y of
P1, P2 - ...
P3, P4 - ...
as sugar for
case (# x, y #) of
(# P1, P2 #) - ...
(# P3, P4
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The
pressing
need is really for a combination of '\' and 'case', that is
single-argument
On Mon, Jul 09, 2012 at 07:22:30PM +0300, Wolfgang Jeltsch wrote:
Although I wasn’t asked, I want to express my opinion. I think, the use
of the comma is strange. When declaring functions with multiple
arguments, we don’t have commas:
f Nothing y = y
f (Just x) y = x
In lambda
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument versions):
1: Omission: case of. There seems to be some support for this but it
was not included in the summary.
2: Omission with clarification: \case of
3: \of - but I think
Quoting Jonas Almström Duregård jonas.dureg...@chalmers.se:
Couldn't we use \\ for multi-case lambdas with layout?
Actually, \\ is a valid (infix) function name... and the base library
includes one in Data.List. That name is copied in several other
container interfaces, as well.
~d
On 07/07/2012, Jonas Almström Duregård jonas.dureg...@chalmers.se wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument
versions):
1: Omission: case of. There seems to be some support for this but it
was not included
On July 7, 2012 00:08:26 Tyson Whitehead wrote:
The very limited scope of this (i.e., it would only apply to lines that end
with a grouping construct where the next line is indented further than that
line) should also address Simon's concerns regarding things like
f x y = x + y
If we're voting
I think \of is all right, and multi-argument case could be handy,
which rules out using 'case of' for lambda case, because it's the
syntax for a 0-argument case:
case of
| guard1 - ...
| guard2 - ...
Then multi-argument lambda case could use the comma syntax
On 07/06/2012 05:47 AM, Donn Cave wrote:
The `multi-clause lambda' seems more elegant, if the syntactical
problems could be worked out. I mean, unnamed functions are thus
just like named functions, something that you'd probably think to
try just as soon as you needed the feature.
I don't
On 07/05/2012 10:22 PM, wagne...@seas.upenn.edu wrote:
Quoting Mikhail Vorozhtsov mikhail.vorozht...@gmail.com:
After 21 months of occasional arguing the lambda-case proposal(s) is
in danger of being buried under its own trac ticket comments. We need
fresh blood to finally reach an agreement
Oh, neat. I guess it does. :) I'll hack that into my grammar when I get into
work tomorrow.
My main point with that observation is it cleanly allows for multiple argument
\of without breaking the intuition you get from how of already works/looks or
requiring you to refactor subsequent lines,
On 07/06/2012 02:31 AM, Tyson Whitehead wrote:
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax.
On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the
Twan,
The 0-ary version you proposed actually works even nicer with \of.
foo'' = case () of
() | quux - ...
| quaffle - ...
| otherwise - ...
Starting from the above legal haskell multi-way if, we can, switch to
foo' = case of
| quux - ...
| quaffle - ...
| otherwise - ...
Christopher Done chrisd...@gmail.com writes:
P.S. \if then … else …?
btw, http://www.haskell.org/haskellwiki/If-then-else
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
On 05/07/2012 20:31, Tyson Whitehead wrote:
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read
On July 6, 2012 05:25:15 Simon Marlow wrote:
Why not just let enclosed scopes be less indented than their outer ones?
Let me be entirely clear about what I was thinking about. The third case for
the layout mapping in Section 9.3 of the report is
L ({n}:ts) (m:ms) = { : (L ts
On 05/07/2012, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1],
Whoops, my earlier answer forgot to copy mailing lists... I would love to
see \of, but I really don't think this is important enough to make case
sometimes introduce layout and other times not. If it's going to obfuscate
the lexical syntax like that, I'd rather just stick with \x-case x of.
On
On July 6, 2012 11:49:23 Tyson Whitehead wrote:
Currently it depends on the depth of this new level of indentation relative
to all the groupings started on that line. I think most people would
expect it to just apply to the last grouping though. That is
where { f x = do {
stmt1
stmt2
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the ticket[2], vote and comment on the proposals!
Quoting Mikhail Vorozhtsov mikhail.vorozht...@gmail.com:
After 21 months of occasional arguing the lambda-case proposal(s) is
in danger of being buried under its own trac ticket comments. We
need fresh blood to finally reach an agreement on the syntax. Read
the wiki page[1], take a look at
I like \case as is proposed. It seems the least controversial one and
there's curry (\case ) for two-args, but even that seems a rare case.
For what it's worth, I like the idea of omission being partiality, as
in case of and if then. It seems perfectly natural to me, I don't need
a \ to tell me
On Thu, Jul 5, 2012 at 12:21 PM, Christopher Done chrisd...@gmail.com wrote:
I like \case as is proposed. It seems the least controversial one and
there's curry (\case ) for two-args, but even that seems a rare case.
For what it's worth, I like the idea of omission being partiality, as
in
On 05/07/12 17:22, wagne...@seas.upenn.edu wrote:
Well, for what it's worth, my vote goes for a multi-argument \case. I find the
comment on the wiki page about mistyping \case Just x instead of \case (Just
x) a lot a bit disingenuous, since you already need these parens with today's
lambda.
On Thu, Jul 5, 2012 at 5:21 PM, Christopher Done chrisd...@gmail.com wrote:
I like \case as is proposed. It seems the least controversial one and
there's curry (\case ) for two-args, but even that seems a rare case.
For what it's worth, I like the idea of omission being partiality, as
in case
1 - 100 of 261 matches
Mail list logo
