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

 On Sat, Jul 25, 2015, 12:11 PM Shelby <[email protected]> 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.

 If by "type of discussion" you mean the topic, this is a good forum to
discuss it. However, while I can't speak for anyone else, I can't
contribute to a discussion that I can't follow. So either you're way beyond
me, and i

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