Re: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented

2009-11-22 Thread GHC
#851: Incomplete-pattern checking for n+k patterns is not implemented
---+
  Reporter:  simonpj   |  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  low   |  Milestone:  _|_ 
 Component:  Compiler  |Version:  6.4.2   
Resolution:  wontfix   |   Keywords:  warnings
Difficulty:  Unknown   | Os:  Unknown/Multiple
  Testcase:  ds061 |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by igloo):

  * status:  new = closed
  * failure:  = None/Unknown
  * resolution:  = wontfix

Comment:

 The !NoNPlusKPatterns proposal was accepted for H'2010, so I don't think
 it is worth spending time on this.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/851#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #3382: Panic in tidyNPat when using N+k patterns with overloaded strings

2009-07-22 Thread GHC
#3382: Panic in tidyNPat when using N+k patterns with overloaded strings
-+--
Reporter:  batterseapower|Owner:  
Type:  bug   |   Status:  closed  
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.10.4  
Severity:  normal|   Resolution:  fixed   
Keywords:|   Difficulty:  Unknown 
Testcase:  deSugar/should_run/T3382  |   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonpj):

  * testcase:  = deSugar/should_run/T3382
  * difficulty:  = Unknown
  * status:  new = closed
  * resolution:  = fixed

Comment:

 Ah yes, excellent point.  Fixed by
 {{{
 Mon Jul 20 07:12:26 GMT Daylight Time 2009  simo...@microsoft.com
   * Fix Trac #3382: desugaring of NPats

   Max spotted that the short-cut rules for desugaring NPats (where
   we compare against a literal) were wrong now that we have overloaded
   strings.
 }}}
 thanks

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3382#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


[GHC] #3382: Panic in tidyNPat when using N+k patterns with overloaded strings

2009-07-18 Thread GHC
#3382: Panic in tidyNPat when using N+k patterns with overloaded strings
-+--
Reporter:  batterseapower|  Owner:  
Type:  bug   | Status:  new 
Priority:  normal|  Component:  Compiler
 Version:  6.10.4|   Severity:  normal  
Keywords:|   Testcase:  
  Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
