I think the usefulness of numeric / string literals as pattern matches is as part of larger matches (as someone mentioned), not by itself. But since (I assume) these things are defined recursively, it makes sense just to add it as a base-level pattern match. Furthermore, you would not want ``` main = let 1 = 2 in print "foo" ``` to error, since the pattern match is unused, and haskell is a lazy language. Really, though, we probably shouldn't be putting incomplete pattern matches in our code :P --Taeer

Furthermore, you would not want ``` main = let 1 = 2 in print "foo" ``` to error, since the pattern match is unused, and haskell is a lazy language.

That's not at all clear. In fact, I believe this thread exists because the OP's daughter expected that it WOULD raise an error. For what it's worth, Start = let 1 = 2 in "hello" is rejected by the Clean compiler, even though Clean is much like Haskell, and 1 is otherwise allowed as a pattern. If nothing else, it would be nice to have a "dead code" warning from the compiler about code that is certain not to be evaluated. "2" counts as dead code in this example.

On Monday, February 27, 2017 at 12:35:26 AM UTC+1, o...@cs.otago.ac.nz wrote:

...

Furthermore, you would not want ``` main = let 1 = 2 in print "foo" ``` to error, since the pattern match is unused, and haskell is a lazy language.

That's not at all clear. In fact, I believe this thread exists because the OP's daughter expected that it WOULD raise an error.

I think i agree with this. IMO it should raise an error as well as (\1 -> "hello") 2 does. Alexey.

Can be added to Nitpicks then :) : https://wiki.haskell.org/Nitpicks Alexey. On Sunday, February 26, 2017 at 12:25:17 AM UTC+1, David Feuer wrote:

I firmly believe that making pattern matches in let and where clauses lazy by default was a mistake in the Haskell Report. It's inconsistent with how pattern matching works elsewhere in the language, and also makes a strange distinction between outer and inner pattern matches. Unfortunately, it's way too late to fix that mistake.

On Feb 24, 2017 12:09 AM, "Harendra Kumar" javascript:> wrote:

...

CCing the list. I guess you intended to cc but forgot.

On 24 February 2017 at 09:27, javascript:> wrote:

...

In Erlang, the equivalent of a let fails. 1> 1=2. ** exception error: no match of right hand side value 2

In SML, the equivalent of a let fails. - val 1 = 1; - val 1 = 2;

uncaught exception Bind [nonexhaustive binding failure] raised at: stdIn:2.5-2.10

The problem is not that let 1 = 2 ... is *legal* but that - the compiler is *silent* about it - the runtime is *silent* about it. Compiling the little program

main = let 1 = 2 in print "hi"

I expected that the compiler would be silent but that there would be some sort of "matched failed" error at run time. Silly me.

The thing is, it is not just bindings that bind no variables that act as if they were not there.

main = let [x] = [1,2] in print "hi"

also compiles silently and runs without error. Change it to

main = let [x] = [1,2] in print ("hi" ++ show x)

and you get a runtime error

<object>: <source>: Irrefutable pattern failed for pattern [x].

I wish the compiler would report an error something like

"<location>: possibly failing match deleted because it binds no live variables"

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Yes, lazy patterns are useful. That's what we have the ~ syntax for! You can always write where ~(a, b) = .... or whatever. I think a bang is good for a strict non-pattern binding, like where !a = .... because that's the unusual case, but I think it's bad for a strict pattern binding, which is the *usual* case. On Sat, Feb 25, 2017 at 10:28 PM, Ivan Lazar Miljenovic wrote:

On 26 February 2017 at 10:23, David Feuer wrote:

...

I firmly believe that making pattern matches in let and where clauses lazy by default was a mistake in the Haskell Report. It's inconsistent with how pattern matching works elsewhere in the language, and also makes a strange distinction between outer and inner pattern matches. Unfortunately, it's way too late to fix that mistake.

I've used that though in combination of guards where I call the (lazily evaluated) result only in cases where it's irrefutable.

...

On Feb 24, 2017 12:09 AM, "Harendra Kumar" wrote:

...

CCing the list. I guess you intended to cc but forgot.

On 24 February 2017 at 09:27, wrote:

...

In Erlang, the equivalent of a let fails. 1> 1=2. ** exception error: no match of right hand side value 2

In SML, the equivalent of a let fails. - val 1 = 1; - val 1 = 2;

uncaught exception Bind [nonexhaustive binding failure] raised at: stdIn:2.5-2.10

The problem is not that let 1 = 2 ... is *legal* but that - the compiler is *silent* about it - the runtime is *silent* about it. Compiling the little program

main = let 1 = 2 in print "hi"

I expected that the compiler would be silent but that there would be some sort of "matched failed" error at run time. Silly me.

The thing is, it is not just bindings that bind no variables that act as if they were not there.

main = let [x] = [1,2] in print "hi"

also compiles silently and runs without error. Change it to

main = let [x] = [1,2] in print ("hi" ++ show x)

and you get a runtime error

<object>: <source>: Irrefutable pattern failed for pattern [x].

I wish the compiler would report an error something like

"<location>: possibly failing match deleted because it binds no live variables"

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com