This page is no longer maintained — Please continue to the home page at www.scala-lang.org

type inference mullings

26 replies
rogerdpack 2
Joined: 2011-08-30,
User offline. Last seen 42 years 45 weeks ago.

Hello all.
I was mulling over type inference recently for the "mirah" JVM
language and thought I'd bring up my points here, as well.
I noticed in a comment in [1] "Most of us wish Scala's type inference
handled as much of the language as Haskell's does."

perhaps it (already does this but mentioning it anyway, in the spirit
of discussion...)

# infer types from their uses *within the same class* or what not.

def go(a) # no type necessary.
a + 3
end
...
# later used like:
go(3)
go(3.0)

Or perhaps it could auto-generate (several different signatures) based
on the current
known classes (all classes given in the classpath).
ex:
def go(a)
a + 3
end

it could look up all classes that respond to +(type_of_this) (which
would be Integer, Float, int,
float, double, etc.,) and generate several methods to match.

-roger-

[1] http://stackoverflow.com/questions/7234095/why-is-scalas-type-inference-...

Jesper Nordenberg
Joined: 2008-12-27,
User offline. Last seen 42 years 45 weeks ago.
Re: type inference mullings

I really don't see the problem with specifying a few types in this case.
It works as an extra check that you implemented the method correctly.

If you want a generic method use the Numeric trait.

/Jesper Nordenberg

rogerdpack skrev 2011-08-30 01:17:
> Hello all.
> I was mulling over type inference recently for the "mirah" JVM
> language and thought I'd bring up my points here, as well.
> I noticed in a comment in [1] "Most of us wish Scala's type inference
> handled as much of the language as Haskell's does."
>
> perhaps it (already does this but mentioning it anyway, in the spirit
> of discussion...)
>
> # infer types from their uses *within the same class* or what not.
>
> def go(a) # no type necessary.
> a + 3
> end
> ...
> # later used like:
> go(3)
> go(3.0)
>
> Or perhaps it could auto-generate (several different signatures) based
> on the current
> known classes (all classes given in the classpath).
> ex:
> def go(a)
> a + 3
> end
>
> it could look up all classes that respond to +(type_of_this) (which
> would be Integer, Float, int,
> float, double, etc.,) and generate several methods to match.
>
> -roger-
>
> [1] http://stackoverflow.com/questions/7234095/why-is-scalas-type-inference-...
>

Alec Zorab
Joined: 2010-05-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: type inference mullings

Following the grand tradition of functional programming, I have taken
your argument and generalised it to other areas of programming:

I don't really see the problem with [managing memory yourself], it
works as an extra check that you [wrote your code diligently]. If you
want to [have automatic memory management] use [auto_prt].

I don't really see the problem with [only having primitives], it works
as an extra check that you [understand the problem properly]. If you
want to [model things using objects] use [arrays of void* and hope].

I don't really see the problem with [having to have a different list
class for each type of list element], it works as an extra check that
you [really need a list of that type in the first place]. If you want
to [generalise across type parameters] use [a macroing system].

In all seriousness though, having to provide type annotations in
places where they're easily deducible a continual source of annoyance
for me (and I imagine anyone else who came from using an (extended)
Hindley-Milner language).

I've heard Martin mention several times that he considers the type
inference in scala to be one of the areas that could be improved the
most, so I'm fairly sure it's not just me and Roger thinking this...

On Tue, Aug 30, 2011 at 7:44 AM, Jesper Nordenberg wrote:
> I really don't see the problem with specifying a few types in this case. It
> works as an extra check that you implemented the method correctly.
>
> If you want a generic method use the Numeric trait.
>
> /Jesper Nordenberg
>
> rogerdpack skrev 2011-08-30 01:17:
>>
>> Hello all.
>> I was mulling over type inference recently for the "mirah" JVM
>> language and thought I'd bring up my points here, as well.
>> I noticed in a comment in [1] "Most of us wish Scala's type inference
>> handled as much of the language as Haskell's does."
>>
>> perhaps it (already does this but mentioning it anyway, in the spirit
>> of discussion...)
>>
>> # infer types from their uses *within the same class* or what not.
>>
>> def go(a)  # no type necessary.
>>   a + 3
>> end
>> ...
>> # later used like:
>> go(3)
>> go(3.0)
>>
>> Or perhaps it could auto-generate (several different signatures) based
>> on the current
>> known classes (all classes given in the classpath).
>> ex:
>> def go(a)
>>  a + 3
>> end
>>
>> it could look up all classes that respond to +(type_of_this) (which
>> would be Integer, Float, int,
>> float, double, etc.,) and generate several methods to match.
>>
>> -roger-
>>
>> [1]
>> http://stackoverflow.com/questions/7234095/why-is-scalas-type-inference-...
>>
>
>
>