-+--
 Spotted this while reading the source code to tidyNPat. It looked dubious
 to me, and indeed it is:

 {{{
 {-# OPTIONS_GHC -XOverloadedStrings #-}
 module Main where

 import Data.String

 instance IsString Int where
 fromString x = 1337

 f :: Int - String
 f hello = correct
 f _   = false

 main = do
 print $ f 1337
 print $ f 1338
 }}}

 Result:

 {{{
 mbolingbr...@mb566 ~/Programming/Checkouts
 $ ghc --make Boog.hs
 [1 of 1] Compiling Main ( Boog.hs, Boog.o )
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.10.3 for i386-apple-darwin):
 tidyNPat
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3382
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


RE: [Haskell-cafe] (n+k) patterns

2009-04-23 Thread Sittampalam, Ganesh
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
data S n = S n

type Plus2 a = S (S a)

minus2 :: Plus2 a - a
minus2 _ = undefined -- or actually use the values, or whatever

If so, I'd say that n+k patterns go well beyond this kind of pattern
aliases, particularly since they operate on arbitrary Nums, not just an
inductively defined natural number type.

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented

2006-10-21 Thread GHC
#851: Incomplete-pattern checking for n+k patterns is not implemented
--+-
 Reporter:  simonpj   |  Owner: 
 Type:  bug   | Status:  new
 Priority:  low   |  Milestone:  _|_
Component:  Compiler  |Version:  6.4.2  
 Severity:  normal| Resolution: 
 Keywords:  warnings  | Difficulty:  Unknown
 Testcase:  ds061 |   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * keywords:  = warnings
  * testcase:  = ds061

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/851
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented

2006-09-28 Thread GHC
#851: Incomplete-pattern checking for n+k patterns is not implemented
---+
  Reporter:  simonpj   |  Owner: 
  Type:  bug   | Status:  new
  Priority:  low   |  Milestone:  _|_
 Component:  Compiler  |Version:  6.4.2  
  Severity:  normal| Resolution: 
  Keywords:| Os:  Unknown
Difficulty:  Unknown   |   Architecture:  Unknown
---+
Changes (by simonpj):

  * milestone:  = _|_
  * priority:  normal = low

Comment:

 See Task #595

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/851
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Erroneous warning with n+k patterns

2005-08-19 Thread Ian Lynagh

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
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html
but if so (well, probably even if not; I've grown quite attached to
-Wall -Werror) then I'd like to add my voice to those who would like to
see the mentioned overhaul done.


Thanks
Ian

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

2003-12-12 Thread Henk-Jan van Tuyl
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. for example, going by that we could
remove lambda abstractions (i am not saying we should)
This is, of course, as apposed to the effort it takes to solve problems that might occur when using n+k patterns.

on the other hand, when you often use these patterns, you might spend hours debugging an endless looping program.
how do n+k patterns lead to looping programs?
I can't remember exactly, it was a complicated story and I already decided not to use these patterns (it had something to do with pattern bindings; I don't know where I read it).


If you are working under high pressure in a large project, chances are, that the testing departement will find your bug and write a bug report (or worse, the customer might find it). Report handling and bug solving costs an enormous amount of money. This has resulted in the clean room approach for software design: prevent bugs rather than solve them. See also Finnagle's Law.
i find this reasoning backward.  i agree (of course!) that we should write 
programs without bugs. i find it strange that people often motivate that, by telling 
me that bugs cost a lot of money for some company.
if companies happened to make money out of bugs (and some do), would it then be ok to 
write buggy software?
i guess it all comes down to what one takes as primary -- writing good software, or 
making money.
It is almost impossible to write large programs without bugs; it takes a lot of 
effort to prevent/solve bugs, and a lot of people don't seem to care much about this.
I have often heard remarks like:
  - We don't have time to do things right the first time; our software will be too 
expensive if we try to do that.
  - It's easier to solve bugs afterwards. (How will you know you found every bug?)
  - It takes too much time to think about a structured solution.
  - If I use a goto, I have less typing to do. You can write perfect programs using 
gotos.
  - After explaining the first few steps of the V-model to a new project leader: Whenever 
will you get to the real work if you do all that?!
  - (At the yearly performance evaluation:) You asked me to write down the specs of 
the program that you were to design: you shouldn't stick to formalism when we have so 
little time.
  - We have to release version 3.0 before our competitor (or: we have to stick to the 
release date); we will solve the rest of the bugs in 3.1 (as we had only one month to 
solve a lot of bugs and add the missing pieces and it wasn't properly tested, release 
3.1.1 was necessary to get the product accepted by our customers).
  - The client doesn't mind a few bugs.
If you look up statistics in software engineering books, you will find that only one or two percent of the software is bugfree and according to customer specifications, at the first release. An amazing percentage of projects is even never finished (I believe it was twenty percent).

To get back to the topic of this mailing list: in my search for reliable software for a reasonable amount of work, I found that Lockheed uses a functional language in the specification phase of their projects, to create testable function specifications. That's why I am now studying Haskell, to use either as a specification language or for coding the final product.

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/compiler features that are likely to dissapear. This is another thing that might cost companies a lot of money.
i didn't know anyone is working on a next haskell standard.  have n+k patterns been made obsolete?
See http://www.haskell.org/development/ or search the web for Haskell 2 or Haskell II.

-iavor



--
Best regards,
Henk-Jan van Tuyl
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe


bugs from n+k patterns (was: Re: Preventing/handling space leaks)

2003-12-11 Thread Iavor S. Diatchki
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 erronously suggest that all numbers are such

for the rest, apologies if i appear to be ranting :-)

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. for example, going by that we could
remove lambda abstractions (i am not saying we should)

on the other hand, when you often use these patterns, you might spend 
hours debugging an endless looping program. 
how do n+k patterns lead to looping programs?

If you are working under high pressure in a large project, chances 
are, that the testing departement will find your bug and write a bug 
report (or worse, the customer might find it). Report handling and bug 
solving costs an enormous amount of money. This has resulted in the 
clean room approach for software design: prevent bugs rather than 
solve them. See also Finnagle's Law.
i find this reasoning backward.  i agree (of course!) that we should 
write programs without bugs. 
i find it strange that people often motivate that, by telling me that 
bugs cost a lot of money for some company.
if companies happened to make money out of bugs (and some do), would it 
then be ok to write buggy software?
i guess it all comes down to what one takes as primary -- writing good 
software, or making money.

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/compiler features 
that are likely to dissapear. This is another thing that might cost 
companies a lot of money.
i didn't know anyone is working on a next haskell standard.  have n+k 
patterns been made obsolete?

-iavor

--
==
| Iavor S. Diatchki, Ph.D. student   | 
| Department of Computer Science and Engineering |
| School of OGI at OHSU  |
| http://www.cse.ogi.edu/~diatchki   |
==

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

2003-12-11 Thread Derek Elkins
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/compiler features 
  that are likely to dissapear. This is another thing that might cost 
  companies a lot of money.
 
 i didn't know anyone is working on a next haskell standard.  have n+k 
 patterns been made obsolete?

I don't know of any other feature that has had this, Many people feel
that n+k patterns should not be used. These patterns may be removed or
changed in future versions of Haskell., said about it in the (online)
Report (3.17.2).  Obviously, the second sentence is vacuous; anything
can be removed or changed in future versions of Haskell, but the intent
seems clear (and is somewhat self-fulfilling).

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

2003-12-11 Thread John Peterson
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.  Unfortunately n+k doesn't match against negative numbers, so

let n+1 = ... in  n ...

is not the same as 

let n =  in    (n-1) ...

Of course n+k was designed for natural numbers but these are not a
separate numeric type so you get a certain amount of confusion.  One
proposal was to make naturals a distinct type and restrict n+k to only
naturals.   

The syntactic issues surrounding n+k are truely awful and I still have
to look at the report to remember what happens with these:

n+1 = 2
(n+1) = 2

A lot of people would have been happy to replace n+k by some view-like
mechanism that gives the user control over the meaning of n+k but we
never managed to get views into the report.
  
John
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: n + k patterns

2003-05-30 Thread Simon Peyton-Jones
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
|  fac (n + 1)   =  (n + 1) * fac n
| 
| the following type
| 
|   / _ \ /\  /\/ __(_)
|  / /_\// /_/ / /  | |  GHC Interactive, version 5.04.2, for
Haskell 98.
| / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
| \/\/ /_/\/|_|  Type :? for help.
| 
| Loading package base ... linking ... done.
| Loading package haskell98 ... linking ... done.
| Compiling Main ( Fac.lhs, interpreted )
| Ok, modules loaded: Main.
| *Main :t fac
| forall a. (Num a, Ord a) = a - a
| 
| The Report, however, states that
| 
|   3.17.2  Informal Semantics of Pattern Matching
|   ...
|   An n+k pattern can only be matched against a value in the class
Integral.
| 
| Cheers, Ralf
| 
| ___
| Glasgow-haskell-bugs mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


n + k patterns

2003-05-29 Thread Ralf Hinze
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/
\/\/ /_/\/|_|  Type :? for help.

Loading package base ... linking ... done.
Loading package haskell98 ... linking ... done.
Compiling Main ( Fac.lhs, interpreted )
Ok, modules loaded: Main.
*Main :t fac
forall a. (Num a, Ord a) = a - a

The Report, however, states that

3.17.2  Informal Semantics of Pattern Matching
...
An n+k pattern can only be matched against a value in the class Integral. 

Cheers, Ralf

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


RE: n+k patterns

2002-01-30 Thread Simon Peyton-Jones

| 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 report
* So we should think what the best answer is

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.

Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-30 Thread Malcolm Wallace

 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.

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, but Float and Double?  I'm not convinced that
would be useful.

f :: Double - Double
f (n+1) = n

Main print (f 3.0)
2.0
Main print (f 2.0001)
1.00010002
Main print (f 1.01)
1.00082740371e-10

Regards,
Malcolm

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: n+k patterns

2002-01-30 Thread Jon Fairbairn

  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.
 
 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, but Float and Double? 

I dimly remember that the justification for having n+k was
to allow inductive definitions, which only applies to
Integral. I'd vote for keeping it as it is, too.

  Jón




___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: n+k patterns

2002-01-30 Thread John Launchbury

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 on a chicken.

If anything, we should have restricted them to the very simplest case
covered in the early textbooks, i.e. just Int.

John

 | 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 report
 * So we should think what the best answer is
 
 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.
 
 Simon
 
 ___
 Haskell mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-30 Thread George Russell

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 that (x+1)=y.  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).

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-30 Thread Rijk J. C. van Haaften

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 change is non-de-stabilising on the rest of the report
* So we should think what the best answer is

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.

