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

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.

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