Jesper Nordenberg
Joined: 2008-12-27,
User offline. Last seen 42 years 45 weeks ago.
Re: type inference mullings

Your analogies are faulty. Having to specify additional types doesn't
make you lose any compile time safety, it's just inconvenient in some
cases (I agree this much).

My stance is still that it's a good thing (TM) to explicitly specify the
types in your public interfaces. However, for local definitions type
inference is convenient. Note that I'm not talking about inference of
type parameters here, only leaving out type information in declarations.
Type parameter inference in Scala can definitely be improved.

/Jesper Nordenberg

Alec Zorab skrev 2011-08-30 09:06:
> Following the grand tradition of functional programming, I have taken
> your argument and generalised it to other areas of programming:
>
> I don't really see the problem with [managing memory yourself], it
> works as an extra check that you [wrote your code diligently]. If you
> want to [have automatic memory management] use [auto_prt].

> I don't really see the problem with [only having primitives], it works
> as an extra check that you [understand the problem properly]. If you
> want to [model things using objects] use [arrays of void* and hope].
>
> I don't really see the problem with [having to have a different list
> class for each type of list element], it works as an extra check that
> you [really need a list of that type in the first place]. If you want
> to [generalise across type parameters] use [a macroing system].
>
> In all seriousness though, having to provide type annotations in
> places where they're easily deducible a continual source of annoyance
> for me (and I imagine anyone else who came from using an (extended)
> Hindley-Milner language).
>
> I've heard Martin mention several times that he considers the type
> inference in scala to be one of the areas that could be improved the
> most, so I'm fairly sure it's not just me and Roger thinking this...
>
> On Tue, Aug 30, 2011 at 7:44 AM, Jesper Nordenberg wrote:
>> I really don't see the problem with specifying a few types in this case. It
>> works as an extra check that you implemented the method correctly.
>>
>> If you want a generic method use the Numeric trait.
>>
>> /Jesper Nordenberg
>>
>> rogerdpack skrev 2011-08-30 01:17:
>>>
>>> Hello all.
>>> I was mulling over type inference recently for the "mirah" JVM
>>> language and thought I'd bring up my points here, as well.
>>> I noticed in a comment in [1] "Most of us wish Scala's type inference
>>> handled as much of the language as Haskell's does."
>>>
>>> perhaps it (already does this but mentioning it anyway, in the spirit
>>> of discussion...)
>>>
>>> # infer types from their uses *within the same class* or what not.
>>>
>>> def go(a) # no type necessary.
>>> a + 3
>>> end
>>> ...
>>> # later used like:
>>> go(3)
>>> go(3.0)
>>>
>>> Or perhaps it could auto-generate (several different signatures) based
>>> on the current
>>> known classes (all classes given in the classpath).
>>> ex:
>>> def go(a)
>>> a + 3
>>> end
>>>
>>> it could look up all classes that respond to +(type_of_this) (which
>>> would be Integer, Float, int,
>>> float, double, etc.,) and generate several methods to match.
>>>
>>> -roger-
>>>
>>> [1]
>>> http://stackoverflow.com/questions/7234095/why-is-scalas-type-inference-...
>>>
>>
>>
>>
>

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: type inference mullings


On Tue, Aug 30, 2011 at 1:13 PM, Jesper Nordenberg <megagurka [at] yahoo [dot] com> wrote:
Your analogies are faulty. Having to specify additional types doesn't make you lose any compile time safety, it's just inconvenient in some cases (I agree this much).

My stance is still that it's a good thing (TM) to explicitly specify the types in your public interfaces. However, for local definitions type inference is convenient. Note that I'm not talking about inference of type parameters here, only leaving out type information in declarations. Type parameter inference in Scala can definitely be improved.

 Whether type inference in Scala can be improved is actually an open question.

An improvement in my mind would be something that

