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

On Sunday, July 26, 2015 at 12:11:26 AM UTC+8, Shelby wrote:
>
> On Saturday, July 25, 2015 at 1:13:13 PM UTC+8, Shelby wrote:
>>
>> Also I discovered this interesting presentation from Martin Odersky 
>> contrasting ML modules and Scala's abstract and self types and the Cake 
>> pattern:
>>
>>
>> http://stackoverflow.com/questions/15584848/whats-the-difference-if-any-between-standard-mls-module-system-and-ocaml-mod#comment22427900_15585373
>>
>
> Can anyone explain to me the justification for the Cake pattern for the 
> Symbol and Type relationship, instead of using a tuple parameterized on 
> Symbol and Type assuming the two are a bijection or at least surjective?
>
> If Symbols are not a bijection to Types, wouldn't an appropriate data 
> structure be a collection of Symbols for each Type?
>
> I can't fathom the re-use advantage of forcing a particular data structure 
> with self types, as it seems to inhibit other data structures. The only 
> relevant issue I fathom is it seems to be we need to statically insure that 
> every instance of Symbol has created a back pointer to itself from a 
> (collection in a) Type. The Symbol can require a method on its Type 
> parameter which the constructor of the Symbol can invoke on its `this`. But 
> traits aren't allow to have constructors, so we don't have a way to 
> statically require instances of Symbol to perform the necessary operation 
> on construction.
>
> So it seems the Cake pattern in this case is conflating data structure 
> re-use with invariants on the constructor, because traits have no other way 
> to declare invariants on the constructor. If I am correct, then what could 
> be done to improve this?
>
> Traits don't have constructors because this would complication 
> linearization with diamond multiple inheritance because each constructor is 
> only supposed to be called once and so that all preconditions for each 
> constructor are consistent. I am not sure if this could be solved with C3 
> linearization?
>
> Let me assume C3 linearization is a "can of worms" w.r.t. to mixin 
> constructors, so another idea is a syntax that declared a method of a trait 
> as required to be invoked from the constructor. Seems to me that would be 
> superior to conflating data structure and constructor invariants in the 
> self type.
>
> I hope someone will comment on this. Is they only way to do research is 
> lonesome and without any dialogue with others. If there is a better forum 
> for these types of discussion, please suggest to me.
>

This is yet another example of premature optimization (declaring the data 
structure in the self type) and my idea for a solution being an 
inversion-of-control, where the mixin injects a method into the constructor 
instead of prematuring declaring itself as a constructor.

I am starting to get the strong intuition that this concept of 
inversion-of-control needs to be proliferated throughout Scala 3 if we want 
to make a huge paradigm shift win on modularity. I am studying now the DOT 
calculus in detail and I am hoping I can apply such concepts so that type 
preservation can be recovered.

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