Re: Cannot use methods that named as +, -, ~, !

On Wed, Oct 26, 2011 at 9:23 AM, Alex Repain
> I won't disagree with this, but you have to admit that this priority choice
> in the Scala grammar is disputable, because strongly misleading. Besides, I
> don't see why Scala couldn't try first a this.$op(...) syntax and fail on it
> before resolving it as a method call on the argument. What harm could that
> do (let's keep aside breaking all existing Scala code) ?

I would say no longer knowing how any given piece of scala code parses
is objectively harmful. And that is leaving aside breaking all
existing scala code ("other than that mrs. lincoln, how was the
play?") Let's not even think about what this would mean for IDE
developers.

On 2011-10-26 18:10, Paul Phillips wrote:
> On Wed, Oct 26, 2011 at 8:57 AM, Eugen Labun wrote:
>> Actually I'm not shure, that this behevior (unconditional treatment of some characters as prefix
>> operators) is really intended (therefore, asking here). At least, cannot find this in SLS.
>
> It's implied by the grammar. This production:
>
> PrefixExpr ::= [‘-’ | ‘+’ | ‘~’ | ‘!’] SimpleExpr
>
> Is considered before
>
> SimpleExpr1 ArgumentExprs
>
> which means -(x) is parsed as -x and will never be considered for
> this.-(x). It is generally considered a bad idea, with good reason I
> think, to incorporate this kind of not-yet-available semantic
> information into parsing (i.e. "if there's no unary_- in the operand,
> go looking for a - method on "this".)
>

OK, the grammar would justify the behevior of the parser. (But to be honest, the Scala parser
doesn't strictly follow this grammar. And the grammar doesn't specify some situation, like if '-' is
a part of numerical literal...)

Anyway, a context-sensitive parsing could help us a lot. Only some advantages:

- right relative precedences for prefix/infix/postfix operators (highest: postfix, then prefix, then
infix) would allow much more expressive DSLs (imagine all arts of units: 5min, 30°, 45kg, ...)

- robust semicolon inference in the presence of a postfix operator.

Paul, if you would want to implement that, where would you change what?
Particularly, on which compiler phase is the required info available?

(C++ people do something similar too. Consider: "foo (bar);" This could be a (strange) variable
declaration, where foo is a typename. Or it could be a method call, where foo is an identifier. How
do they implement their compilers? Refine the AST at a later compiler phase?)

I meant, that units would be possible in expressions, like: 5min + 20min, 30° - 5°, etc.

On Wed, Oct 26, 2011 at 9:43 AM, Eugen Labun wrote:
> OK, the grammar would justify the behevior of the parser. (But to be honest, the Scala parser
> doesn't strictly follow this grammar.

Yes, there are bugs (in both the grammar and the parser) which is
tangential to the question.

> And the grammar doesn't specify some situation like if '-' is
> a part of numerical literal...)

And that one little corner has created multiple tickets and there is a
huge chunk of code (huge relative to the percentage of the parsing
space it addresses) for that one thing. It's a fine example of why
not to do something like this.

> Paul, if you would want to implement that, where would you change what?
> Particularly, on which compiler phase is the required info available?

That depends on what you want to work. You can't know with much
confidence what members a class has until after typer. To have
parsing itself depend on that information, when everything which
happens after parsing depends on the parse, means you create a strong
cyclic dependency among compiler phases. I can imagine it being
workable in practice, but it is a lot of complexity and I don't even
begin to entertain the idea of introducing more complexity in these
areas of the compiler. Anyone who wants to had better show some
willingness and ability to get their hands dirty. (That's rhetorical
in this case, I can't imagine this happening regardless.)

> (C++ people do something similar too. Consider: "foo (bar);" This could be a (strange) variable
> declaration, where foo is a typename. Or it could be a method call, where foo is an identifier. How
> do they implement their compilers?

They probably commit offenses against decency which must be repented
at length. It's not impossible, it's just undesirable.

I see, it's not realistic to change the actual compiler.
But perhaps, this behevior should still be explicitly documented in SLS.

On 2011-10-26 19:20, Paul Phillips wrote:
> On Wed, Oct 26, 2011 at 9:43 AM, Eugen Labun wrote:
>> OK, the grammar would justify the behevior of the parser. (But to be honest, the Scala parser
>> doesn't strictly follow this grammar.
>
> Yes, there are bugs (in both the grammar and the parser) which is
> tangential to the question.
>
>> And the grammar doesn't specify some situation like if '-' is
>> a part of numerical literal...)
>
> And that one little corner has created multiple tickets and there is a
> huge chunk of code (huge relative to the percentage of the parsing
> space it addresses) for that one thing. It's a fine example of why
> not to do something like this.
>
>> Paul, if you would want to implement that, where would you change what?
>> Particularly, on which compiler phase is the required info available?
>
> That depends on what you want to work. You can't know with much
> confidence what members a class has until after typer. To have
> parsing itself depend on that information, when everything which
> happens after parsing depends on the parse, means you create a strong
> cyclic dependency among compiler phases. I can imagine it being
> workable in practice, but it is a lot of complexity and I don't even
> begin to entertain the idea of introducing more complexity in these
> areas of the compiler. Anyone who wants to had better show some
> willingness and ability to get their hands dirty. (That's rhetorical
> in this case, I can't imagine this happening regardless.)

Who knows, perhaps one day I'll come with an implementation proposal.

>> (C++ people do something similar too. Consider: "foo (bar);" This could be a (strange) variable
>> declaration, where foo is a typename. Or it could be a method call, where foo is an identifier. How
>> do they implement their compilers?
>
> They probably commit offenses against decency which must be repented
> at length.

For what I love this forum, is for humor and for learning english language to the same extent as
Scala language :)

Has anyone considered making it illegal to define unary functions called + - ! or ~? I mean, if you can't call them, then it seems a bit cruel to be able to define them.

On Wed, Oct 26, 2011 at 12:09 PM, Cay Horstmann wrote:
> Has anyone considered making it illegal to define unary functions called + -
> ! or ~? I mean, if you can't call them, then it seems a bit cruel to be able
> to define them.

You can call them.

this.-(5)

You just can't call them with syntax which looks like a prefix operator.

On Wed, Oct 26, 2011 at 12:10 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Oct 26, 2011 at 12:09 PM, Cay Horstmann <cay.horstmann@gmail.com> wrote:
> Has anyone considered making it illegal to define unary functions called + -
> ! or ~? I mean, if you can't call them, then it seems a bit cruel to be able
> to define them.

You can call them.

Why, so can I, and so can any other man! But will they come when you do call for them?
 

this.-(5)

Not from the vasty REPL.

scala> def ~(s: String) = s.reverse
$tilde: (s: String)String

scala> this.~("Harry")
<console>:8: error: value ~ is not a member of object $iw
              this.~("Harry")
                   ^
scala> $iw.~("Harry")
<console>:8: error: value ~ is not a member of object $iw
              ~("Harry")
                  ^

On Wed, Oct 26, 2011 at 1:52 PM, Cay Horstmann wrote:
> Not from the vasty REPL.

That's a repl artifact, as it often is.

scala> class Foo { def ~(s: String) = s.reverse ; def g = this.~("Harry") }
defined class Foo

scala> new Foo g
res0: String = yrraH

2011/10/26 Paul Phillips <paulp@improving.org>

On Wed, Oct 26, 2011 at 9:23 AM, Alex Repain
> I won't disagree with this, but you have to admit that this priority choice
> in the Scala grammar is disputable, because strongly misleading. Besides, I
> don't see why Scala couldn't try first a this.$op(...) syntax and fail on it
> before resolving it as a method call on the argument. What harm could that
> do (let's keep aside breaking all existing Scala code) ?

I would say no longer knowing how any given piece of scala code parses
is objectively harmful.  And that is leaving aside breaking all
existing scala code ("other than that mrs. lincoln, how was the
play?") Let's not even think about what this would mean for IDE
developers

Sorry if I sound retarded, maybe I'm missing something big, but how is the solution I suggested, preventing us from knowing the behaviour of the code ? I would say this is the opposite. I know what I'm defining in my class/object/... better than the API classes/objects/... I'm using, so treating the prefix operators like they are method calls on this seems for me the very natural way, before thinking that maybe it's a prefix operator of the type I'm using... And even if this doesn't feel natural to some, I don't see what informations we would be missing to predict the code behaviour...

Apart from that, I totally understand that changing the compiler code for such a matter is irrelevant, not-needed and undesirable, but this behaviour is really an oddity to me.



--
Alex REPAIN
ENSEIRB-MATMECA - student
TECHNICOLOR R&D - intern
BORDEAUX I      - master's student
SCALA           - enthusiast

It's yet another special case that seems convenient but adds complexity without much benefit. Just stay away from ! + - ~ as functions or methods. They are, for historical reasons, unary prefix operators, and there is no point in messing with them.

On Wed, Oct 26, 2011 at 3:07 PM, Alex Repain <alex.repain@gmail.com> wrote:

Sorry if I sound retarded, maybe I'm missing something big, but how is the solution I suggested, preventing us from knowing the behaviour of the code ? I would say this is the opposite. I know what I'm defining in my class/object/... better than the API classes/objects/... I'm using, so treating the prefix operators like they are method calls on this seems for me the very natural way, before thinking that maybe it's a prefix operator of the type I'm using... And even if this doesn't feel natural to some, I don't see what informations we would be missing to predict the code behaviour...

Apart from that, I totally understand that changing the compiler code for such a matter is irrelevant, not-needed and undesirable, but this behaviour is really an oddity to me.



--
Alex REPAIN
ENSEIRB-MATMECA - student
TECHNICOLOR R&D - intern
BORDEAUX I      - master's student
SCALA           - enthusiast