Re: Puzzling Case of Unreachable Code

I would guess because capitalized words are usually identifers, such as Objects or CONSTANTS, so it would be annoying to always have to use back quotes to keep them from being interpreted as "capturers" (whatever they're called). On the other hand, regular words default to capturing values maybe because that's a more common use of "words" in pattern matching. Why not let it depend on whether there is such an identifier? I would guess that they want code to be self explanatory, not dependent on "outside variables."It would be nice if the compiler would warn you that the capturing word is an existing identifier, though, I guess...

On Mon, Mar 23, 2009 at 5:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

2009/3/23 Naftoli Gugenheim <naftoligug@gmail.com>

The other use of back quotes is to refer to an identifier that is a Scala keyword, like Thread.yield. (JavaFX uses <<>> IIRC). So it forces a word to be interpreted as an identifier. Similarly, in pattern matching, lowercase is assumed to be a placeholder to capture a value, not to refer to an existing identifier, unless you tell the compiler that it is.

On Mon, Mar 23, 2009 at 5:21 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Can someone explain why this was chosen so? Where could it be useful, or necessary? I only see it till now as confusing. 

2009/3/23 Naftoli Gugenheim <naftoligug@gmail.com>

The alternative is to quote it with back quotes - `enter`.

On Mon, Mar 23, 2009 at 1:55 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday March 23 2009, Christian Szegedy wrote:
> You should capitalize enter, ahead and exit. Otherwise they are
> taken for a a variables, resulting in irrefutable match.
>
> ...

Really? Wow.

I started to ask about enumerated value names on #scala yesterday, but
then decided not to pester folks with another trifling question.

So... The leading alphabetic case of identifiers is actually significant
to the compiler? Shades of Prolog...


Randall Schulz

Jim, do you have an alternative proposal syntax for pattern matching?  How do you distinguish pattern variables from the rest of the pattern?


On Mon, Mar 23, 2009 at 2:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

Why not let it depend on whether there is such an identifier? I would guess that they want code to be self explanatory, not dependent on "outside variables."It would be nice if the compiler would warn you that the capturing word is an existing identifier, though, I guess...

Some(10) match { case Some(x) => println(x) }

Without this special treatment, Some(x) above would have to be a
normal call to Some.apply, so then it just wouldn't be an extractor
any more.

So that's why it's useful. It's not necessary, we could have
backticks for everything not treated as applicative. But I'd rather
read Scala than that.

2009/3/23 Jim Andreou :
> Sorry, I wasn't asking about the use of backquotes, but about the underlying
> issue. Why is it useful or necessary for the compiler to treat
> capitalization as significant? I see it makes the language more complicated,
> but I don't see what is gained instead, so I hope someone can provide a
> reasonable explanation.
>
> 2009/3/23 Naftoli Gugenheim
>>
>> The other use of back quotes is to refer to an identifier that is a Scala
>> keyword, like Thread.yield. (JavaFX uses <<>> IIRC). So it forces a word to
>> be interpreted as an identifier. Similarly, in pattern matching, lowercase
>> is assumed to be a placeholder to capture a value, not to refer to an
>> existing identifier, unless you tell the compiler that it is.
>>
>> On Mon, Mar 23, 2009 at 5:21 PM, Jim Andreou
>> wrote:
>>>
>>> Can someone explain why this was chosen so? Where could it be useful, or
>>> necessary? I only see it till now as confusing.
>>>
>>> 2009/3/23 Naftoli Gugenheim
>>>>
>>>> The alternative is to quote it with back quotes - `enter`.
>>>>
>>>> On Mon, Mar 23, 2009 at 1:55 PM, Randall R Schulz
>>>> wrote:
>>>>>
>>>>> On Monday March 23 2009, Christian Szegedy wrote:
>>>>> > You should capitalize enter, ahead and exit. Otherwise they are
>>>>> > taken for a a variables, resulting in irrefutable match.
>>>>> >
>>>>> > ...
>>>>>
>>>>> Really? Wow.
>>>>>
>>>>> I started to ask about enumerated value names on #scala yesterday, but
>>>>> then decided not to pester folks with another trifling question.
>>>>>
>>>>> So... The leading alphabetic case of identifiers is actually
>>>>> significant
>>>>> to the compiler? Shades of Prolog...
>>>>>
>>>>>
>>>>> Randall Schulz
>>>>
>>>
>>
>
>

What do you think of a warning for an extractor shadowing an identifier?

On Mon, Mar 23, 2009 at 6:09 PM, James Iry <jamesiry@gmail.com> wrote:

Ouch!

val myVariable : Whatever = something()
....lots of code

x match {
  case Some(myVraiable) => "it matched"
  case _ => "no match"
}

notice the misspelling still compiles but with totally different semantics from intended

On Mon, Mar 23, 2009 at 3:00 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

From the top of my head, since the user can easily pick a new pattern variable name (only local changes needed), how about always let such variables be shadowed by outer variable definitions? (As a bonus, no particular syntax would be needed). Changing the outer variable  should be more difficult, since it would typically be used in a wider scope. 

2009/3/23 James Iry <jamesiry@gmail.com>

Jim, do you have an alternative proposal syntax for pattern matching?  How do you distinguish pattern variables from the rest of the pattern?


On Mon, Mar 23, 2009 at 2:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

No because then it's an error if it doesn't exist.

On Mon, Mar 23, 2009 at 6:14 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Isn't this problem already possible with the capitalized variable names?

2009/3/24 James Iry <jamesiry@gmail.com>

Ouch!

val myVariable : Whatever = something()
....lots of code

x match {
  case Some(myVraiable) => "it matched"
  case _ => "no match"
}

notice the misspelling still compiles but with totally different semantics from intended

On Mon, Mar 23, 2009 at 3:00 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

From the top of my head, since the user can easily pick a new pattern variable name (only local changes needed), how about always let such variables be shadowed by outer variable definitions? (As a bonus, no particular syntax would be needed). Changing the outer variable  should be more difficult, since it would typically be used in a wider scope. 

2009/3/23 James Iry <jamesiry@gmail.com>

Jim, do you have an alternative proposal syntax for pattern matching?  How do you distinguish pattern variables from the rest of the pattern?


On Mon, Mar 23, 2009 at 2:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

Ouch!

val myVariable : Whatever = something()
....lots of code

x match {
  case Some(myVraiable) => "it matched"
  case _ => "no match"
}

notice the misspelling still compiles but with totally different semantics from intended

On Mon, Mar 23, 2009 at 3:00 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

From the top of my head, since the user can easily pick a new pattern variable name (only local changes needed), how about always let such variables be shadowed by outer variable definitions? (As a bonus, no particular syntax would be needed). Changing the outer variable  should be more difficult, since it would typically be used in a wider scope. 

2009/3/23 James Iry <jamesiry@gmail.com>

Jim, do you have an alternative proposal syntax for pattern matching?  How do you distinguish pattern variables from the rest of the pattern?


On Mon, Mar 23, 2009 at 2:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

From the top of my head, since the user can easily pick a new pattern variable name (only local changes needed), how about always let such variables be shadowed by outer variable definitions? (As a bonus, no particular syntax would be needed). Changing the outer variable  should be more difficult, since it would typically be used in a wider scope. 

2009/3/23 James Iry <jamesiry@gmail.com>

Jim, do you have an alternative proposal syntax for pattern matching?  How do you distinguish pattern variables from the rest of the pattern?


On Mon, Mar 23, 2009 at 2:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

Isn't this problem already possible with the capitalized variable names?

2009/3/24 James Iry <jamesiry@gmail.com>

Ouch!

val myVariable : Whatever = something()
....lots of code

x match {
  case Some(myVraiable) => "it matched"
  case _ => "no match"
}

notice the misspelling still compiles but with totally different semantics from intended

On Mon, Mar 23, 2009 at 3:00 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

From the top of my head, since the user can easily pick a new pattern variable name (only local changes needed), how about always let such variables be shadowed by outer variable definitions? (As a bonus, no particular syntax would be needed). Changing the outer variable  should be more difficult, since it would typically be used in a wider scope. 

2009/3/23 James Iry <jamesiry@gmail.com>

Jim, do you have an alternative proposal syntax for pattern matching?  How do you distinguish pattern variables from the rest of the pattern?


On Mon, Mar 23, 2009 at 2:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

No, it's not an unreasonable observation. I even agree with you - this one bit of case sensitivity is not in keeping with the rest of the language.  The point is that it's hard to have a good solution.  For instance, another way that would fit in with the language is is to use "val" when you want to bind.

case Some(x) => // matches against x
case Some(val x) => // makes a new variable named x

But that solution creates verbosity.

On Mon, Mar 23, 2009 at 3:38 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

In any case, my point is that the capitalization solution is confusing. Is that too unreasonable an observation? Now we have to be careful when we pick variable names, thinking whether that they might be used in pattern matching and whether we might cause problems.

val Oops = new Object
var v: Option[AnyRef] = ...;...v = Some(new Object).....lots of code

v match {    case Some(oops) => println("Great! I found Some(Oops)! Now I can launch the rocket! ")     case _ => println("Nah, it was something else, don't bother")}
I wanted to match Some(Oops), but I made a typo and matched something irrelevant.
In any case, my point is that the capitalization solution is confusing. Is that too unreasonable an observation? Now we have to be careful when we pick variable names, thinking whether that they might be used in pattern matching and whether we might cause problems.
2009/3/24 Naftoli Gugenheim <naftoligug@gmail.com>

No because then it's an error if it doesn't exist.

On Mon, Mar 23, 2009 at 6:14 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Isn't this problem already possible with the capitalized variable names?

2009/3/24 James Iry <jamesiry@gmail.com>

Ouch!

val myVariable : Whatever = something()
....lots of code

x match {
  case Some(myVraiable) => "it matched"
  case _ => "no match"
}

notice the misspelling still compiles but with totally different semantics from intended

On Mon, Mar 23, 2009 at 3:00 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

From the top of my head, since the user can easily pick a new pattern variable name (only local changes needed), how about always let such variables be shadowed by outer variable definitions? (As a bonus, no particular syntax would be needed). Changing the outer variable  should be more difficult, since it would typically be used in a wider scope. 

2009/3/23 James Iry <jamesiry@gmail.com>

Jim, do you have an alternative proposal syntax for pattern matching?  How do you distinguish pattern variables from the rest of the pattern?


On Mon, Mar 23, 2009 at 2:32 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sorry, I wasn't asking about the use of backquotes, but about the underlying issue. Why is it useful or necessary for the compiler to treat capitalization as significant? I see it makes the language more complicated, but I don't see what is gained instead, so I hope someone can provide a reasonable explanation.

2009/3/23 James Iry :
> No, it's not an unreasonable observation. I even agree with you - this one
> bit of case sensitivity is not in keeping with the rest of the language.
> The point is that it's hard to have a good solution.  For instance, another
> way that would fit in with the language is is to use "val" when you want to
> bind.
>
> case Some(x) => // matches against x
> case Some(val x) => // makes a new variable named x
>
> But that solution creates verbosity.

Hm.

I actually rather like this solution. It's probably far past too late
for it though.

Oh the verbosity!!!!!


Actually, I also think it's a neato solution.  However, does it fit with the whole   val Some(x) = y   pattern match scenario?  Or would that become Some(val x) = y, so tuples extraction is ....   (val x, val y) = func()

Meh!   Too much worms in the can for me.

On Mon, Mar 23, 2009 at 7:06 PM, David MacIver <david.maciver@gmail.com> wrote:

2009/3/23 James Iry <jamesiry@gmail.com>:
> No, it's not an unreasonable observation. I even agree with you - this one
> bit of case sensitivity is not in keeping with the rest of the language.
> The point is that it's hard to have a good solution.  For instance, another
> way that would fit in with the language is is to use "val" when you want to
> bind.
>
> case Some(x) => // matches against x
> case Some(val x) => // makes a new variable named x
>
> But that solution creates verbosity.

Hm.

I actually rather like this solution. It's probably far past too late
for it though.

James Iry wrote:
> No, it's not an unreasonable observation. I even agree with you - this
> one bit of case sensitivity is not in keeping with the rest of the
> language. The point is that it's hard to have a good solution. For
> instance, another way that would fit in with the language is is to use
> "val" when you want to bind.

Well, we did get rid of val's in for loops, which I never understood the
reasoning for:

was: for (val i <- 1 to 10)
now: for (i <- 1 to 10)

So using consistency with the rest of the language doesn't appear to be too
strong of an argument.

Blair

On Mon, Mar 23, 2009 at 11:45 PM, James Iry wrote:
> case Some(x) => // matches against x
> case Some(val x) => // makes a new variable named x

I like the val version, seems consistent. Principle of least surprice,
val declares a bound value)

