On 16 May 2009, at 03:54, wren ng thornton wrote:
Conor McBride wrote:
Rumblings about funny termination behaviour, equality
for functions, and the complexity of unification (which
isn't the proposal anyway)
But unification is what you get by adding non-linearity.
Hang on a minute: we're s
Algebraic datatypes are built and unpacked with constructors.
Pattern matching is just a way to use these constructors.
This is distinct from the kind of unification/validation that
happens in logic languages like Prolog. There is no special list
constructor for when the first two items
Conor McBride wrote:
Rumblings about funny termination behaviour, equality
for functions, and the complexity of unification (which
isn't the proposal anyway)
But unification is what you get by adding non-linearity. Sure, all terms
are ground; would you prefer I said "testing for membership in
Simplicity of pattern matching semantics, not of implementation (we
all knew how to implement it).
Miranda had non-linear patterns, but nobody really argued for them in Haskell.
If Haskell had them, I'd not argue to have them removed, but nor will
I argue to add them.
-- Lennart
On Fri, May 15,
Conor McBride wrote on 15.05.2009 16:19:
My guess is that if this feature were already in, few would be campaigning to
remove it.
You're probably right. For example, I'm not compaigning to remove multiple inheritance (from non-abstract classes) from C++. But I still think
it's an ugly feat
On 15 May 2009, at 12:07, Lennart Augustsson wrote:
In the original language design the Haskell committee considered
allowing multiple occurrences of the same variable in a pattern (with
the suggested equality tests), but it was rejected in favour of
simplicity.
Simplicity for whom, is the qu
In the original language design the Haskell committee considered
allowing multiple occurrences of the same variable in a pattern (with
the suggested equality tests), but it was rejected in favour of
simplicity.
-- Lennart
On Fri, May 15, 2009 at 11:30 AM, Sittampalam, Ganesh
wrote:
> Conor McB
Conor McBride wrote:
> On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote:
>>
>> but then pattern matching can introduce Eq constraints which some
>> might see as a bit odd.
>
> Doesn't seem that odd to me. Plenty of other language features come
> with constraints attached.
It's the introductio
I miss lots of stuff from when I was a kid. I used to write
elem x (_ ++ x : _) = True
elem _ _ = False
and think that was cool. How dumb was I?
Yeah, the Kiel Reduction Language had similarly expressive
and fun pattern matching, with subsequence matching and
backtracking if
Conor McBride wrote:
Hi
Sittampalam, Ganesh wrote:
> Martin Hofmann wrote:
> > It is pretty clear, that the following is not a valid Haskell pattern:
> >
> > foo (x:x:xs) = x:xs
> >
> > My questions is _why_ this is not allowed. IMHO, the semantics should
> > be
> > clear: The pattern is expecte
Hi
On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote:
Martin Hofmann wrote:
It is pretty clear, that the following is not a valid Haskell
pattern:
foo (x:x:xs) = x:xs
My questions is _why_ this is not allowed. IMHO, the semantics should
be
clear: The pattern is expected to succeed, iff '
Why, then, not permit such definitions only for members of Eq?
My thoughts:
- because it will break an important invariant indicated by Martin,
namely the one that says that pattern variables are not forced
- it will make efficient compilation of pattern matching much harder
- it will make the t
Dear Martin,
I think that the (practical) reason is avoiding equality checks during
pattern matching.
For instance, how do you evaluate this:
foo ((+1):(1+):[])?
Both expressions in the first and second entries of the list are
semantically equivalent,
but from an operational point of
Martin Hofmann wrote:
> It is pretty clear, that the following is not a valid Haskell pattern:
>
> foo (x:x:xs) = x:xs
>
> My questions is _why_ this is not allowed. IMHO, the semantics should
> be
> clear: The pattern is expected to succeed, iff 'x' is each time bound
> to the same term.
How
Martin Hofmann wrote:
It is pretty clear, that the following is not a valid Haskell pattern:
foo (x:x:xs) = x:xs
My questions is _why_ this is not allowed. IMHO, the semantics should be
clear: The pattern is expected to succeed, iff 'x' is each time bound to
the same term.
Isn't this allowed
What would you expect
foo [id, \x -> x]
to be?
Martin Hofmann wrote on 15.05.2009 12:09:
It is pretty clear, that the following is not a valid Haskell pattern:
foo (x:x:xs) = x:xs
My questions is _why_ this is not allowed. IMHO, the semantics should be
clear: The pattern is expected to succe
16 matches
Mail list logo
