On 10/2/10, Christopher Done wrote:
> On 2 October 2010 20:23, Max Bolingbroke wrote:
>> Do you like this feature and think it would be worth incorporating
>> this into GHC? Or is it too specialised to be of use? If there is
>> enough support, I'll create a ticket and see what GHC HQ make of it.
At 3:36 AM -0600 10/5/10, Luke Palmer wrote:
On Mon, Oct 4, 2010 at 9:04 PM, Dean Herington
wrote:
With respect to "datatype destructing" functions, the Prelude has:
maybe :: b -> (a -> b) -> Maybe a -> b
either :: (a -> c) -> (b -> c) -> Either a b -> c
which suggests the following signa
-1 for if then. The examples of "curried" if then else look, to my
eyes, less readable than the pointed version. And it's easy enough to
write a 'bool' deconstructor, or an 'ifM' for the monadic case.
+1 for something to solve the "dummy <- m; case dummy of" problem.
Here are the possibilities I
On 6/10/2010, at 5:56 AM, Brandon S Allbery KF8NH wrote:
>> In order to be consistent with current case, maybe in layout mode:
>>
>> \1 -> f
>> 2 -> g
>>
>> and in non-layout mode
>>
>> \{1 -> f; 2 -> g}
>
> +1; likewise for consistency it should support guards (which would preclude
> using |
On 4 October 2010 00:38, Conal Elliott wrote:
> I like it!
>
> Are the other sections available as well, e.g.,
>
> (if False then else "Cafe") "Haskell" --> "Cafe"
They are not, though this would certainly make sense for lambda-if.
It's not so clear with lambda-case because of the issue of fr
On 5 October 2010 17:38, Henning Thielemann
wrote:
> Richard O'Keefe schrieb:
>
>> I'd prefer to see something like
>> \ 1 -> f
>> | 2 -> g
>> but I'm sure something could be worked out.
>
> In order to be consistent with current case, maybe in layout mode:
>
> \1 -> f
> 2 -> g
>
> an
Quoth Ketil Malde ,
...
> Just that they seem to be natural generalizations. If it's just the
> single form of paramtrizing the condition, I think it's better served by
> a regular function, 'bool' or (??) or whatever.
Well, yes, there's some logic to that. Like,
bool b c a = if a
then
Donn Cave writes:
> I think you're not the first to ask. Just out of curiosity, or is
> there a use for these variations?
Just that they seem to be natural generalizations. If it's just the
single form of paramtrizing the condition, I think it's better served by
a regular function, 'bool' or (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/10 12:38 , Henning Thielemann wrote:
> In order to be consistent with current case, maybe in layout mode:
>
> \1 -> f
> 2 -> g
>
> and in non-layout mode
>
> \{1 -> f; 2 -> g}
+1; likewise for consistency it should support guards (which wo
Richard O'Keefe schrieb:
> I'd prefer to see something like
> \ 1 -> f
> | 2 -> g
> but I'm sure something could be worked out.
In order to be consistent with current case, maybe in layout mode:
\1 -> f
2 -> g
and in non-layout mode
\{1 -> f; 2 -> g}
?
__
For what it's worth, after all this discussion my rather cheeky preference
is as follows:
Instead of introducing more specialised syntax, remove both existing special
syntaxes for if and case, and introduce multi-clause support for lambdas!
Cheers!
On 2 October 2010 19:23, Max Bolingbroke wrote
I also vote +1 for lambda-case, and abstain for lambda-if.
I don't think multiple-clause lambdas being desirable should be an
argument against lambda-case. After all, we can also define top-level
functions with either multiple clauses or a single case expression.
Haskell has always followed the TM
On Tue, 5 Oct 2010 03:36:12 -0600, Luke Palmer wrote:
> On Mon, Oct 4, 2010 at 9:04 PM, Dean Herington
> wrote:
> > With respect to "datatype destructing" functions, the Prelude has:
> >
> > maybe :: b -> (a -> b) -> Maybe a -> b
> > either :: (a -> c) -> (b -> c) -> Either a b -> c
> >
> > which
On 05/10/10 07:52, Nicolas Wu wrote:
I'd prefer to see something like
\ 1 -> f
| 2 -> g
but I'm sure something could be worked out.
While I think the "case of"
is a good idea, multiple clauses in lambdas seems more canonical to
me.
Alternatively, we could abandon la
On Mon, Oct 4, 2010 at 9:04 PM, Dean Herington
wrote:
> With respect to "datatype destructing" functions, the Prelude has:
>
> maybe :: b -> (a -> b) -> Maybe a -> b
> either :: (a -> c) -> (b -> c) -> Either a b -> c
>
> which suggests the following signatures for the analogues for Bool and list
> To repeat, the analogues in SML and Erlang *do* support multiple
> clauses (as well as pattern matching) and the failure of Haskell
> lambdas to do so has always seemed like a weird restriction in a
> language that's usually free of weird restrictions.
I agree with this sentiment. I have never u
At 12:05 PM +0200 10/4/10, Christopher Done wrote:
On 4 October 2010 10:55, Bulat Ziganshin wrote:
Hello Ketil,
Monday, October 4, 2010, 11:30:48 AM, you wrote:
Prelude> (if then "Haskell" else "Cafe") False
lambda-if is easily implemented in terms of usual functions.
and we even have
On 5/10/2010, at 12:49 PM, Donn Cave wrote:
> Just to be sure, are you saying, rather than
>
>case of
>1 -> f
>2 -> g
>
> you'd like to see \ support pattern matching etc. like named functions -
>
>\ 1 -> f
> 2 -> g
Absolutely.For the record, lambda DOES suppor
Quoth "Richard O'Keefe" ,
...
> Erlang manages fine with multiclause 'fun':
>
> (fun (1) -> "One" ; (_) -> "Not-one" end)(1)
>
> ML manages fine with multiclause 'fn':
>
> (fn 1 => "one" | _ => "not-one")(1)
>
> In both cases, the same notation is used for multiclause lambda as
> for si
On 4/10/2010, at 8:30 PM, Ketil Malde wrote:
>
>> Prelude> (case of 1 -> "One"; _ -> "Not-one") 1
>> "One"
>> Prelude> :q
>
> "case of" looks a bit weird, but I like the points brought up about
> avoiding to name a one-use variable (e.g., getArgs >>= case of ...)
> AFACS, this isn't easily imple
I really like the lambda-case. There are dozens of places in my code
where I could use it.
Not so sure about the lambda-if. It is just as easily done using an
ordinary function.
lambda-case: +1
lambda-if: neutral
___
Haskell-Cafe mailing list
Haskell-Ca
Quoth Ketil Malde ,
> Max Bolingbroke writes:
...
>> Prelude> (if then "Haskell" else "Cafe") False
>> "Cafe"
>
> Presumably, this extends to
>
>> Prelude> (if False then else "Cafe") "Haskell"
>> "Cafe"
>
> and
>
>> Prelude> (if then "Haskell" else) False "Cafe"
>> "Cafe"
>
> as well?
I think y
On 4 October 2010 10:55, Bulat Ziganshin wrote:
> Hello Ketil,
>
> Monday, October 4, 2010, 11:30:48 AM, you wrote:
>>> Prelude> (if then "Haskell" else "Cafe") False
>
> lambda-if is easily implemented in terms of usual functions.
> and we even have one named bool:
>
> bool: Bool -> a -> a -> a
Hello Ketil,
Monday, October 4, 2010, 11:30:48 AM, you wrote:
>> Prelude> (if then "Haskell" else "Cafe") False
lambda-if is easily implemented in terms of usual functions.
and we even have one named bool:
bool: Bool -> a -> a -> a
lambda-case cannot be implemented as a function since we need
m
Max Bolingbroke writes:
> [1] http://hackage.haskell.org/trac/haskell-prime/ticket/41
I tried to find anything about lambda-if in there, but failed (Trac and
I aren't on very friendly terms, so it's probably my fault). Is there
more information about the rationale and use cases for this?
> Pr
I like it!
Are the other sections available as well, e.g.,
(if False then else "Cafe") "Haskell" --> "Cafe"
- Conal
On Sat, Oct 2, 2010 at 11:23 AM, Max Bolingbroke wrote:
> Hi Cafe,
>
> I implemented the proposed Haskell' feature lambda-case/lambda-if [1]
> during the Haskell Implementor
On 10/2/10 3:13 PM, Christopher Done wrote:
There's nothing more annoying than having to introduce intermediate
bindings when you're going to immediate pattern match against it
immediately and never use it again. It's both annoying to have to
think of a variable name that makes sense and is not i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/2/10 15:27 , Jan Christiansen wrote:
> You can use a similar approach for case expressions ; )
There are several better (that is, not using unsafePerformIO) versions at
http://haskell.org/haskellwiki/Case .
- --
brandon s. allbery [linux,s
On Sat, Oct 2, 2010 at 4:13 PM, Christopher Done
wrote:
> There's nothing more annoying than having to introduce intermediate
> bindings when you're going to immediate pattern match against it
> immediately and never use it again. It's both annoying to have to
> think of a variable name that makes
On 02.10.2010, at 20:35, Henning Thielemann wrote:
On Sat, 2 Oct 2010, Colin Paul Adams wrote:
Prelude> (if then "Haskell" else "Cafe") False
Max> "Cafe"
My reaction is to ask:
Can you write this as:
(if then else) False "Haskell" "Cafe"
?
Sure:
ifThenElse :: Bool -> a -> a ->
On 2 October 2010 19:33, Henning Thielemann
wrote:
>
> On Sat, 2 Oct 2010, Max Bolingbroke wrote:
>
> ... lambda-case/lambda-if ...
>>
>
> Nice! Concerning if-then-else I would more like to see an according
> function to go to Data.Bool, then we won't need more syntactic sugar like
> if-then-else.
I just had a look at hpaste.org, and, amusingly, the first paste has this:
down <- openLazyURI "http://list.iblocklist.com/?list=bt_level1";
case down of
Left _ -> error "Could not download file"
Right bs -> do input <- bs
...
On 2 October 2010 20:23, Max Bolingbroke wrote:
> Do you like this feature and think it would be worth incorporating
> this into GHC? Or is it too specialised to be of use? If there is
> enough support, I'll create a ticket and see what GHC HQ make of it.
Nice work! I like it and have wanted it f
On Sat, 2 Oct 2010, Colin Paul Adams wrote:
"Max" == Max Bolingbroke writes:
Prelude> (if then "Haskell" else "Cafe") False
Max> "Cafe"
My reaction is to ask:
Can you write this as:
(if then else) False "Haskell" "Cafe"
?
Sure:
ifThenElse :: Bool -> a -> a -> a
ifThenElse True
On Sat, 2 Oct 2010, Max Bolingbroke wrote:
Hi Cafe,
I implemented the proposed Haskell' feature lambda-case/lambda-if [1]
during the Haskell Implementors Workshop yesterday for a bit of fun.
The patches are online [2, 3].
The feature is demonstrated in this GHCi session:
$ inplace/bin/ghc-st
> "Max" == Max Bolingbroke writes:
Prelude> (if then "Haskell" else "Cafe") False
Max> "Cafe"
My reaction is to ask:
Can you write this as:
(if then else) False "Haskell" "Cafe"
?
--
Colin Adams
Preston Lancashire
() ascii ribbon campaign - against html e-mail
/\ www.asciirib
Hi Cafe,
I implemented the proposed Haskell' feature lambda-case/lambda-if [1]
during the Haskell Implementors Workshop yesterday for a bit of fun.
The patches are online [2, 3].
The feature is demonstrated in this GHCi session:
$ inplace/bin/ghc-stage2 --interactive -XLambdaCase
GHCi, version 7
37 matches
Mail list logo
