Re: two things about defs

hi alexander,

to the first question, the answer is that methods are different from function values.

to the second, the second- and higher-order systems like F(sub), Fomega(sub) have indeed some undecidability results, concerning inference, and subtyping. polymorphic values (type abstraction values) take you there.

maybe for that reason, type inference does not like to leave type parameters of methods-turned-into-functions uninstantiated. i don't know for sure (it seems feasible to do what you propose for *methods*), but I guess we would not like to be inference to do different things for values and for methods(defs). 

BTW I think you could have omitted the & in definition of xxx, given that you gave a function type in the annotation.

hope this helps,
Burak

On 1/27/07, Alexander Sergeev <as.beta@xxxxxxxxx> wrote:

I've posted one of these features into buglist, another one is probably
waiting it's turn.

First one:

scala> def sum(a: Int)(b: Int): Int = a+b
sum: (scala.Int)(scala.Int)scala.Int

scala> val sum2 = (x: int) => (y: int) => x + y
sum2: (scala.Int) => (scala.Int) => scala.Int = <function>

Could interpreter print out only one version of type output? Personally
I think the best one is: scala.Int => scala.Int => scala.Int = <function>

Second one:

scala> def yyy = &(List(1,2) foldLeft)
yyy: => (scala.Nothing) => ((scala.Nothing, scala.Int) => scala.Nothing) => scala.Nothing

scala> def xxx[a] : (a => ((a, int) => a) => a) =  &(List(1,2) foldLeft)
xxx: [a](a) => ((a, scala.Int) => a) => a

Is it possible for type inference mechanism to abstract over scala.Nothing
when deciding type for yyy? It would be great to have xxx automatically.
Though, this problem may be undecidable.

-- WBR, Alexander Sergeev.

-- 
Burak Emir
Research Assistant / PhD Candidate
Programming Methods Group
EPFL, 1015 Lausanne, Switzerland

http://lamp.epfl.ch/~emir