| And I think that the solution is not to make the language larger and larger
| everytime someone wants a feature but to give people the tools to provide
| features without language changes.
Of course that would be even better! (Provided of course the resulting
programs were comprehensible.) Ha
On Thu, Dec 06, 2007 at 11:40:58PM +0100, Ben Franksen wrote:
> Aaron Denney wrote:
> > On 2007-12-06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> >> list comprehensions deal with specific operations (map, filter, etc.)
> >> of a specific type ([]).
> >
> > Ah, so we should bring back monad comp
Am Donnerstag, 6. Dezember 2007 22:47 schrieb Aaron Denney:
> On 2007-12-06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> > list comprehensions deal with specific operations (map, filter, etc.)
> > of a specific type ([]).
>
> Ah, so we should bring back monad comprehensions?
No, we already have
Aaron Denney wrote:
> On 2007-12-06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
>> list comprehensions deal with specific operations (map, filter, etc.)
>> of a specific type ([]).
>
> Ah, so we should bring back monad comprehensions?
I don't miss monad comprehension much, but I'd like to have a
On 2007-12-06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> list comprehensions deal with specific operations (map, filter, etc.)
> of a specific type ([]).
Ah, so we should bring back monad comprehensions?
--
Aaron Denney
-><-
___
Haskell-Cafe maili
Am Donnerstag, 6. Dezember 2007 10:03 schrieb Simon Peyton Jones:
> [redirecting to Haskell Cafe]
>
> | > It is clear that this situation must not stay this way. Bit by bit,
> | > disciples of Perl and Python discover Haskell and demand that Haskell
> | > will be plastered with syntactic sugar unt
[redirecting to Haskell Cafe]
| > It is clear that this situation must not stay this way. Bit by bit,
| > disciples of Perl and Python discover Haskell and demand that Haskell will
| > be plastered with syntactic sugar until the simplicity of the functional
| > approach isn’t visible anymore. Sa
Hello everyone,
Just to clarify, the intended semantics of my example was that it
should behave as if we were to duplicate the common prefix:
server text
| Just xs <- parse text, "field1" `elem` xs = ... do one thing ...
| Just xs <- parse text, "field2" `elem` xs = ... do something else .
It seems there is previous background here that I am unaware of. I'll
chime in anyway.
What you describe as the "wrong semantics" seems to me to be the more
appropriate. I am inferring that your expected behavior is explained
such that the first server match ought to fail (and fall through to
the
Neil Mitchell wrote:
>> server text
>>| Just xs <- parse text = let
>> x | "field1" `elem` xs = error "... do one thing ..."
>>| "field2" `elem` xs = error "... do something else ..."
>> in x
>> server _ = error "... invalid request ..."
>
> This now has the wrong semant
Hi
> server text
>| Just xs <- parse text = let
> x | "field1" `elem` xs = error "... do one thing ..."
>| "field2" `elem` xs = error "... do something else ..."
> in x
> server _ = error "... invalid request ..."
This now has the wrong semantics - before if parse text
11 matches
Mail list logo