Personally I vote for keeping Integral. The strongest reason
for my choice is that if we want to be sure the pattern is
really correct, we need a bijection.
For Integral, we have + and - to form one, but we can't construct
one for Float and Double, though by this change they would be allowed
in the pattern.

Rijk-Jan van Haaften


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-30 Thread Simon Peyton-Jones

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 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 change is non-de-stabilising on the rest of the report
| * So we should think what the best answer is
| 
| 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.
| 
| Personally I vote for keeping Integral. The strongest reason 
| for my choice is that if we want to be sure the pattern is 
| really correct, we need a bijection. For Integral, we have + 
| and - to form one, but we can't construct one for Float and 
| Double, though by this change they would be allowed in the pattern.
| 
| Rijk-Jan van Haaften
| 
| 

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: n+k patterns

2002-01-30 Thread Lennart Augustsson

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 implementation teams didn't read the report. :-)

-- Lennart



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-30 Thread carlos . scheidegger

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, 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 be 
advisable in the case that Rational numbers were implemented 
explicitly with numerators and denominators).

Besides that, what about deprecating n+k patterns in future 
Haskell reports? :)

just my $0.02,
Carlos Eduardo Scheidegger


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: n+k patterns

2002-01-29 Thread Olaf Chitil


 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.

Btw., in 3.17.2  Informal Semantics of Pattern Matching
the end of the following sentence should be changed:

Matching a non-_|_ value x against a pattern of the form n+k (where n is
a variable and k is a positive integer literal) succeeds if x=k,
resulting in the binding of n to x-k, and fails if xk. 

There is no guarantee that if x=k == False then x  k == True.
So the sentence should end ..., and fails otherwise.

Olaf

-- 
OLAF CHITIL, 
 Dept. of Computer Science, The University of York, York YO10 5DD, UK. 
 URL: http://www.cs.york.ac.uk/~olaf/
 Tel: +44 1904 434756; Fax: +44 1904 432767

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-29 Thread Simon Peyton-Jones

| 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

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 
| cannot be a rational ... But then n+k patterns are a wart anyway.

Actually, you can only use integer 'k's.  

Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-29 Thread Mark P Jones

| 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 fromInteger), and indeed that's what GHC requires. 
|  Do Hugs or nhc actually require Integral?
| 
| Hugs demands Integral and the assumption that only one class is involved
| seems deeply entwined in the code.

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 I wouldn't have thought this was up for grabs.
(I'm thinking, for example, of the unnecessary same context
restriction on mutually recursive binding groups, which has more
practical impact, is very clearly a bug, and has not (AFAIK)
been fixed in Haskell 98.  Then there's David Wakeling's
generalized gap proposal, and ...)

All the best,
Mark


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: n+k patterns

2002-01-29 Thread Simon Peyton-Jones