- keeps the same typing rules, in particular wrt subtyping
- can be specified with the at least same level of detail and rigor as the current implementation.
- infers types in more places and/or infers better types
- gives error messages that are at least as understandable as the current ones.

From my viewpoint this is very much an open research topic. If somebody came up with a system that satisfies these criteria, I'd be the happy to award that person a PhD.

Cheers

 -- Martin

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: type inference mullings

On Tue, Aug 30, 2011 at 08:26, martin odersky wrote:
>
> Whether type inference in Scala can be improved is actually an open
> question.
>
> An improvement in my mind would be something that
>
> - keeps the same typing rules, in particular wrt subtyping
> - can be specified with the at least same level of detail and rigor as the
> current implementation.
> - infers types in more places and/or infers better types
> - gives error messages that are at least as understandable as the current
> ones.
>
> From my viewpoint this is very much an open research topic. If somebody came
> up with a system that satisfies these criteria, I'd be the happy to award
> that person a PhD.

As a lower-hanging, non-PHD-material, fruit, types of default
parameters could be inferred.

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: type inference mullings


On Tue, Aug 30, 2011 at 4:00 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
On Tue, Aug 30, 2011 at 08:26, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
>
> Whether type inference in Scala can be improved is actually an open
> question.
>
> An improvement in my mind would be something that
>
> - keeps the same typing rules, in particular wrt subtyping
> - can be specified with the at least same level of detail and rigor as the
> current implementation.
> - infers types in more places and/or infers better types
> - gives error messages that are at least as understandable as the current
> ones.
>
> From my viewpoint this is very much an open research topic. If somebody came
> up with a system that satisfies these criteria, I'd be the happy to award
> that person a PhD.

As a lower-hanging, non-PHD-material, fruit, types of default
parameters could be inferred.

That's true. That would be easy enough to do  -- Martin

Hubert Plociniczak
Joined: 2009-09-12,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: type inference mullings
And for folks who are interested in this area here is a paper that describes some of the challenges Haskell people have with type inference:
http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn
(...and why sometimes it is just better to require from the programmer to give types explicitly).

hubert


On 08/30/2011 01:26 PM, martin odersky wrote:
DTfWc5Twvc0uicKL2eBkcg [at] mail [dot] gmail [dot] com" type="cite">

On Tue, Aug 30, 2011 at 1:13 PM, Jesper Nordenberg <megagurka [at] yahoo [dot] com" rel="nofollow">megagurka [at] yahoo [dot] com> wrote:
Your analogies are faulty. Having to specify additional types doesn't make you lose any compile time safety, it's just inconvenient in some cases (I agree this much).

My stance is still that it's a good thing (TM) to explicitly specify the types in your public interfaces. However, for local definitions type inference is convenient. Note that I'm not talking about inference of type parameters here, only leaving out type information in declarations. Type parameter inference in Scala can definitely be improved.

  Whether type inference in Scala can be improved is actually an open question.

An improvement in my mind would be something that

- keeps the same typing rules, in particular wrt subtyping
- can be specified with the at least same level of detail and rigor as the current implementation.
- infers types in more places and/or infers better types
- gives error messages that are at least as understandable as the current ones.

From my viewpoint this is very much an open research topic. If somebody came up with a system that satisfies these criteria, I'd be the happy to award that person a PhD.

Cheers

 -- Martin


Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: type inference mullings

I think you're missing the value of explicit type declaration as
documentation. Having used Python, I know how confusing it can be in
some cases to figure out the type of a particular value by tracing it
back to its origin. I have never used Haskell, but I would guess the
same issue would apply (albeit perhaps to a lesser extent due to
static typing).

For something like "val x = 1", the type is obvious from the line
itself, which is the ideal situation. However, the return type of a
long method or function is not always obvious without a return type
declaration. For that reason, I am tempted to suggest that return
types should be mandatory just as arguments are. But then you have
those one-liner methods that are more elegant without an explicit
return type. Maybe an explicit return type declaration should be
required for any function or method that has more than one statement
(or stated another way, any function or method with a body enclosed in
curly braces). Is that reasonable? Of course that could just be a
coding standard, but if its a good coding standard, then perhaps it
should be enforced by the compiler itself.

Here's another documentation problem with inferred types:

val foo = afunction(y, z)

What is the type of foo? It is not obvious based on this line alone. I
need to look up "afunction" to find out, which is not the ideal
situation.

