type inference in subclasses / skipping parameter names

[Dennis Haupt]

in short, why do i have to write

trait X {def y(s:String,i:Int)}

instead of trait X {def y(String,Int)}
?

the implementation will name the arguments anyway, so why do i need names in the abstract method at all? sure, sometimes i want to name them as documentation - but sometimes, the purpose of a parameter is totally obvious because of its type or irrelevant. for example: class sequence {def sorted(comparator:Comparator)}. it is sufficient to specify that i need a comparator. it does not need a name.

and the other way round:

why should i have to specify the types *again* when implementing the trait if i don't want to change it? if the trait says "here, a string is passed", then why should i have to write "that is a string" again? the information can be inferred unless also i want to accept a more general type. in most cases i won't, so this should be possible:

trait Sequence { def sortedWith(Comparator):Sequence}

class SequenceImpl {def sortedWith(comparator) = .... }

did i miss something, or did simply nobody think of that?

[Mirko Stocker]

On Friday 31 August 2012 16:41:06 Dennis Haupt wrote:
> in short, why do i have to write
>
> trait X {def y(s:String,i:Int)}
>
> instead of trait X {def y(String,Int)}
> ?
>
> the implementation will name the arguments anyway, so why do i need names in
> the abstract method at all? sure, sometimes i want to name them as
> documentation -

Don't forget calls with named arguments..

Cheers,

Mirko

[Paul Phillips]

On Fri, Aug 31, 2012 at 7:41 AM, Dennis Haupt <h-s...@gmx.de> wrote:

did i miss something, or did simply nobody think of that?

The second item has been present since 2.8.1:

% scala3 -Yinfer-argument-types

Welcome to Scala version 2.11.0-20120828-084442-c5d1cf0915 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_33).

Type in expressions to have them evaluated.

Type :help for more information.

scala> trait Foo { def f(x: Ordering[Int], y: Seq[Int]): Int }

defined trait Foo

scala> object Bar extends Foo { def f(x, y) = y sorted x head }

defined module Bar

 

[Daniel Sobral]

Err... what???? WTF! And I only get to find out about this NOW!??!?!?!
Oh, man, I'll be doing some refactoring today... I wonder if
IntelliJ's parser will complain about it. :-)


--
Daniel C. Sobral

I travel to the future all the time.

[Patrik Andersson]

Where's the ballot for paulp for president?

[Daniel Sobral]

Oh, it's behind an -Y. Ah, well.

[Daniel Sobral]

On Fri, Aug 31, 2012 at 1:24 PM, Patrik Andersson <pande...@gmail.com> wrote:
> Where's the ballot for paulp for president?

*I'm* not voting for him! What time would he have to hack on Scala if elected?

[Eugene Burmako]

Yeah I've got exactly the same reaction :)

[Som Snytt]

For the record, they don't allow just any crazy idea in under -Y (as I learned the hard way).

But here's a quote from another -Y commit message:

Another exciting development in the world of -Y options which I and
three other people will use.

[Josh Suereth]

Any chance we can unleash this, or is it behind -Y because it's flaky in some way?

[Daniel Sobral]

On Fri, Aug 31, 2012 at 5:30 PM, Josh Suereth <joshua....@gmail.com> wrote:
> Any chance we can unleash this, or is it behind -Y because it's flaky in
> some way?

Well... it's non-spec'ed, right? It would be a major clean-up in the
project I have right now, though.

>
>
> On Fri, Aug 31, 2012 at 11:54 AM, Paul Phillips <pa...@improving.org> wrote:
>>
>>
>>
>> On Fri, Aug 31, 2012 at 7:41 AM, Dennis Haupt <h-s...@gmx.de> wrote:
>>>
>>> did i miss something, or did simply nobody think of that?
>>
>>
>> The second item has been present since 2.8.1:
>>
>> % scala3 -Yinfer-argument-types
>> Welcome to Scala version 2.11.0-20120828-084442-c5d1cf0915 (Java
>> HotSpot(TM) 64-Bit Server VM, Java 1.6.0_33).
>> Type in expressions to have them evaluated.
>> Type :help for more information.
>>
>> scala> trait Foo { def f(x: Ordering[Int], y: Seq[Int]): Int }
>> defined trait Foo
>>
>> scala> object Bar extends Foo { def f(x, y) = y sorted x head }
>> defined module Bar
>>
>
>

[Josh Suereth]

Right, we'd need a sip, but let's get on that for 2.11

[HamsterofDeath]

i really like where this is heading

[Naftoli Gugenheim]

On Fri, Aug 31, 2012 at 10:41 AM, Dennis Haupt <h-s...@gmx.de> wrote:

instead of trait X {def y(String,Int)}
?

I think it would be more consistent if it was:

trait X { def y(_: String, _: Int) }

[Lukas Rytz]

On Fri, Aug 31, 2012 at 10:30 PM, Josh Suereth <joshua....@gmail.com> wrote:

Any chance we can unleash this, or is it behind -Y because it's flaky in some way?

https://issues.scala-lang.org/browse/SI-1803

[Alex Repain]

2012/8/31 Naftoli Gugenheim <nafto...@gmail.com>

Agreeing on that. just putting in the type feels like a whole different syntax, and I feel like I would get confused by Dennis example if the type hierarchy got only slightly more complex...

[HamsterofDeath]

my shortcut was intended for simple cases. imagine it the other way round:
what if you were forced to use named arguments at every call you make? it certainly makes sense for calls like moveBy(x:Int, y:Int) so you don't confuse rows and colums. but if you just *can't* get it wrong, or it is very unlikely, you should be allowed to go the lazy developer's way.
agreeing on _:Type though, makes more sense and is consistent with already existing functions:
takesFunction((a,b,_,_,e) => ...)

[Som Snytt]

If you're taking requests, has anyone mentioned

def f(i = 0)

inferring the type from the default arg?  Just for the wish list of record.

Or maybe there's a good reason it was not added when defaults were introduced.

I also noticed -Yinfer-arg-types doesn't choose between overloads differing in result type, e.g.,
def f(i: Int): Int
def f(s: String): String
and implementation
def f(i): Int = ???

[Paul Phillips]

On Mon, Sep 3, 2012 at 1:20 AM, Som Snytt <som....@gmail.com> wrote:

def f(i = 0)

inferring the type from the default arg?  Just for the wish list of record.

Or maybe there's a good reason it was not added when defaults were introduced.

It's dangerous.  It's already dangerous enough that you can skip declaring return types, and when people do that in public API they are often punished when something changes (either in their own code, or in type inference itself) to lead to a different type being inferred, silently breaking compatibility with previous classes.  This problem would be multiplied if we allowed inference in parameter positions.

[Matthew Pocock]

I agree that this is dangerous. IMHO the root cause is that the situations where you can use defs with unannotated types should be very much restricted. The problems I stumble over all involve inheritance and overriding. Ideally, if there's a def of the same name and arity in the parent class and choose not to give a return type, you should *only* be able to over-ride the parent def. It should be impossible in this case to  provide an alternative polymorphic def without fully specifying the type. If the parent def is already polymorphic then this would rule out ever overriding it without giving an explicit return type. I think a similar rule would work with inference for argument types - if you choose to not fully supply the type argument types, you can only override a non-polymorphic method. That would change the inference from `inferred type` to the appropriate intersection or union with the parent type.

This is probably quite a big change though, and would perhaps break some existing code. Is there any point spending the effort working this up into a SIP?

Matthew

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Josh Suereth]

Not that I know, although if you lead an effort it would be appreciated.