Re: [scala-language] The cake’s problem, dotty des ign and the approach to modularity.

Okay I think I learned enough OCaml to understand row polymorphism for 
objects. Warning potential Dunning-Kruger statements ahead...

Afaics, it doesn't apply to the scenario of the Expression Problem I was 
addressing.

It appears row polymorphism is a way of declaring you want access to 
specific methods by name (structural typing) regardless of any other 
methods present in the object. But that is still requiring the control to 
be in the objects.

I was trying to solve the Expression Problem cases where the control can't 
be in the objects, and the control needs to be inverted and injected 
orthogonal to the objects. Not to mention that my proposal is agnostic to 
whether nominal or structural typing is employed.

For example, a function inputs a collection (e.g. a List) of objects but 
the caller has a List of objects which don't have the same type but there 
exists a way to pimp them to the required type. Do you create an entirely 
new list by wrapping all those objects as pimped. How inefficient. Instead 
we want that first function to input an injected interface as an extra 
function parameter, and this interface accepts as "this" the polymorphic 
type of the objects in the collection parameter. I gave coding examples 
previously and I will try to organize it all in near future.

Thus subclassing is no longer needed for implementing polymorphism because 
if you want reimplement a method of another type, provide a conversion from 
that type to your type.

I have now realized that an implicit function parameter (as the recommended 
replacement for the deprecated view bounds) can accomplish a large chunk of 
what I wanted.

First-class conjunctions (and disjunctions) are absolutely necessary 
because the implicit function parameter can't be a conversion from Any to 
the required type. For my idea to work we can't discard the types by 
subsuming to Any.

But it is wonderful to now realize that Dotty already supports my vision. 
All that remains is a deprecating subclassing and then realizing the gains 
in simplification of the DOT calculus so it is provable by traditional 
methods, and I think this will also make type inference more robust if I am 
not mistaken.

There may be other aspects of my original ramblings that are not 
incorporated into what I wrote in this post. I will need to review 
(preferably when I am not 4 days into fasting).


<rant>Of the many things I hate about OCaml's syntax is that it does 
everything snobbishly different from C, C++, Java heritage of the 
mainstream, e.g. semicolons as separator just afaik because they wanted to 
use commas for tuples and wanted to allow tuples to be written with or w/o 
enclosing parens, (* comments *), 2. +. 1., and other gnarly "symbol soup" 
bewilderment. Perhaps that's all necessary to make global type inference 
work seamlessly.</rant>



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.