--Russ P.

On Aug 29, 4:17 pm, rogerdpack wrote:
> Hello all.
> I was mulling over type inference recently for the "mirah" JVM
> language and thought I'd bring up my points here, as well.
> I noticed in a comment in [1] "Most of us wish Scala's type inference
> handled as much of the language as Haskell's does."
>
> perhaps it (already does this but mentioning it anyway, in the spirit
> of discussion...)
>
> # infer types from their uses *within the same class* or what not.
>
> def go(a)  # no type necessary.
>   a + 3
> end
> ...
> # later used like:
> go(3)
> go(3.0)
>
> Or perhaps it could auto-generate (several different signatures) based
> on the current
> known classes (all classes given in the classpath).
> ex:
> def go(a)
>  a + 3
> end
>
> it could look up all classes that respond to +(type_of_this) (which
> would be Integer, Float, int,
> float, double, etc.,) and generate several methods to match.
>
> -roger-
>
> [1]http://stackoverflow.com/questions/7234095/why-is-scalas-type-inferen...

roland.kuhn
Joined: 2011-02-21,
User offline. Last seen 35 weeks 3 days ago.
Re: Re: type inference mullings


On Aug 30, 2011, at 16:07, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:



On Tue, Aug 30, 2011 at 4:00 PM, Daniel Sobral <dcsobral [at] gmail [dot] com (dcsobral [at] gmail [dot] com" rel="nofollow">dcsobral [at] gmail [dot] com)> wrote:
On Tue, Aug 30, 2011 at 08:26, martin odersky <martin [dot] odersky [at] epfl [dot] ch (martin [dot] odersky [at] epfl [dot] ch" rel="nofollow">martin [dot] odersky [at] epfl [dot] ch)> wrote:
>
> Whether type inference in Scala can be improved is actually an open
> question.
>
> An improvement in my mind would be something that
>
> - keeps the same typing rules, in particular wrt subtyping
> - can be specified with the at least same level of detail and rigor as the
> current implementation.
> - infers types in more places and/or infers better types
> - gives error messages that are at least as understandable as the current
> ones.
>
> From my viewpoint this is very much an open research topic. If somebody came
> up with a system that satisfies these criteria, I'd be the happy to award
> that person a PhD.

As a lower-hanging, non-PHD-material, fruit, types of default
parameters could be inferred.

That's true. That would be easy enough to do  -- Martin

including a warning for when a singleton type is inferred?
Regards,
Roland
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: type inference mullings

On Tue, Aug 30, 2011 at 15:12, Russ P. wrote:
> I think you're missing the value of explicit type declaration as
> documentation. Having used Python, I know how confusing it can be in
> some cases to figure out the type of a particular value by tracing it
> back to its origin. I have never used Haskell, but I would guess the
> same issue would apply (albeit perhaps to a lesser extent due to
> static typing).
...
> Here's another documentation problem with inferred types:
>
> val foo = afunction(y, z)
>
> What is the type of foo? It is not obvious based on this line alone. I
> need to look up "afunction" to find out, which is not the ideal
> situation.

I'm pretty sure we have gone into this discussion before. I stand by
my point that showing the type is the job of the IDE. Some people
dislike the idea of having to use an IDE at all -- well, we like the
compiler doing a lot of work for us, so I don't know why resist the
editor doing so too.

rogerdpack 2
Joined: 2011-08-30,
User offline. Last seen 42 years 45 weeks ago.
Re: type inference mullings

> My stance is still that it's a good thing (TM) to explicitly specify the
> types in your public interfaces. However, for local definitions type
> inference is convenient. Note that I'm not talking about inference of
> type parameters here, only leaving out type information in declarations.
> Type parameter inference in Scala can definitely be improved.

Yes I agree. I'm not suggesting type information of arguments be
excluded from documentation,
just that it be inferred more aggressively from the code if possible,
but still included in the documentation.

-roger-

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: Re: type inference mullings

On Tuesday 30 August 2011, Daniel Sobral wrote:
> ...
>
> > Here's another documentation problem with inferred types:
> >
> > val foo = afunction(y, z)
> >
> > What is the type of foo? It is not obvious based on this line
> > alone. I need to look up "afunction" to find out, which is not the
> > ideal situation.
>
> I'm pretty sure we have gone into this discussion before. I stand by
> my point that showing the type is the job of the IDE. Some people
> dislike the idea of having to use an IDE at all -- well, we like the
> compiler doing a lot of work for us, so I don't know why resist the
> editor doing so too.

How does an IDE differ from a compiler (or _the_ compiler) in its
ability to infer (and then make explicit) the type of any particular
expression?

Randall Schulz

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: type inference mullings
Who said it differs?

On Wed, Aug 31, 2011 at 12:10 AM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Tuesday 30 August 2011, Daniel Sobral wrote:
> ...
>
> > Here's another documentation problem with inferred types:
> >
> > val foo = afunction(y, z)
> >
> > What is the type of foo? It is not obvious based on this line
> > alone. I need to look up "afunction" to find out, which is not the
> > ideal situation.
>
> I'm pretty sure we have gone into this discussion before. I stand by
> my point that showing the type is the job of the IDE. Some people
> dislike the idea of having to use an IDE at all -- well, we like the
> compiler doing a lot of work for us, so I don't know why resist the
> editor doing so too.

How does an IDE differ from a compiler (or _the_ compiler) in its
ability to infer (and then make explicit) the type of any particular
expression?


Randall Schulz

adriaanm
Joined: 2010-02-08,
User offline. Last seen 31 weeks 4 days ago.
Re: Re: type inference mullings
> I'm pretty sure we have gone into this discussion before. I stand by
> my point that showing the type is the job of the IDE. Some people
> dislike the idea of having to use an IDE at all -- well, we like the
> compiler doing a lot of work for us, so I don't know why resist the
> editor doing so too.
consider the analogy with documentation
would you expect the compiler or the IDE (or whatever tool) to infer documentation?
well, types (on module boundaries) are documentation, and there is no algorithm that can decide which of the various valid types that can be inferred, should be inferred, in order to convey the meaning you intended
that said, I'm sure someone could improve Scala's type inference algorithm, but I don't see any huge wins(and I think that are many more interesting challenges in and around the type system)
cheersadriaan
Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: type inference mullings

On 30/08/2011 23:24, Daniel Sobral wrote:
> I'm pretty sure we have gone into this discussion before. I stand by
> my point that showing the type is the job of the IDE. Some people
> dislike the idea of having to use an IDE at all -- well, we like the
> compiler doing a lot of work for us, so I don't know why resist the
> editor doing so too.

Sure, whenever I read Scala code on the Web (among others sources), I will copy & paste it
in an IDE to see its types. And it won't work if the code isn't self-contained...

Indeed, giving types might not be enforced by the compiler, to suit all programming
styles. But to explicitly give type of functions (or even of variables, when they are not
obvious from the assignment) remain an interesting "documentation" task, and can be part
of a company's policy.
And having type inference to fail (I nave no issue with this) lead to inconsistent code
where sometime type is explicitly given and sometime not.
Thus, it could be interesting to have a flag to issue warnings when such types are
omitted: admittedly, sometime I input code quickly and omit these types, and try and add
them when I re-read the code, so I suppose it can be frequent minor sin among coders...
As pointed out, the difficulty is to set a limit: it is pointless to type most anonymous
functions, or very short, obvious ones.

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: type inference mullings

On Wed, Aug 31, 2011 at 04:23, Adriaan Moors wrote:
>> > I'm pretty sure we have gone into this discussion before. I stand by
>> > my point that showing the type is the job of the IDE. Some people
>> > dislike the idea of having to use an IDE at all -- well, we like the
>> > compiler doing a lot of work for us, so I don't know why resist the
>> > editor doing so too.

First of all, let me make clear that the issue here is whether I write

val x: Int = lst.size

or

val x = lst.size

In other words, whether I make the type explicit where the compiler
can infer it for the sole purpose of documentation. Emphasis on
"sole".

> consider the analogy with documentation
> would you expect the compiler or the IDE (or whatever tool) to infer
> documentation?

I consider that to be a utterly broken analogy.

> well, types (on module boundaries) are documentation, and there is no
> algorithm that can decide which of the various valid types that can be
> inferred, should be inferred, in order to convey the meaning you intended

And, yet, scalac does precisely that in a lot of places quite often.

Perhaps you mean there's no algorithm that can infer which type I
intended *all the time*, and *for the Scala type system*. That I'll
readily grant, but it's not at all related to my point. My point only
comes into play when the compiler successfully infers the type I
intended, so it is moot what happens when it doesn't. And, in fact, it
is not really related to Scala the language, but to statically typed
languages that have type inference to any extent.

adriaanm
Joined: 2010-02-08,
User offline. Last seen 31 weeks 4 days ago.
Re: Re: type inference mullings
First of all, let me make clear that the issue here is whether I write
val x: Int = lst.size

or

val x = lst.size

In other words, whether I make the type explicit where the compiler
can infer it for the sole purpose of documentation. Emphasis on
"sole".
I consider this an utterly unexciting example of type inference. 
Sure, we can and should do that. That's what local type inference is all about. Nobody's arguing against that, as far as I understood. 
We're debating whether we can (theoretically?) or even should (practically) push it beyond that.

> consider the analogy with documentation
> would you expect the compiler or the IDE (or whatever tool) to infer
> documentation?

I consider that to be a utterly broken analogy.
I consider this an utterly broken argument. It's a valid opinion, but I beg to differ.
 
> well, types (on module boundaries) are documentation, and there is no
> algorithm that can decide which of the various valid types that can be
> inferred, should be inferred, in order to convey the meaning you intended

And, yet, scalac does precisely that in a lot of places quite often.
Really, the compiler has guessed what you mean before? I think we're talking about different things here.
Let me try and clarify.
I'm talking about choices like: should I infer Seq[Int] as the type of the expression List(1,2,3), since the programmer may later decide to generalise it? Or should I just go ahead and infer List[Int]? (Or wait, maybe she meant Seq[Any] -- let me sleep on this for a night).
More diligent compilers might ponder: should I infer ForAll U, T <: {def +(x: Int): U}. T => U, or just Int => Int? (Say it's currently mulling over the expression `x => x + 1`)
I don't think the compiler bothers with these questions. In fact, I know it doesn't.
On the other hand, we make these choices all the time and write them down as machine-checked documentation: type annotations.
I consider these deliberate choices by the programmer documentation.Whenever you decide to subsume a type, you're saying, "hey, I may later decide to use a Set here, but that's none of your business". Etc, etc.

cheersadriaan
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: type inference mullings

I'm pretty sure we are talking completely at odds here. I'll quote a
bit of the message I was replying to:

***************
Here's another documentation problem with inferred types:

val foo = afunction(y, z)

What is the type of foo? It is not obvious based on this line alone. I
need to look up "afunction" to find out, which is not the ideal
situation.
***************

This is the situation I am talking about, and my point is that it's
the job of the IDE (or editor) to show the type, instead of demanding
us to write it out.

On Wed, Aug 31, 2011 at 14:08, Adriaan Moors wrote:
>> First of all, let me make clear that the issue here is whether I write
>> val x: Int = lst.size
>>
>> or
>>
>> val x = lst.size
>>
>> In other words, whether I make the type explicit where the compiler
>> can infer it for the sole purpose of documentation. Emphasis on
>> "sole".
>
> I consider this an utterly unexciting example of type inference.
> Sure, we can and should do that. That's what local type inference is all
> about.
> Nobody's arguing against that, as far as I understood.
> We're debating whether we can (theoretically?) or even should (practically)
> push it beyond that.
>>
>> > consider the analogy with documentation
>> > would you expect the compiler or the IDE (or whatever tool) to infer
>> > documentation?
>>
>> I consider that to be a utterly broken analogy.
>
> I consider this an utterly broken argument. It's a valid opinion, but I beg
> to differ.
>
>>
>> > well, types (on module boundaries) are documentation, and there is no
>> > algorithm that can decide which of the various valid types that can be
>> > inferred, should be inferred, in order to convey the meaning you
>> > intended
>>
>> And, yet, scalac does precisely that in a lot of places quite often.
>
> Really, the compiler has guessed what you mean before? I think we're talking
> about different things here.
> Let me try and clarify.
> I'm talking about choices like: should I infer Seq[Int] as the type of the
> expression List(1,2,3), since the programmer may later decide to generalise
> it? Or should I just go ahead and infer List[Int]? (Or wait, maybe she meant
> Seq[Any] -- let me sleep on this for a night).
> More diligent compilers might ponder: should I infer ForAll U, T <: {def
> +(x: Int): U}. T => U, or just Int => Int? (Say it's currently mulling over
> the expression `x => x + 1`)
> I don't think the compiler bothers with these questions.
> In fact, I know it doesn't.
> On the other hand, we make these choices all the time and write them down as
> machine-checked documentation: type annotations.
> I consider these deliberate choices by the programmer documentation.
> Whenever you decide to subsume a type, you're saying, "hey, I may later
> decide to use a Set here, but that's none of your business".
> Etc, etc.
>
> cheers
> adriaan

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Re: type inference mullings
On Wed, Aug 31, 2011 at 11:27 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
I'm pretty sure we are talking completely at odds here. I'll quote a
bit of the message I was replying to:

***************
Here's another documentation problem with inferred types:

val foo = afunction(y, z)

What is the type of foo? It is not obvious based on this line alone. I
need to look up "afunction" to find out, which is not the ideal
situation.
***************

This is the situation I am talking about, and my point is that it's
the job of the IDE (or editor) to show the type, instead of demanding
us to write it out.


Daniel, I was only trying to point out the difference between type inference that is self-contained in the line itself and type inference that depends on other code that could be in a completely different source file. I use both kinds of type inference myself, but I am somewhat conflicted about the latter. On the one hand, it is elegant and clean, but on the other hand, it could hinder someone else trying to understand my code in some instances. To put it the other way, explicit type declarations could in some instances clarify the code and save the reader the trouble of determining the type (even if it takes only a few seconds).

Yes I agree that a good IDE can reduce the need for explicit type declarations. But not everyone uses an IDE all the time. As someone else pointed out, you don't use an IDE when you read code samples on the web or when you read github source code listings, for example (or do you?). Also, for high-value code (e.g., safety-critical or mission-critical code), there needs to be a code reference that stands on its own, independent of any IDE. Oh, and what about printing out code? Does anyone do that anymore?

--Russ P.

--
http://RussP.us
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: type inference mullings

On Wed, Aug 31, 2011 at 16:07, Russ Paielli wrote:
>
> Yes I agree that a good IDE can reduce the need for explicit type
> declarations. But not everyone uses an IDE all the time. As someone else
> pointed out, you don't use an IDE when you read code samples on the web or
> when you read github source code listings, for example (or do you?). Also,
> for high-value code (e.g., safety-critical or mission-critical code), there
> needs to be a code reference that stands on its own, independent of any IDE.
> Oh, and what about printing out code? Does anyone do that anymore?

I submit we need to evolve towards more intelligent tools across the
board. Print code? Have an option that print it with types. Simple
editor instead of IDE? What is a simple editor these days? Textmate,
vim, etc -- they all already have a lot of intelligence. The need more
of it. Codes on sites? Evolve beyond syntax highlighting to type
tool-tips, etc.

Jesper Nordenberg
Joined: 2008-12-27,
User offline. Last seen 42 years 45 weeks ago.
Re: type inference mullings

Adriaan Moors skrev 2011-08-31 19:08:
> Let me try and clarify.
>
> I'm talking about choices like: should I infer Seq[Int] as the type of
> the expression List(1,2,3), since the programmer may later decide to
> generalise it? Or should I just go ahead and infer List[Int]? (Or wait,
> maybe she meant Seq[Any] -- let me sleep on this for a night).

This is one of the reasons why I think it's preferable to explicitly
specify the (return) type of public definitions. For local definitions I
think it's best to infer the most specific type, even singleton types.
Yes, this is problematic for types of var's, but they are problematic
anyway in the context of subtyping.

/Jesper Nordenberg

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: type inference mullings

On Wed, Aug 31, 2011 at 3:24 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
On Wed, Aug 31, 2011 at 16:07, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
>
> Yes I agree that a good IDE can reduce the need for explicit type
> declarations. But not everyone uses an IDE all the time. As someone else
> pointed out, you don't use an IDE when you read code samples on the web or
> when you read github source code listings, for example (or do you?). Also,
> for high-value code (e.g., safety-critical or mission-critical code), there
> needs to be a code reference that stands on its own, independent of any IDE.
> Oh, and what about printing out code? Does anyone do that anymore?

I submit we need to evolve towards more intelligent tools across the
board. Print code? Have an option that print it with types. Simple
editor instead of IDE? What is a simple editor these days? Textmate,
vim, etc -- they all already have a lot of intelligence. The need more
of it. Codes on sites? Evolve beyond syntax highlighting to type
tool-tips, etc.

That's a wonderful ideal, but the fact is, today (at least) most people don't have such super tools everywhere, so one can still argue that one should have consideration for readers.
But that argument (the one about code on the web, etc.) does create distinctions between different code. For instance, if I'm working on my own project, I don't expect to publish it in such places.
 

--
Daniel C. Sobral

I travel to the future all the time.

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: type inference mullings

On 31/08/2011 21:24, Daniel Sobral wrote:
> I submit we need to evolve towards more intelligent tools across the
> board. Print code? Have an option that print it with types. Simple
> editor instead of IDE? What is a simple editor these days? Textmate,
> vim, etc -- they all already have a lot of intelligence. The need more
> of it. Codes on sites? Evolve beyond syntax highlighting to type
> tool-tips, etc.

Sure, that's what the debate about lack of tooling for Scala (compared to Java) is about.
We also need to inject Scala awareness in all diff tools we can use, all the range of
editors we can use, all syntax highlighting (server-side and client-side) libraries, and
so on.
Until then, we have to live with in our current real world... :-)

Note: yes, I occasionally print out some code, when I need to study it in public
transports (I don't have a tablet or notebook yet).

And yes, sometime, being the beginner I am, sometime I wonder when I see a simple val
assignment, what is the type of the variable:

val someData = someColl.filter(tada).map(transf).collect { some code here }

and so on (yes, that's random code...).

adelarsq
Joined: 2010-09-19,
User offline. Last seen 1 year 35 weeks ago.
Re: type inference mullings

Is this a case that is possible to improve the language?

scala> trait S{
| type x
| def get:x
| }
defined trait S

scala> var sample = new S {
| type x = Int
| def get = 3
| }
sample: java.lang.Object with S{type x = Int} = $anon$1@1bd2184

To define correctly is obrigatory to put ":S":

scala> var sample2:S = new S {
| type x = Int
| def get = 3
| }
sample2: S = $anon$1@144e3ae

[]'s

On 1 set, 05:26, Philippe Lhoste wrote:
> On 31/08/2011 21:24, Daniel Sobral wrote:
>
> > I submit we need to evolve towards more intelligent tools across the
> > board. Print code? Have an option that print it with types. Simple
> > editor instead of IDE? What is a simple editor these days? Textmate,
> > vim, etc -- they all already have a lot of intelligence. The need more
> > of it. Codes on sites? Evolve beyond syntax highlighting to type
> > tool-tips, etc.
>
> Sure, that's what the debate about lack of tooling for Scala (compared to Java) is about.
> We also need to inject Scala awareness in all diff tools we can use, all the range of
> editors we can use, all syntax highlighting (server-side and client-side) libraries, and
> so on.
> Until then, we have to live with in our current real world... :-)
>
> Note: yes, I occasionally print out some code, when I need to study it in public
> transports (I don't have a tablet or notebook yet).
>
> And yes, sometime, being the beginner I am, sometime I wonder when I see a simple val
> assignment, what is the type of the variable:
>
>    val someData = someColl.filter(tada).map(transf).collect { some code here }
>
> and so on (yes, that's random code...).
>
> --
> Philippe Lhoste

d_m
Joined: 2010-11-11,
User offline. Last seen 35 weeks 2 days ago.
Re: Re: type inference mullings

On Tue, Sep 06, 2011 at 04:18:48PM -0700, Adelar da Silva Queiróz wrote:
> Is this a case that is possible to improve the language?

When you create "new S { type = Int; ...}" you are creating a new type,
(an anonymous subclass of S) which is different (and more specific)
than the trait S. So, while you can certainly say "val s:S = new S {
... }" that should not be the default.

It's similar like saying "val s:Seq = Array.ofDim[Int](10)" to make s a
Seq[Int]. We want to be able to do this but by default s should be an
Array[Int], not a Seq[Int].

d_m
Joined: 2010-11-11,
User offline. Last seen 35 weeks 2 days ago.
Re: Re: type inference mullings

On Wed, Sep 07, 2011 at 11:45:27AM -0400, Erik Osheim wrote:
> It's similar like saying "val s:Seq = Array.ofDim[Int](10)" to make s a

Errr, that should be "val s:Seq[Int] = Array.ofDim[Int](10)".

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland