Re: Re: Strange type error

     Hello,

  If you have:

  (_+_)*_

  How would the compiler know where the function definition begins an where
it ends?

  If you want to reduce the sugar, just replace with

  (x, y, z) => (x+y)*z

  In general, when you write code intended to mean X, but the compiler
thinks you meant Y, what is the reason? Probably, designers that thought in
most cases, people do mean Y. Maybe they still think so, or maybe they now
think it is not worth making the change and break existing stuff.

  Now you may ask, what if Y does not work out, why does the compiler not
fall back to X? Probably, the compiler arrived at Y as the result of
multiple decisions, and how does it know which of these decisions were
wrong? Probably, it was not the most recent one.

  Maybe a smarter compiler would do what you want. But some one has to
build it first.

     Best, Oliver

On Thu, May 7, 2015 at 11:15 AM, Toby <[email protected]> wrote:

> Ok, so in essence when building the tree the compiler does not yet realise
> that it requires a three-parameter function at that point and hence follows
> the 'default approach' for combining low-level stuff into higher level
> stuff. The brackets change what that default is.
>
> I can't say that I understand the why any better, but I suspect that that
> is not a 'user-level' issue. Sometimes, there is just too much sugar!
>
> On Thursday, 7 May 2015 16:50:35 UTC+2, Oliver Ruebenacker wrote:
>>
>>
>>      Hello,
>>
>>   First, the compiler needs to turn the source code into a syntax tree.
>> Only after that, it assigns types to nodes of the tree.
>>
>>   So, at the time the compiler needs to decide which part of the code
>> constitutes an anonymous function, it cannot yet take into account, what
>> type is required. It needs to go by syntax only, and that leaves few
>> options besides limiting it to simple expressions.
>>
>>   Something like (_ + _) * 3 is not necessarily illegal, there may be an
>> implicit conversion of a function into something that has a * operator.
>>
>>      Best, Oliver
>>
>> On Thu, May 7, 2015 at 10:31 AM, Toby <[email protected]> wrote:
>>
>>> Thank you Janusz and Phillips for your answers.
>>>
>>> However, you have told me what happens but not why it happens. I am
>>> hence a little wiser but no more enlightened.
>>>
>>> Why does the compiler decide that the presence of brackets requires
>>> nested functions, rather than one function with multiple parameters and
>>> precedence? The unique type that would satisfy the requirements of the
>>> function being called is a function of three Double parameters. This makes
>>> no sense to me.
>>>
>>> On Thursday, 7 May 2015 13:10:28 UTC+2, Andrew Phillips wrote:
>>>>
>>>> > but with additional brackets to change precedence, (_ + _) * _ fails
>>>>
>>>> Just for completeness: as you probably also discovered, it also fails
>>>> if you *don't* affect the precedence, and simply add brackets for e.g.
>>>> clarity:
>>>>
>>>> scala> execute( _ + (_ * _) )
>>>> <console>:9: error: missing parameter type for expanded function ((x$1)
>>>> => x$1.$
>>>> plus(((x$2, x$3) => x$2.$times(x$3))))
>>>>               execute( _ + (_ * _) )
>>>>                        ^
>>>>
>>>> Regards
>>>>
>>>> ap
>>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "scala-language" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Oliver Ruebenacker
>> Solutions Architect at Altisource Labs <http://www.altisourcelabs.com/>
>> Be always grateful, but never satisfied.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Oliver Ruebenacker
Solutions Architect at Altisource Labs <http://www.altisourcelabs.com/>
Be always grateful, but never satisfied.

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.