Re: two things about defs

Burak,

On Sat, 27 Jan 2007 21:21:24 +0100, Burak Emir wrote:

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

Well, I always thought that method is a function that is associated to
particular object. In this case, it's not associated to any object since
I'm writing definition in toplevel (or maybe it's associated to some
artificial one).

> 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).

It seems I still don't understand the difference between methods and
functions, could you tell me?

> 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

-- WBR, Alexander Sergeev.

> 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.
>>
>>
> 
>