On 30 Jan 2002, at 12:01, [EMAIL PROTECTED] wrote:
> Yet for floats there may not be such an x (y = positive zero), or there may
> be more than one (y=2^n with n chosen so that 2^n+1 is not
exactly representable but 2^n-1 is, then
> x could be 2^n or 2^n-1).
Well, I am just a newbie in Haskell
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
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
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
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 such th
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 o
> > I argued that (Num a, Ord a) makes most sense to me.
> > You argued that (Integral a) was a conscious choice (something I
> > don't remember but I'm sure you're right), and is the right one anyway.
> >
> > I'd be interested to know what others think. If there's any doubt,
> > we'll stay with
> I argued that (Num a, Ord a) makes most sense to me.
> You argued that (Integral a) was a conscious choice (something I
> don't remember but I'm sure you're right), and is the right one anyway.
>
> I'd be interested to know what others think. If there's any doubt,
> we'll stay with Integral.
| 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 re
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 mi
Well, it was a deliberate decision to limit the n+k pattern to class Integral
because people at that time felt that n+k was something that should
only be used with integers. So it's not a fluke, it was quite deliberate.
I kind of like Integral for this (as much as I can like anything about n+k :)
| 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, the
| 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 (for
| Btw., in 3.17.2 Informal Semantics of Pattern Matching
| the end of the following sentence should be changed:
Actually I've changed the entire wording of that section
in consultation with Ross who has read it rather carefully.
You can find the current draft of the expressions chapter at
> 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 anywa
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 (for - and fromInteg
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 t
(I sent a similar message a few days ago which got lost somewhere)
We have tried to express the semantics of some Haskell constructs by giving
a translation into "Kernel" Haskell (Report section 1.2).
This leads to difficulties because free variables in the translations can
be captured by the
|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 comprehen
Some more questions concerning some constructs in Haskell:
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 a
>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 mean a somewhere
else d
:37 1993
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 decis
> Both (>=) and (-) belong to classes defined in PreludeCore,
> and hence cannot be rebound. This was a deliberate decision,
> made in order to turn your point into a non-problem.
It's true that things from PreludeCore cannot be rebound on the top level,
but they can be rebound locally. So the
Phil wrote:
> Both (>=) and (-) belong to classes defined in PreludeCore,
> and hence cannot be rebound. This was a deliberate decision,
> made in order to turn your point into a non-problem.
>
> Long live (n+k)! -- P
The Report tries to handle this by "always implicitly importing"
Pr
Lennart Augustsson <[EMAIL PROTECTED]> writes:
> PS. I'd like to start the "Ban n+k patterns"-movement, any followers?
Count on me! I guess this makes it an organized movement ... two persons
(movement) that know about each other (organized).
Cheers,
Karl-Filip
I like the capability to redefine syntax.
For example, I would like to be able to define syntax that looks like
EBNF when writing parsers. I would like to be able to write
E = T {(`+`|`-`) T}
rather than
e = concat1 (t,zeroOrMore (concat2 (alternative (lit '+',lit '-'),t)))
Of course infix
The Haskell Committee was well aware of the problem of name
capture in syntactic expansions. We discussed various solutions
and opted for the simplest (if not most formal): whenever a
name freshly appears on the right side of a translation, add
a comment that says where it came from. If you
Both (>=) and (-) belong to classes defined in PreludeCore,
and hence cannot be rebound. This was a deliberate decision,
made in order to turn your point into a non-problem.
Long live (n+k)! -- P
- Begin Included Message -
>From [EMAIL PROTECTED] Mon May 17 21:33:41 1993
From: Lenna
|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
Original-Via: uk.ac.ed.mrcvax; Thu, 28 Nov 91 08:51:34 GMT
| Personally, I think n+k patterns are a baroque left-over from views that
| someone thought would be nice to retain when views were abandonned. They
| should either be thrown out or generalised in a more regula
X-Comment1: #
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail#
X-Comment4: # administrator to update your NRS & mailer tables. #
X-
Original-Via: uk.ac.nsf; Wed, 6 Nov 91 20:00:39 GMT
Original-Sender: [EMAIL PROTECTED]
> I would be very much in favour of missing out the >= test in both n+k and
> c*n+k. As Mark says there is no need for a restriction in the latter case.
> In the former, the restriction is only there because o
Original-Via: uk.ac.st-and.cs; Wed, 6 Nov 91 14:54:59 GMT
> > | Kent Karlsson asks:
> > | | Which semantics did you use?
> > |
> > | The following seemed sensible to me (Your first choice in each case):
> >
> > [ ... my attempt at a semantics for c*p and p+k patterns ... ]
> >
> >
Original-Via: uk.ac.ox.prg; Wed, 6 Nov 91 11:44:16 GMT
> | Kent Karlsson asks:
> | | Which semantics did you use?
> |
> | The following seemed sensible to me (Your first choice in each case):
>
> [ ... my attempt at a semantics for c*p and p+k patterns ... ]
>
>I had hoped not, since t
Original-Via: uk.ac.nsf; Tue, 5 Nov 91 21:31:13 GMT
Original-Sender: [EMAIL PROTECTED]
Mark says:
This problem isn't just restricted to pattern matching ...
I'm interested in the assumptions that an implementation can legitimately
make about the way overloaded functions behave. Other no
Original-Via: uk.ac.nsf; Mon, 4 Nov 91 17:00:37 GMT
> Kent Karlsson asks:
> | Which semantics did you use?
>
> The following seemed sensible to me (Your first choice in each case):
There was no ranking!
>
> For p+k patterns: (as in the report):
> case e0 of {p+k -> e; _ -> e'
Original-Via: uk.ac.ox.prg; Mon, 4 Nov 91 13:52:20 GMT
Kent Karlsson asks:
| Which semantics did you use?
The following seemed sensible to me (Your first choice in each case):
For p+k patterns: (as in the report):
case e0 of {p+k -> e; _ -> e'}
= if e0 >= k then let {p = e0-k}
X-Comment1: #
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail#
X-Comment4: # administrator to update your NRS & mailer tables. #
X-
Original-Via: uk.ac.nsf; Mon, 4 Nov 91 11:35:00 GMT
> Incidentally, I'd suggest that we have separate (c*n) and (n+k) forms of
> pattern ... extending the syntax of patterns to:
>
> pat ::= | int * pat | pat + k
>
> This would allow c*n+k patterns as a special case, but also
Original-Via: uk.ac.ox.prg; Fri, 1 Nov 91 18:04:12 GMT
Brian Boutel writes:
| With Haskell as it is currently defined, one can take an operational view,
| that the syntactic translation given in the report defines the semantics
| of n+k patterns, and too bad if the semantics of the introduced f
Original-Via: uk.ac.ed.mrcvax; Fri, 1 Nov 91 14:00:30 GMT
> | Which leads me to one final comment. Does the Report say anywhere that
> | an overflow gives rise to an undefined result?
>
> Yes it does (though you may not like the answer!). See Section 6.8.1, p56.
>
> Simon
X-Comment1: #
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail#
X-Comment4: # administrator to update your NRS & mailer tables. #
X-
Original-Via: uk.ac.ed.mrcvax; Fri, 1 Nov 91 10:03:45 GMT
| Which leads me to one final comment. Does the Report say anywhere that
| an overflow gives rise to an undefined result?
|
| Tony
Good question! I think it should, though I fear the efficiency implications.
Ian
Original-Via: uk.ac.st-and.cs; Fri, 1 Nov 91 09:37:40 GMT
Brian says there are two distinct problems with n+k patterns,
1) That laws relating * `div` `rem` + - might not hold.
2) A user defined >= might not be strict giving rise to a match
of bottom to a refutable patt
Original-Via: uk.ac.nsf; Fri, 1 Nov 91 01:19:12 GMT
Simon says:
This is certainly technically feasible. As it happens, our compiler is set
up so that it is easy to compile any pattern which you can express as a
predicate function ("does it match?") plus an extract-binder
X-Comment1: #
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail#
X-Comment4: # administrator to update your NRS & mailer tables. #
X-
46 matches
Mail list logo
