Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On Fri, Jul 13, 2012 at 9:12 PM, Gábor Lehel wrote:
> On Thu, Jul 12, 2012 at 7:38 PM, Cale Gibbard 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 progress.
I don't much care whether what is implemented is "\case" or "case of" or
even "\of" (even though that last reads weird), but "\case of" strikes me
as including syntactic noise (a pointless extra token). One or the other;
not both.
--
brandon s allbery allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On Thu, Jul 12, 2012 at 7:38 PM, 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 a simple extension of operator
> sections to another part of the syntax.
>
> Does anyone else agree?
>
I also completely agree, but I don't want my opinion to get in the way
of progress.
--
Your ship was caught in a monadic eruption.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type error when deriving Generic for an associated data type
On 12 July 2012 12:33, Andres Löh wrote: > Your example compiles for me with HEAD (but fails with 7.4.1 and > 7.4.2, yes). I've not tested if it also "works". Great, I will wait for a new release then. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needsyourhelp
Quoth Wolfgang Jeltsch , ... > What is an anonymous function? A function that has no name, that is, a > function that is not assigned to an identifier. So (+ 1), \x -> x + 1, > and any lambda case are all anonymous functions. All right, that more general definition works for me. It doesn't take much away from my point, though - in any case, clarity doesn't demand that we use \ for all these things, only for \ x -> x + 1. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
On 13.07.2012 19:27, Brandon Allbery wrote: On Fri, Jul 13, 2012 at 7:29 AM, Aleksey Khudyakov mailto:alexey.sklad...@gmail.com>> wrote: Num inherits from Eq, so Float couldn't have an instance for Num if we didn't have that Eq instance. No more since GHC 7.4. But Eq is indeed superclass of Ord and it Ord is used a lot. ...but Float's Ord instance is even more dubious than its Eq. What's wrong with it except for NaN? NaN surely breaks every law but otherwise it's OK. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needsyour help
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. I don't see this as an `anonymous function' in any special sense,
> only inasmuch as the workaround in its absence involves one. I.e., if
> I for some reason had been compelled to write
>\ a -> hPutStrLn stdout a
>
> ... that wouldn't make "hPutStrLn stdout" an anonymous function in my book.
> Neither is `case of ...' an anonymous function, or functions.
>
> Donn
What is an anonymous function? A function that has no name, that is, a
function that is not assigned to an identifier. So (+ 1), \x -> x + 1,
and any lambda case are all anonymous functions.
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
On Fri, Jul 13, 2012 at 7:29 AM, Aleksey Khudyakov < alexey.sklad...@gmail.com> wrote: > Num inherits from Eq, so Float couldn't have an instance for Num if we >> didn't have that Eq instance. >> >> No more since GHC 7.4. But Eq is indeed superclass of Ord and it Ord is > used a lot. ...but Float's Ord instance is even more dubious than its Eq. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needsyour help
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,
only inasmuch as the workaround in its absence involves one. I.e., if
I for some reason had been compelled to write
\ a -> hPutStrLn stdout a
... that wouldn't make "hPutStrLn stdout" an anonymous function in my book.
Neither is `case of ...' an anonymous function, or functions.
Donn
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
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 replacing the \ with proc (like in “proc case”).
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. If the abbreviation
contained no \, there would be no way to replace it with a proc.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
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 the former makes sense to me as a simple extension of operator
> sections to another part of the syntax.
>
> Does anyone else agree?
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 replacing the \ with proc (like in “proc case”).
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
On 13.07.2012 14:18, Sönke Hahn wrote: On 07/13/2012 03:12 AM, Bardur Arantsson wrote: Speaking of which... would it be remiss of me to mention the elephant in the room, namely the Eq instance for Float? AFAICT there is no possible way for a Float value to fulfill the Eq type class requirements, so why is it an instance? (I'm thinking of the "weird" Nan/Infinity behvaior primarily). Is there *really* such a huge amount of code out there that relies on an Eq (or Ord for that matter!) instance for Float? If so... shouldn't that code be fixed rather than being subtly buggy? Num inherits from Eq, so Float couldn't have an instance for Num if we didn't have that Eq instance. No more since GHC 7.4. But Eq is indeed superclass of Ord and it Ord is used a lot. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
On 07/13/2012 03:12 AM, Bardur Arantsson wrote: > Speaking of which... would it be remiss of me to mention the elephant in > the room, namely the Eq instance for Float? > > AFAICT there is no possible way for a Float value to fulfill the Eq type > class requirements, so why is it an instance? (I'm thinking of the > "weird" Nan/Infinity behvaior primarily). Is there *really* such a huge > amount of code out there that relies on an Eq (or Ord for that matter!) > instance for Float? If so... shouldn't that code be fixed rather than > being subtly buggy? Num inherits from Eq, so Float couldn't have an instance for Num if we didn't have that Eq instance. BTW: My newsgroup client seems to have eaten my last mail. I filed a bug report here: http://hackage.haskell.org/trac/ghc/ticket/7069 Cheers, Sönke ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
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 ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359 GHC HQ has reached a consensus[1]. [1] http://hackage.haskell.org/trac/ghc/ticket/4359#comment:69 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Mikhail Vorozhtsov 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 > at the ticket[2], vote and comment on the proposals! > > P.S. I'm CC-ing Cafe to attract more people, but please keep > the discussion to the GHC Users list. > > [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching > [2] http://hackage.haskell.org/trac/ghc/ticket/4359 Apart from lambda match, the suggestions seem to me to be poor solutions to an old piece of bad design and they don’t fit very well with the look of haskell. Way back at the beginning of time, I was against pattern matching altogether as it seemed like a seductive feature that wouldn’t generalise very well. I wanted algebraic combinations of some form of guarded expressions. But the rest of the committee wanted pattern matching (I think they were right — the seductive aspect is important and if I had had my way Haskell would not have been as popular as it is now) and it seemed logical to have pattern matching in lambdas too. But that led to lambdas that can fail, which I think was a bad decision. What I would rather have happen now is that we introduce a distinction between pure destructor patterns (where a type is not a sum) and patterns that can fail. Then mandate that at some future date \pattern1 -> expression will be invalid unless pattern1 is a pure destructor, (but to begin with the compiler would just issue a warning). Now \pattern1 -> expression has type a -> b without a hidden exception. Then add another lambda for patterns that can fail, eg \? pattern -> expression, which has a type reflecting the fact that the match can fail, eg a -> Maybe b. Add operators to combine such lambda expressions (eg a symbol — on the lines of || — for liftA2 mplus) and a means of getting the answer out when all the bases are covered (something a bit handier than just having an operator for liftA2 fromMaybe, though that would cover all the use cases that end with \? _ -> e). lambda match is very close to that and worked out in more detail. So I’m against the other proposals. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
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 as
> expressions whose value happens to be a function. The point is just
> that there are already a few other places in the syntax where the
> omission of a value results in a function having the omitted value as
> its parameter. At least to me, it seems natural to extend that pattern
> in this case.
The question is, how self explanatory is the syntax? I think that
sections and partial function application are pretty self explanatory
just by looking at the expression, because it tells you visually pretty
well what it actually does.
'case of {}' isn't self explanatory, because you don't have a visual
hint what happend with the parameter between 'case' and 'of'.
I can see why - I think it was Simon - proposed '\of', because you could
read it as if the parameter between 'case' and 'of' is applied to the 'of'.
I don't like the version 'case of {}' and I even don't like the version
'\case of' that much, because I think both versions degrade the syntax
of Haskell, which is part of the beauty of Haskell and we shouldn't rush
in expanding it, only for pragmatic reasons.
Greetings,
Daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