| 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 I wouldn't have thought this was up for 
| grabs. (I'm thinking, for example, of the unnecessary same 
| context restriction on mutually recursive binding groups, 
| which has more practical impact, is very clearly a bug, and 
| has not (AFAIK) been fixed in Haskell 98.  Then there's David 
| Wakeling's generalized gap proposal, and ...)

That is a fair point, and is exactly the reason I bother the Haskell
list with
these proposals rather than simply executing them.   This is an unforced
change, as you point out, but in fact GHC and NHC currently do one
thing, and
Hugs does another (i.e. follows the spec!).  So some of us have to
change
our implementations. 

It clearly isn't a big deal, because no one has ever reported this
as a practical problem.

Other things being equal, it would be better to make the spec make 
as much sense as possible; hence my proposal.  But if it's really hard
to change Hugs, maybe we should leave the spec and change GHC and
nhc.   But you say it would be easy. 

I agree it's a moot point.  I lean towards making the change,
but I'm willing to be persuaded.

Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: n+k patterns

2002-01-29 Thread Lennart Augustsson

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 :).
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 strong.   All that is needed are Ord (for the = and
 -)
 and Num (for fromInteger), and indeed that's what GHC requires.
 Do Hugs or nhc actually require Integral?

 In any case,  I propose to change Integral to Ord and Num.

 Does anyone think this is the Wrong Thing?

 How this bug has lasted so long I don't know.

 Simon

 ___
 Haskell mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: n+k patterns

2002-01-29 Thread Lennart Augustsson

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 change
 | for Haskell 98, then I wouldn't have thought this was up for
 | grabs. (I'm thinking, for example, of the unnecessary same
 | context restriction on mutually recursive binding groups,
 | which has more practical impact, is very clearly a bug, and
 | has not (AFAIK) been fixed in Haskell 98.  Then there's David
 | Wakeling's generalized gap proposal, and ...)

 That is a fair point, and is exactly the reason I bother the Haskell
 list with
 these proposals rather than simply executing them.   This is an unforced
 change, as you point out, but in fact GHC and NHC currently do one
 thing, and
 Hugs does another (i.e. follows the spec!).  So some of us have to
 change
 our implementations.

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. :-)

-- Lennart



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Haskell 1.3 (n+k patterns)

1993-10-12 Thread John Launchbury


I feel the need to be inflamatory:

  I believe n+k should go.

There are lots of good reasons why they should go, of course. The question
is: are there any good reasons why they should stay? My understanding is
that the only reason they are advocated is that they make teaching
induction easier. 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 unlike the form of patterns they have become
used to they find all sorts of difficulties. What if n is negative. Ah yes,
well it can't be. Why not. It just can't. etc.

Let's throw them out.

John.





Re: Haskell 1.3 (n+k patterns)

1993-10-12 Thread Lennart Augustsson



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 think backwards compat is a problem.
Anyone who thinks this change will cause them more than 10
minutes work, plese speak up.

-- Lennart




Re: n+k patterns, etc.

1993-06-01 Thread hudak-paul


  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 the semantics of
  case expressions, are not macros. A simple replacement of the
  right-hand-side for the left-hand-side with substitution of parameters  
does
  not give the intended semantics. The reason for this is that the
  translations make use of certain names defined in the standard prelude  
(see
  section 5.4), and macro substitution could result in the capture of  
these
  names by locally defined entities, or the use of a name in a context in
  which it is not defined at all because the part of the prelude in which  
it
  is defined has not been imported. The general rule is: the use of a name
  defined in the standard prelude in a translation intended to show the
  semantics of a construct always implies the definition in the standard
  prelude.

  Then, people can locally rebind as much as they want, but the constructs
  defined by translation will be unaffected.
  

This sounds reasonable to me.  -Paul




Re: n+k patterns, etc.

1993-05-20 Thread Simon L Peyton Jones



|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 comprehensions etc.?  (Via some unseen and unhidable
| intermediary module.) Or are constructs that use hidden parts of the
| standard prelude (according to their translations given in the report)
| not available?

Yes.  No.  Respectively.

