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
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
Quoting wagne...@seas.upenn.edu:
Well, for what it's worth, my vote goes for a multi-argument \case. I
Just saw a proposal for \of on the reddit post about this. That's even
better, since:
1. it doesn't change the list of block heralds
2. it doesn't mention case, and therefore multi-arg
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 the wiki
page[1], take a look at the
I really like the \of proposal!
It is a clean elision with \x - case x of becoming \of
I still don't like it directly for multiple arguments.
One possible approach to multiple arguments is what we use for multi-argument
case/alt here in our little haskell-like language, Ermine, here at SP
On 2012-07-05 23:04, Edward Kmett wrote:
A similar generalization can be applied to the expression between case and of
to permit a , separated list of expressions so this becomes applicable to the
usual case construct. A naked unparenthesized , is illegal there currently as
well. That would
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 understand the issues well enough with the
On 07/06/2012 04:33 AM, Twan van Laarhoven wrote:
On 2012-07-05 23:04, Edward Kmett wrote:
A similar generalization can be applied to the expression between case
and of
to permit a , separated list of expressions so this becomes applicable
to the
usual case construct. A naked unparenthesized ,
71 matches
Mail list logo
