Expected distribution of lambda sizes (Re: Syntax poll, take 2)
John Nilsson
john at milsson.nu
Wed Jun 15 10:27:48 PDT 2011
In that case you could just skip the type parameter list entierly. In
my mind the method is attached to the raw type, just like static
methods are accessed by Class.method(), Class#method would be
sensible.
BR,
John
On Wed, Jun 15, 2011 at 7:25 PM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 15/06/11 18:17, John Nilsson wrote:
>> That could be solved either by simply deciding which name wins, or by
>> some slight syntax change to differentiate between methods and
>> functions ( a method on this, for example, would be a function in the
>> scope of the lambda) for example #.fst #.snd would be method calls.
> Another idea:
>
> Pair<>#fst
>
> Maurizio
>> BR,
>> John
>>
>> On Wed, Jun 15, 2011 at 5:37 PM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>> On 15/06/11 16:00, John Nilsson wrote:
>>>> On Wed, Jun 15, 2011 at 4:13 PM, Maurizio Cimadamore
>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>> <T, V extends Comparable<T>> List<V> schwarz(List<T> x, Function<T,
>>>>> Pair<T,V>> f) {
>>>>> return map(#{ w -> f.apply(w) }, x)
>>>>> .sort( Pair<T,V>#fst() )
>>>>> .map( Pair<T,V>#snd() );
>>>>> }
>>>> Could this become the following even?
>>>>
>>>> <T, V extends Comparable<T>>
>>>> List<V> schwarz(List<T> x, Function<T,Pair<T,V>> f) {
>>>> return x.map(f).sort(#fst).map(#snd);
>>>> }
>>> I see where you are headed, you want to use the target type in order to
>>> infer the receiver type of the method reference; while this seems a nice
>>> idea in principle, a problem I see with this is the potential ambiguity with
>>> this#foo (which people might want to be able to shorten to just #foo).
>>>
>>> Maurizio
>>>> BR,
>>>> John
>>>
>
>
More information about the lambda-dev
mailing list