Re: Re: Scala - a Roadmap

That didn't take long to dig.

It appears to me that all counterexamples to preservation (which prevent a 
simple proof that DOT is sound), derive from the generative essence that 
abstract (a.k.a. virtual) types are allowed to be carried around at 
runtime. It is not the choice of representation as parameteric or abstract 
types which causes the problem (since given both the ability to encode the 
self type, they are rationally equivalent); rather that hidden abstract 
types can be refined at runtime. All the syntactical sugar that prefers one 
over the other is apparently irrelevant to the issue which is allowing 
refinement to not be checked at compile-time, e.g. val x : Animal instead 
of val x : Animal { Food = Grass | Meat } equivalent to some parameter 
representation val x : Animal[Food] instead of val x : Animal[Grass | Meat]

http://lampwww.epfl.ch/~amin/dot/

Thus as expected (see my quote below) the problem with DOT as currently 
formulated is premature optimization of abstraction at compile-time. Rather 
than allowing inversion-of-control and injection of the abstraction at 
compile-time, it optimizing by pushing abstraction to run-time.

The argument against this inversion-of-control was stated by Martin 
Odersky, "You could parameterize class Animal with the kind of food it 
eats. But in practice, when you do that with many different things, it 
leads to an explosion of parameters, and usually, what's more, in bounds of 
parameters. At the 1998 ECOOP, Kim Bruce, Phil Wadler, and I had a paper 
where we showed that as you increase the number of things you don't know, 
the typical program will grow quadratically.":

http://www.artima.com/scalazine/articles/scalas_type_system.html#abstracttypes

My response to Martin is that is why we must invert the control at every 
method per the quotes below, so that quadric explosion is shifted 
inside-out.

I therefor posit that DOT is broken and needs to be reformated in a new 
holistic model per my quotes below and the examples in the other thread.

P.S. this idea about inversion-of-control at the call site with automated 
assistance from the compiler is one I had in my head for a couple of years 
now since I was brainstorming one day with the author of Kotlin. He went 
with some very simple form of solution which didn't embody what I was 
driving for.


From the thread "Re: [scala-language] The cake’s problem, dotty design and 
the approach to modularity.":
 
On Sunday, July 26, 2015 at 12:28:53 AM UTC+8, Shelby wrote:

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



On Saturday, July 25, 2015 at 1:13:13 PM UTC+8, Shelby wrote:
>
> I believe perhaps the ideas I have presented for injection of interface 
> (relying on DOT) are a complete solution (and more generalized) to the 
> reasons given for needing to represent family polymorphism by tracking 
> types in the instance (which appears to be a less general form of 
> dependency injection):
>  
> http://www.cs.au.dk/~eernst/tool11/papers/ecoop01-ernst.pdf#page=8



On Wednesday, July 22, 2015 at 11:47:04 PM UTC+8, Shelby wrote:
>
> If a set of types share a set of methods (perhaps implemented as typeclass 
> rather than virtual inheritance so the dictionary can be injected with an 
> object), then the disjunction of those types is the conjunction (and the 
> conjunction of those types is the disjunction) of the implementations of 
> that interface. But note that A ∧ A = A ∨ A, so thus both disjunction and 
> conjunction can be operated upon if they share an interface A.
>
> That was the point of my prior post.
>


On Saturday, July 18, 2015 at 9:51:18 PM UTC+8, Shelby wrote:
>
> I believe I show herein the fundamental importance of objects (as in 
> "OOP"), that subclassing (but not subtyping) is fundamentally an 
> anti-pattern, and that the new DOT calculus is essential.
>
> For the goal of completely solving the Expression Problem, I believe the 
> requirement for a "global vtable" which I pondered upthread, is implicitly 
> fulfilled by the injection of inversion-of-control I had proposed.
>
> Objects are passed around as the vtable, which I believe is a form of the 
> extensible modularity
> ...
> Perhaps the Dotty compiler could automatically generate the implicit 
> object `Drawable[Line ∨ Box]`. Thus we retain subtyping (i.e. `Line` and 
> `Box` are subtypes of `Line ∨ Box`) while eliminating subclassing (i.e. 
> there is no nominal type which is the supertype of `Line ∨ Box` or at 
> least `Any` should only occur with a cast since I've shown it discards 
> extensible static typing).
> ...
>
> Another benefit of deprecating subsumption via subclassing in favor of 
> subtyped disjunction, is distinct invariantly parametrized types can be 
> added to the same List:
>
> class TaggedLine[Tag](a: Point, b: Point, tag: TAG)...
>
> draw(List(TaggedLine(Point(0,0), Point(1,1), 
> 1), List(TaggedLine(Point(0,0), Point(1,1), "1"))) // Error: can not 
> subsume to List[TaggedLine[Any]] because TAG is invariant
>
> I assume the new DOT calculus will instead implicitly subsume `TAG` to 
> `Int ∨ String` instead of `Any`?
>
> Somewhat OT, I am pondering how will DOT deal with the following?
>
> trait Invertible[T <: Invertible[T, A, B], A, B] {
>   def to(a: A): B
>   def from(b: B): A
> }
>
> object AB extends Invertible[AB, A, B] {
>   def to(a: A): B...
>   def from(b: B): A...
> }
>
> object CD extends Invertible[CD, C, D] {
>   def to(c: C): D...
>   def from(d: D): C...
> }
>
> def to[T, A, B](invertible: Invertible[T, A, B], a: A): B = invertible.to
> (a)
>
> f(AB ∧ CD, new A)
> f(AB ∧ CD, new C)
>
> So the Dotty compiler has to automatically supply:
>
> object `AB ∧ CD` extends Invertible[`AB ∧ CD`, A ∨ C, B ∨ D] {
>   def to(a: A): B...
>   def to(a: C): D...
>   def from(b: B): A...
>   def from(d: D): C...
> }
>
> On Sunday, July 5, 2015 at 11:50:07 PM UTC+8, Shelby wrote:
>>
>> Coming back to this ... and sorry no time to construct a blog too rushed 
>> ... 
>>
>
>> To summarize ideas against premature specialization... 
>>
>

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