Re: Successor patterns in bindings
Speaking of n+k patterns, did anyone ever answer this question? > Date: Wed, 14 Apr 1993 11:24:54 + > From: [EMAIL PROTECTED] > Subject: Successor patterns in bindings > To: Multiple recipients of list HASKLD-L <[EMAIL PROTECTED]> > > I'm puzzled by a bit of the Haskell 1.2 report on page 36; can > anyone clarify? > > The BNF and the supprting text seem to disagree. > > The BNF defines as a or a , where > cannot be a successor pattern. But can be a successor > pattern, since "+" is a . So a successor pattern can only > be parsed as a function binding, ie as a redefinition of "+". It > can never be parsed as a pattern binding. > > In the supporting text the sentence beginning, "Top level n+k > pattern bindings are explicitly disallowed" suggests that > successor pattern bindings _are_ allowed in contexts other > than the top level (ie in "where" or "let" constructs). Is this > the case? If so, how is the ambiguity resolved? Should the > sentence begin, "Successor pattern bindings are explicitly > disallowed?" > > -Norman Paterson The sentence Norman refers to is more precisely: "Top level n+k pattern bindings are explicitly disallowed; otherwise, programs such as x+2=3 could be parsed either as a definition of + or as a pattern binding." I think that Norman's suggested rewording is correct, but I suggest that it be further modifed to read: "n+k pattern bindings are explicitly disallowed; programs such as x+2=3 are parsed as a definition of +." Indeed, the Standard Prelude contains several such definitions in the instance declarations for the class Num. -Paul
Re: n+k patterns
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
> 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
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" PreludeCore. This is not sufficient to prevent rebinding, e.g. if somebody calls a formal parameter (>=). There is a related story w.r.t. the Definition of Standard ML. In its appendix, the SML report defines the meaning of some so-called "derived forms" in form of rewrite rules (e.g. it rewrites if-then-else into case-expressions and case-expressions into function application). These rewrite rules also use predefined identifiers (like true and false), which means that SML has exactly the same problems as Haskell. I took it for granted that the SML definition "meant" to refer to predefined identifiers, and all the standard implementations agreed on that. However, when I had an email-dispute with somebody who was involved in designing the SML definition about some of the problems relating to this, I was very surprised to find out that he was willing to understand the definitions literally and leave it to the user to modify the meaning of if-then-else by redefining true if s/he chooses to do so. I was even more surprised to hear from Dave Berry who works on Harlequin's SML compiler that their prototype indeed implemented these rules literally [well, almost: they did not get the "identifier status" bit right, a problem that does not exist in Haskell]; I am not sure whether their final release will still contain this feature, at least I discouraged them. Moral: do not take anything for granted, you can end up with somebody's implementation violating your hidden assumptions. -- Stefan Kahrs P.S. I join Lennart's "Ban n+k pattern"-movement.
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 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: More questions
> More questions along the same lines as for n+k: > > Does == in the pattern match translation refer to == in PreludeCore? > > Does negate in the translation of -e refer to negate in PreludeCore? All identifiers used in explicit translations refer to those from the Prelude. Kevin
Re: n+k patterns
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
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
Re: n+k patterns
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 look at the translations for expressions in Section 3 of the Report, you will see many instances of the phrase "as defined in the Standard Prelude". It was an oversight not to include such a phrase in the translation of patterns given in Section 3.14, the source of Lennart's original question. As for n+k patterns, I tried to get them out of Haskell on several occasions, even before the Report was released, but failed! Now that I've programmed in Haskell for a few years, I'm convinced more than ever that they should be removed. So add me to the movement! -Paul
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.
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
|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
