₀₁₂₃₄₅₆₇₈₉⁰¹²³⁴⁵⁶⁷⁸⁹₍₎⁽⁾₊₋]
John
On Sat, Jun 14, 2014 at 7:48 AM, Mikhail Vorozhtsov
wrote:
Hello lists,
As some of you may know, GHC's support for Unicode characters in lexemes is
rather crude and hence prone to inconsistencies in their handling versus the
ASCII counterparts. For example,
On 06/17/2014 03:13 AM, Tsuyoshi Ito wrote:
Hello,
Mikhail Vorozhtsov wrote:
I also worry (although not based on anything particular you said)
whether this will not change meaning of any existing programs. Does it
only allow new programs?
As far as I can see, no change in meaning. Some hacky
On 06/16/2014 04:26 AM, Mateusz Kowalczyk wrote:
On 06/14/2014 04:48 PM, Mikhail Vorozhtsov wrote:
Hello lists,
As some of you may know, GHC's support for Unicode characters in lexemes
is rather crude and hence prone to inconsistencies in their handling
versus the ASCII counterparts
Hello lists,
As some of you may know, GHC's support for Unicode characters in lexemes
is rather crude and hence prone to inconsistencies in their handling
versus the ASCII counterparts. For example, APOSTROPHE is treated
differently from PRIME:
λ> data a +' b = Plus a b
:3:9:
Unexpected
On 07/18/2012 07:25 PM, Simon Peyton-Jones wrote:
Folks
Mikhail has improved Template Haskell’s handling of INLINE pragmas,
SPECIALISE pragmas, and RULES. I plan to commit his patch:
http://hackage.haskell.org/trac/ghc/ticket/7064
Will the patch make it to 7.6? I have 6 unpublished libraries t
Hi Simon.
On Wed, Jul 18, 2012 at 7:25 PM, Simon Peyton-Jones
wrote:
> Mikhail has improved Template Haskell’s handling of INLINE pragmas,
> SPECIALISE pragmas, and RULES. I plan to commit his patch
BTW, is there a reason why you use commit messages to attribute other
people's work instead of `g
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
wrote:
>
> Hi.
>
> After 21 months of occasional arguing the lambda-case proposal(s) is in
> danger of being buried und
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
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
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:
|
|
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 re
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 #)
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
wrote:
Couldn't we use \\ for multi-case lambdas with layout?
I
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
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
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".
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
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 10:22 PM, wagne...@seas.upenn.edu wrote:
Quoting Mikhail Vorozhtsov :
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
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 unders
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 , i
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!
P.S.
21 matches
Mail list logo