The Report is obviously not clear enough on this point. The wording given
for translations (eg list comprehensions) that "map" refers to the Prelude
"map" is meant to indicate that it refers to the Prelude "map" whether or
not the latter is explicitly in scope.  That's the consistent story for all
special syntax, to answer the latter part of your message.

Simon




Re: n+k patterns

1993-05-19 Thread marc



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 defined (or locally rebound) function.

If we keep this in mind there shouldn't
be any problem.


(Tell me if I'm wrong.)

Greetings,

Marc Rehmsmeier.





Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread kh


 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
var + int + pat

so I'd expect the answer to be 0.  glhc and gofer both agree with me.

Kevin





Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread hudak-paul


  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 left-hand-sides!
It should be as illegal as writing something like:

  f f = 1

Isn't that OBVIOUS??  (:-)

-Paul




Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread smk


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 "=".

Question:
Can one misuse the feature of n+k-patterns to simulate
n*k+k' patterns?  [I am talking about weird user-defined
instances of Num.]

Stefan Kahrs




Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread Joe Fasel


| 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 had them).

| One could leave it class Num, if the translation were expressed
| in terms of "signum" rather than "=".

Being able to match complex numbers (along the positive real axis only!)
with n+k patterns would be a dubious advantage, IMHO.

| Question:
| Can one misuse the feature of n+k-patterns to simulate
| n*k+k' patterns?  [I am talking about weird user-defined
| instances of Num.]

quite possibly.

| Stefan Kahrs

--Joe Fasel




Re: n+k patterns

1993-05-18 Thread kff



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




Re: n+k patterns

1993-05-18 Thread wadler


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


- Begin Included Message -

From [EMAIL PROTECTED] Tue May 18 14:56: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 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 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


- End Included Message -





Re: n+k patterns

1993-05-18 Thread Ken Sailor


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 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, and a wish for more flexible
syntax not hampered by special cases.

Ken





n+k patterns

1993-05-18 Thread rabin


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 program in
terms of SKI combinators!  Since these constructs have well-known,
unchanging meanings there is little chance that a program will be
misunderstood*.  I don't know about the rest of the people reading
this, but I find the notation S(S(S(KS)K))((S(S(KS)K))(KI)) =
(S(S(KS)K))(S(S(KS)K))(KI) to be much more precise than the n+k
equivalent, 1 + 1 = 2.  The similarity of the latter notation to the
informal numerals of everyday life is an open invitation to sloppy
reasoning leading to widespread program bugs.  Besides, anybody who
can't handle needless complexity shouldn't be fooling around with
dangerous machines such as computers.

  -- Dan Rabin ([EMAIL PROTECTED])

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 

*in fact, there is little chance that a program will be understood,
period.




Re: n+k patterns

1993-05-18 Thread wadler


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: 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 of { x+k - e; _ - e' }

translates to

if e0 = k then { let { x' = e0-k } in e[x'/x] else e'

Which = and - does this refer to?

What if they have been locally rebound?  E.g.

let x - y = x ++ f y
where f 0 = []
  f (n+1) = f n
in  [] - 0

Does the translated - still refer to the method in PreludeCore or
to the - in scope?

-- Lennart

PS. I'd like to start the "Ban n+k patterns"-movement, any followers?


- End Included Message -






Re: n+k patterns

1993-05-18 Thread Lennart Augustsson



 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 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




Re: n+k patterns

1993-05-18 Thread Joe Fasel


|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




n+k patterns

1993-05-17 Thread Lennart Augustsson


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 of { x+k - e; _ - e' }

translates to

if e0 = k then { let { x' = e0-k } in e[x'/x] else e'

Which = and - does this refer to?

What if they have been locally rebound?  E.g.

let x - y = x ++ f y
where f 0 = []
  f (n+1) = f n
in  [] - 0

Does the translated - still refer to the method in PreludeCore or
to the - in scope?

-- Lennart

PS. I'd like to start the "Ban n+k patterns"-movement, any followers?