Re: Re: Strange type error

OTOH a compiler needs to be predictable. You don't want a compiler that's
smarter than you, and decide that you "must" have meant something that
didn't even occur to you! Now if could actually read your mind... Then
again code has to be read by other people too...

On Thu, May 7, 2015, 12:54 PM Oliver Ruebenacker <[email protected]> wrote:

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

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