Re: The cake's problem, dotty design and the approach to modularity.

To expand on that last part a bit.

In FP languages like Haskell you have functions to be unary, with partial
application and higher order return types to support multi parameters.
X->Y->Z apply X = Y->Z
In language like scala, which also focuses on objects it seems prudent to
have objects for parameters.
{x:X}->{y:Y}->{z:Z} apply {x:X} = {y:Y}->{z:Z}
But since we now have the bindings lets just simplify to
{x:X,y:Y}->{z:Z} apply {x:X} = {y:Y}->{z:Z}
Since the order is now not important
{a:A}->{y:Y} andThen {x:X,y:Y}->{z:Z} is simple enough
BR
John.




sön 23 aug 2015 kl. 18:11 skrev John Nilsson <[email protected]>:

> With regards to parameter lists I think there is a case to be made for not
> treating not them as lists at all. The order is usually not important,
> while the name of the binding is. So it's probably better to treat
> arguments as a set of bindings or as first class environments.
>
> The names of the argument needs to be explicit in the type to allow
> disambiguation, and also to support overloading on parameter name only (if
> the type of the value is not sufficient)
>
> Also, when the parameter order is not significant composition and
> application can be commutative.
>
> BR
> John
>
>
> sön 23 aug 2015 kl. 16:58 skrev Shelby <[email protected]>:
>
>> I am in the midst of studying OCaml in case it should be a preferred
>> language choice for the project I am currently launching. The curiosity is
>> unbearable.
>>
>> First gripe (and attempting to make the first case of justification for
>> my allegation of "fugly syntax") is I want to know how many in the Scala
>> community agree or disagree with my preference for parens around function
>> operands (a.k.a. parameters or arguments)? Those coming from the C, C++,
>> and Java background do not usually like the FP preference of just using
>> spaces. My justification on top of that legacy, popularity point is that
>> without parens, you must visit the function declaration site before you can
>> read the function use site. For someone unfamiliar trying to read code,
>> this places a burden of "all or nothing" knowledge of the source code,
>> which is highly inefficient and not in the spirit of separation-of-concerns
>> and single-point-of-truth. The only place where I think spaces should be
>> allowed are for infix operators (even those which are keywords instead of
>> symbols), i.e. those in which there is an operand on each side of the
>> operator, and those unary (post or prefix) operators which are symbols (and
>> in that case there should be no spaces between the operand and operator,
>> use parens if you need to juxtapose unary operators). These are the sort of
>> rules that I would like to see so there is consistency to Scala code
>> because given open source "the #1 priority of any programming language bar
>> none, is readability"— Eric S. Raymond the progenitor of the term "open
>> source":
>>
>>
>> http://jobtipsforgeeks.com/2012/05/17/lessons-from-a-jug-talk-with-eric-esr-raymond/
>>
>> So that is one way Scala can differentiate itself from other purest,
>> snobbish FP languages and be more friendly to those coming from mainstream
>> backgrounds.
>>
>> Feedback?
>>
>>
>>
>> On Sunday, August 23, 2015 at 1:33:47 AM UTC+8, Shelby wrote:
>>>
>>> Thanks I'll try to look at that. I don't know ML well and struggle with
>>> its syntax so it will slow me down, but I should see if that does already
>>> provide the functionality. Necessary of course for writing a white paper
>>> and citing prior art.
>>>
>>> Even then there are other variables at play such as:
>>>
>>> * tool support
>>> * JVM interopt
>>> * JS compilation (I must have this!)
>>> * fugly syntax of OCaml (imo)
>>> * community
>>> * momentum
>>>
>>> I believe Scala heads can be convinced subclassing is an anti-pattern
>>> but even if not, it appears Scala is headed towards being a modular
>>> platform for language experimentation with the move towards a TASTY layer.
>>>
>>> I sense that Scala will be the place where there economies-of-scale
>>> form. Maybe not. Need to consider a lot of details and I am 1000 miles up
>>> in the air right now due to other priorities.
>>>
>>>
>>> On Saturday, August 22, 2015 at 6:43:53 PM UTC+8, Bardur Arantsson wrote:
>>>>
>>>> On 08/22/2015 03:05 AM, Shelby wrote:
>>>> > I agreed with all the range of discussion at the following HN thread.
>>>> In
>>>> > particular, I want to call attention to the following post which
>>>> emphasizes
>>>> > that Scala is not sufficiently simplified and unified. Scala 3 with
>>>> the DOT
>>>> > (Dotty) proposal is attempting to make some headway, and my position
>>>> is to
>>>> > try to remove subclassing (retain subtyping) and replace with a
>>>> superior
>>>> > paradigm which is more unified, which will make the calculus more
>>>> provable,
>>>> > will make type inference more simplifed and complete, and will remove
>>>> the
>>>> > CAKE pattern and other warts which are giving Scala a bad rap while
>>>> also
>>>> > slam dunking it to massive adoption...
>>>> >
>>>>
>>>> I think you're tilting at windmills. As I understand it, part of the
>>>> raison d'être of Scala is that it is a research vehicle[1] and that
>>>> "how
>>>> to do subclassing right" is/was a big part of that research. Instead of
>>>> tilting, perhaps you should look into some of the more... ahem...
>>>> polished functional languages? Like O'Caml or Haskell?
>>>>
>>>> For example, it seems that much of what you want is already provided by
>>>> the row polymorphism support in O'Caml...? (Btw, O'Caml also has an
>>>> object system which is structural, i.e. non-nominal, but ironically --
>>>> given the name of the language -- almost nobody used it last I heard...
>>>> which was quite a long while ago, admittedly.)
>>>>
>>>> Regards,
>>>>
>>>> [1] Well, at least it started out that way. I guess things might have
>>>> changed?
>>>>
>>>> --
>> 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.