#851: Incomplete-pattern checking for n+k patterns is not implemented
---+
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: low
#3382: Panic in tidyNPat when using N+k patterns with overloaded strings
-+--
Reporter: batterseapower|Owner:
Type: bug | Status: closed
#3382: Panic in tidyNPat when using N+k patterns with overloaded strings
-+--
Reporter: batterseapower| Owner:
Type: bug | Status: new
Priority: normal
Richard O'Keefe wrote:
The thing is that it really seems bizarre to see this one feature
singled out for non-implementation.
If I can do the equivalent of n+k patterns by programming in the
*type system*, why *not* in a pattern?
Do you mean by something like the following?
data Z = Z
#851: Incomplete-pattern checking for n+k patterns is not implemented
--+-
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: low | Milestone
#851: Incomplete-pattern checking for n+k patterns is not implemented
---+
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: low | Milestone
Hi all,
This function:
g :: Int - Int
g (x+1) = 1
g _ = 0
(erroneously) gives this warning:
Warning: Pattern match(es) are overlapped
In the definition of `g': g _ = ...
I'm not sure if this is covered by the first item on
L.S.,
On Thu, 11 Dec 2003 06:23:51 -0800, Iavor S. Diatchki [EMAIL PROTECTED] wrote:
:
:
Henk-Jan van Tuyl wrote:
1) It takes no effort, once you are use to it, to code without n+k patterns;
this does not seem like a good argument. there are many other features like that
in haskell
hi,
first here is why i think n+k patterns are problematic;
1) they lead to some parsing awkwardness (e.g. when n+k pattern bindings
are involved, but those don'treally make much sense anyways)
2) in haskell as it is, patterns are associated with algebraic
datatypes, and n+k patterns may
On Thu, 11 Dec 2003 06:23:51 -0800
Iavor S. Diatchki [EMAIL PROTECTED] wrote:
...
Henk-Jan van Tuyl wrote:
...
2) It is likely, that n+k patterns dissapear in the next Haskell
standard. If you don't like to rewrite, test and debug all your
software every few years, don't use any language
The n+k pattern issue inspired endless debates on the Haskell
committee and this feature was considered for removal in nearly every
iteration of the Haskell report. We all agreed that n+k is extremely ad-hoc but
that certain programs can be expressed slightly more elegantly using
them.
Good point. Fixed in the head, but not in 6.0
Thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Ralf Hinze
| Sent: 28 May 2003 20:40
| To: GHC bugs
| Subject: n + k patterns
|
| GHCi infers for
|
| fac 0 = 1
GHCi infers for
fac 0 = 1
fac (n + 1) = (n + 1) * fac n
the following type
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.04.2, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_|
| hbc is on the Integral side, if that counts. :-)
| Just because ghc doesn't follow the spec isn't a good reason
| to change the spec. :-)
I absolutely didn't say that! All I'm saying is
* Two of the four impls have to change regardless
* The change is non-de-stabilising on the rest of the
view is that (n+k) patterns are evil, so it doesn't really matter
what we decide. :-) No, seriously, I'm a little worried about
widening the range of numeric types for which (n+k) patterns are
supposed to work. I can (just about) imagine wanting to use Rationals
in an (n+k) pattern, but Float
.
My view is that (n+k) patterns are evil, so it doesn't really matter
what we decide. :-) No, seriously, I'm a little worried about
widening the range of numeric types for which (n+k) patterns are
supposed to work. I can (just about) imagine wanting to use Rationals
in an (n+k) pattern
I strongly disapprove of n+k patterns from a whole-language taste
perspective, so I am most unkeen to broaden their scope. Because they are
such a language kludge already it simply doesn't make sense to try to reason
rationally about what the best answer for them is. It's like putting
lipstick
I too am against broadening the scope of n+k patterns, for reasons that others have
already
given. In particular, I am absolutely against allowing n+k patterns to be used for
Float/Double.
If n+k patterns are to be meaningful at all, you want matching y against x+1, you want
a unique
x
At 03:27 30-01-02 -0800, Simon Peyton-Jones wrote:
| hbc is on the Integral side, if that counts. :-)
| Just because ghc doesn't follow the spec isn't a good reason
| to change the spec. :-)
I absolutely didn't say that! All I'm saying is
* Two of the four impls have to change regardless
* The
OK, OK, I give in!
Integral it remains. I repent.
Simon
| -Original Message-
| From: Rijk J. C. van Haaften [mailto:[EMAIL PROTECTED]]
| Sent: 30 January 2002 17:00
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: n+k patterns
|
|
| At 03:27 30-01-02 -0800, Simon
Simon Peyton-Jones wrote:
| hbc is on the Integral side, if that counts. :-)
| Just because ghc doesn't follow the spec isn't a good reason
| to change the spec. :-)
I absolutely didn't say that! All I'm saying is
* Two of the four impls have to change regardless
Only because two of the
, but this reason, together with
the fact that n+k patterns were designed to be used in inductive
definitions do make me strongly favor the restriction of n+k patterns
to the class Integral (Malcolm Wallace pointed out that there may
be a use for Rational n+k patterns, but I think it would only
In any case, I propose to change Integral to Ord and Num.
I agree. And nhc98 seems to actually implement this.
Nonetheless I find using n+k patterns for floating point numbers pretty
horrible. And it raises the question why k cannot be a rational ...
But then n+k patterns are a wart anyway
at
http://research.microsoft.com/~simonpj/tmp/exps.html
The numbered items in the Informal Semantics of Pattern Matching
are substantially changed and IHMO much clearer.
| Nonetheless I find using n+k patterns for floating point
| numbers pretty horrible. And it raises the question why k
| On Tue, Jan 29, 2002 at 07:36:56AM -0800, Simon Peyton-Jones wrote:
| The Haskell Report says of n+k patterns:
|
| A n+k pattern can only be matched against a value in
| the class Integral.
|
| This seems far too strong. All that is needed are Ord (for the =)
| and Num
| Hugs demands Integral because that's what it was told to do
| to follow the report. So in that sense, yes, the code
| depends on having only one class. But it would be easy for
| someone to change that.
|
| Then again, if we're following the rules of minimal change
| for Haskell 98, then
:).
Since this is not a typo, I don't see why it should be changed unless there
is some really good reason.
-- Lennart
Simon Peyton-Jones wrote:
Folks
The Haskell Report says of n+k patterns:
A n+k pattern can only be matched against a value in
the class Integral.
This seems far too
Simon Peyton-Jones wrote:
| Hugs demands Integral because that's what it was told to do
| to follow the report. So in that sense, yes, the code
| depends on having only one class. But it would be easy for
| someone to change that.
|
| Then again, if we're following the rules of minimal
. I don't believe it. I teach an introductory FP course
including induction. I introduce structural induction directly, and the
students have no problem with it. When I have tried to talk to individuals
about natural number induction using (n+k) patterns, then the problems
start. Because they are so
jl writes:
I feel the need to be inflamatory:
I believe n+k should go.
Again, I agree completely. Let's get rid of this horrible wart
once and for all. It's a special case that makes the language
more difficult to explain and implement. I've hardly seen any
programs using it so I don't
I think that we should try a different approach, forget about
the importing
mechanism, and make a single statement defining the intended semantics.
Section 1.2 (The Haskell Kernel) is the place. I propose adding the
following.
The translations given, and the identities given for
|What if (the appropriate parts of) the standard prelude is
| explicitly *not* imported:
|
| import Prelude ()
| or
| import Prelude hiding(map)
|
| (see section 5.4.3).
|
|Are then the hidden parts of the standard prelude still available via
| n+k patterns, list
From my point of view (n+k)-patterns have a
very special meaning. This natural numbers
should be considered as a type like this:
data Nat = Zero | Succ Nat
Therefore a (n+k)-pattern is an abbreviation for
Succ(Succ(...Zero...)). It's obvious that
"+" in "(n+k)" doesn't m
And now for a little quiz. What's the value of the following (legal)
Haskell expression? (Don't try it with hbc, it fails.)
let (+) + 1 + 1 = (+)
in 1 + 1
Given infixl 6 + (since you can't change this without renaming!):
(+) + 1 + 1
== lpat6 + pat7
And now for a little quiz. What's the value of the following (legal)
Haskell expression? (Don't try it with hbc, it fails.)
let (+) + 1 + 1 = (+)
in 1 + 1
This is illegal syntax!! (+) and (the second) + are the same
variable, thus violating the linearity constraint for
Another strange thing about n+k patterns.
Its definition uses = , but = is not part of the class Num.
Does that mean that n+k patterns have to be instances of class Real?
One could leave it class Num, if the translation were expressed
in terms of "signum" rather than "="
| Another strange thing about n+k patterns.
|
| Its definition uses = , but = is not part of the class Num.
| Does that mean that n+k patterns have to be instances of class Real?
Certainly. In fact, they're really meant to apply only to class
Integral (and it would be natural numbers, if we
Date: Tue, 18 May 93 15:55:42 +0200
From: Lennart Augustsson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: n+k patterns
Both (=) and (-) belong to classes defined in PreludeCore,
and hence cannot be rebound. This was a deliberate decision,
made in order to turn your
operators help, but what about nice multiple
token symbols like { } ?
So, minimally, I am in favor of the local redefinition of symbols like
'+' and '=', and think it unfortunate that there is a clash between
the redefinition and treatment of n+k patterns.
This is a vote for dumping n+k patterns
Phil Wadler says:
You are quite right. I'd forgotten about local rebinding,
because I feel that all local rebinding should be disallowed.
Anyone want to start a movement to eliminate local
rebinding? (1/2 :-) Cheers, -- P
And *I* think we should stop using names altogether and
: Lennart Augustsson [EMAIL PROTECTED]
Subject: n+k patterns
Date: Mon, 17 May 93 22:25:03 +0200
To: [EMAIL PROTECTED]
Could those in charge of the formal semantics of Haskell (yes,
that's you folks in Glasgow!) tell me what the meaning of n+k patterns
are?
In the report it says that
case e0
the problem I state does occur.
OK, I think that (=), (-), etc. should refer to those from PreludeCore,
but it doesn't say anywhere.
Another question along the same lines: What if (+) has been rebound?
Are n+k patterns still allowed?
-- Lennart
|Another question along the same lines: What if (+) has been rebound?
|Are n+k patterns still allowed?
|
|-- Lennart
The answer should be that n+k patterns are still allowed, but (+), (-),
and (=) from PreludeCore are used in the translation.
--Joe
43 matches
Mail list logo