But just to throw some ideas around

I guess the following is valid right now. no?

case Some(x @ _) =>

maybe something like

case Some(@x) => // Reuse the @ to signify binding. I think it's to
heavy (at least in the font I'm using to write this)
case Some(_x) => // Instead of case senditivity use _ with an appended tax
case Some({x}) // Seems natural for some reason
case Some(`x`) //The reverse of the current usage of ` ?

BR,
John

Isn't the easiest and most natural solution to give a compiler error when something is shadowed, and if demanded by the public, add an @Shadow annotation that allows the shadowing to occur?

On Wed, Mar 25, 2009 at 8:41 PM, John Nilsson <john@milsson.nu> wrote:

On Mon, Mar 23, 2009 at 11:45 PM, James Iry <jamesiry@gmail.com> wrote:
> case Some(x) => // matches against x
> case Some(val x) => // makes a new variable named x

I like the val version, seems consistent. Principle of least surprice,
val declares a bound value)

But just to throw some ideas around

I guess the following is valid right now. no?

case Some(x @ _) =>

maybe something like

case Some(@x)  => // Reuse the @ to signify binding. I think it's to
heavy (at least in the font I'm using to write this)
case Some(_x) => // Instead of case senditivity use _ with an appended tax
case Some({x}) // Seems natural for some reason
case Some(`x`) //The reverse of the current usage of ` ?

BR,
John

--
Viktor Klang
Senior Systems Analyst

On 25 Mar 2009, at 19:53, Viktor Klang wrote:

> Isn't the easiest and most natural solution to give a compiler error
> when something is shadowed, and if demanded by the public, add an
> @Shadow annotation that allows the shadowing to occur?

That sounds thoroughly ideal to me. The shadowing is a bit of a trap
for the unwary, and it's caught me once or twice.

And I do it all the time and don't want my code to sprout ugly @Shadow annotations.
2009/3/27 Andrew Forrest <andrew@dysphoria.net>

On 25 Mar 2009, at 19:53, Viktor Klang wrote:

Isn't the easiest and most natural solution to give a compiler error when something is shadowed, and if demanded by the public, add an @Shadow annotation that allows the shadowing to occur?

That sounds thoroughly ideal to me. The shadowing is a bit of a trap for the unwary, and it's caught me once or twice.

On Tue, Mar 24, 2009 at 12:45 AM, James Iry wrote:
> No, it's not an unreasonable observation. I even agree with you - this one
> bit of case sensitivity is not in keeping with the rest of the language.
> The point is that it's hard to have a good solution.  For instance, another
> way that would fit in with the language is is to use "val" when you want to
> bind.
>
> case Some(x) => // matches against x
> case Some(val x) => // makes a new variable named x
>
> But that solution creates verbosity.
>
Yes, and it violates a design principle of pattern matching: patterns
and expressions should look alike. That principle does not hold a 100%
(for instance, @ bindings in patterns don't have analogues for
expressions), but it';s nevertheless useful.

I agree it's a tradeoff. We chose one side of it, and it certainly too
late to change.

Cheers