Re: [Haskell-cafe] Very Small Program
Hello Jason,
Thursday, November 2, 2006, 8:45:14 AM, you wrote:
let 0 = 1 in 0
let { 1 + 1 = 3; 3 + 1 = 7 } in 1 + 1 + 1
Where you get 7.
these sippets looks cool :) they may be placed in somewhat like
Haskell puzzles
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Very Small Program
G'day all. Quoting Bernie Pope [EMAIL PROTECTED]: This is a weird example of a pattern binding, and it is surprising (to me) that the syntax is valid. Maybe. But you wouldn't balk at this: numzeroes xs = sum [ 1 | 0 - xs ] ...even if you wouldn't naturally express it that way. Patterns like this are useful in places other than lets. I'd find it more surprising if lets were treated as a special case. In this case you are defining the function which is bound to the variable called +. Though thanks to n+k patterns, this is well-understood to be a confusing and controversial case. One would normally expect to see at least one variable inside the pattern on the left-hand-side of a pattern binding (otherwise what point would there be to the definition?). If the pattern is demanded (as it may well be in a list comprehension generator, do block generator or a lambda), then it can be very useful. The programmer is asking for an error/empty list/monad fail if the conformality check fails. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Very Small Program
On 11/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: G'day all. Quoting Bernie Pope [EMAIL PROTECTED]: This is a weird example of a pattern binding, and it is surprising (to me) that the syntax is valid. Maybe. But you wouldn't balk at this: numzeroes xs = sum [ 1 | 0 - xs ] ...even if you wouldn't naturally express it that way. Patterns like this are useful in places other than lets. I'd find it more surprising if lets were treated as a special case. Actually, I had to try it out to see if it would work. That's a neat little trick. I had known that this similar one worked but it uses pattern matching on a data constructor so I never questioned it: numJusts xs = sum [ 1 | Just x - xs ] thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Very Small Program
On 02/11/2006, at 9:56 PM, [EMAIL PROTECTED] wrote: G'day all. Quoting Bernie Pope [EMAIL PROTECTED]: This is a weird example of a pattern binding, and it is surprising (to me) that the syntax is valid. Maybe. But you wouldn't balk at this: numzeroes xs = sum [ 1 | 0 - xs ] ...even if you wouldn't naturally express it that way. Patterns like this are useful in places other than lets. I'd find it more surprising if lets were treated as a special case. In this case you are defining the function which is bound to the variable called +. Though thanks to n+k patterns, this is well-understood to be a confusing and controversial case. One would normally expect to see at least one variable inside the pattern on the left-hand-side of a pattern binding (otherwise what point would there be to the definition?). If the pattern is demanded (as it may well be in a list comprehension generator, do block generator or a lambda), then it can be very useful. The programmer is asking for an error/empty list/monad fail if the conformality check fails. I agree with what you say. When I said pattern binding, I was using the terminology of the Haskell Report, which means only declarations of the form pat = exp. Generator statements and lambdas are a different story, as you rightly point out. Nonetheless, I still believe that it is surprising for pattern bindings that this syntax is allowed, since there doesn't seem to be any purpose to them. (A cursory glance at the Report suggests that this kind of pattern binding is allowed). Then again, since the bindings are benign, maybe one could argue that it is better to have one less rule in the language definition? Then again, such a declaration could be the sign of a buggy program, and it might be better to give a compile time error. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Very Small Program
Hello,
I just found it (in ghci and hugs) that this is a valid haskell program:
let 0 = 1 in 0
This program evaluates to 0 (to my surprise).
I expected something similar to how this works:
let { 1 + 1 = 3; 3 + 1 = 7 } in 1 + 1 + 1
Where you get 7.
So, if the 0 is not used as an identifier (ie, defining a function or
name of a value), then why doesn't this count as a parse error? And,
why didn't I get to locally redefine it?
Thanks,
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Very Small Program
On 02/11/2006, at 4:45 PM, Jason Dagit wrote:
Hello,
I just found it (in ghci and hugs) that this is a valid haskell
program:
let 0 = 1 in 0
This program evaluates to 0 (to my surprise).
This is a weird example of a pattern binding, and it is surprising
(to me) that the syntax is valid.
Because there are no variables on the left-hand-side of the equation,
the definition is much the same as:
let _ = 1 in 0
The definition that you give suggests that we evaluate the expression
1, then compare it
to 0, and then do nothing with the result of the comparison
(because it doesn't bind
any variables). Though it is weird, it is rather benign, since
pattern bindings are
evaluated lazily, and in this case never.
I expected something similar to how this works:
let { 1 + 1 = 3; 3 + 1 = 7 } in 1 + 1 + 1
Where you get 7.
In this case you are defining the function which is bound to the
variable called +.
So, if the 0 is not used as an identifier (ie, defining a function or
name of a value), then why doesn't this count as a parse error? And,
why didn't I get to locally redefine it?
In the first case the definition is pattern matching against 0, and
in the second case
the definition is giving the meaning of a variable.
While numerical constants are a little bit special in Haskell (they
are overloaded),
they act much like regular data constructors. When they appear inside
a pattern,
you are matching against them, rather than re-defining them.
One would normally expect to see at least one variable inside the
pattern on the
left-hand-side of a pattern binding (otherwise what point would there
be to the
definition?). It may very well be the case that the syntax for
Haskell in the Report
requires this, but I haven't bothered to check it up. If the Report
does require at least
one variable in the pattern, it may be the case that hugs and ghc are
using a slightly
more liberal interpretation of the grammar. Or it could be the case
that the Haskell
Report does in fact allow such pointless, but benign pattern bindings.
Perhaps you could chase this up and see what the Report really does
require?
Cheers,
Bernie.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
