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

I would not seriously involve LSP into solving this kind of problems. LSP
is for explaining things to beginners, not for solving problems in "applied
category theory" (as some people call programming these days).

One of the solutions is to think about a natural transformation from a
covariant functor to a contravariant functor (List[+T] => List[-T]).

Thanks,
-Vlad

On Mon, Jun 15, 2015 at 11:52 PM, Shelby <[email protected]> wrote:

> Thinking about how this relates to the problem of loss of specialization
> (restriction) due to inheritance subsumption:
>
>
> http://stackoverflow.com/questions/8360413/selectively-disable-subsumption-in-scala-correctly-type-list-contains
>
> Afaics, the generalized, paradigmatic solution to the above linked problem
> is:
>
> List[+A] {
>   def contains[B <: A](x: B)(implicit areEqual: (A, B) => Bool): Bool
> }
>
> where inheritance is not used for the types of A and B. For example, a
> Number can implement a Ordered and an OrderedDivisable typeclass (which can
> be tested with an implicit input parameter), but it doesn't inherit from
> those interfaces. Whereas, the type of A is covariant so that we may assign
> return values of type List[T] which BTW should be intersections of types in
> the container instead of a subsumption of types in the container (as is now
> the case in Scala 2.11).
>
> Again it would be ideal if the future compiler would automatically create
> the apropos areEqual with the requisite match-case boilerplate to extract
> the types from the intersection and call the extant instances of areEqual
> for each type in the intersection.
>
> In other words, it appears the intersection and union types of DOT are
> essential to play correctly with forsaking premature restriction via
> premature inheritance of types. Inheritance should only come into play
> where it is unavoidable due to Liskov Substitution Principle and therein
> the compiler should automatically do the match-case boilerplate for us.
>
> Thoughts please?
>
> On Tuesday, June 16, 2015 at 9:00:25 AM UTC+8, Shelby wrote:
>
>> On further thought, why can't the future compiler expand that boilerplate
>> for us, even the match-case boilerplate (done at caller site thus VM type
>> erasure is irrelevant) where T is an intersection types that each have an
>> implementation of Desired[_] available in the current scope, so then we
>> only need to write:
>>
>> def f[T](a: List[T])(implicit b: Desired[T])
>>
>> Or better yet the sugar where the compiler does the boilerplate internal
>> to the function too:
>>
>> def f(a: List[Desired])
>>
>> It seems Haskell has modularity correct with typeclasses instead of
>> inheritance?
>>
>> On Tuesday, June 16, 2015 at 7:49:11 AM UTC+8, Shelby wrote:
>>>
>>> def f[T](a: List[T], b: Desired[T]) ...
>>>
>>> I note that the Dotty Dependent Object Types calculus is orthogonal to
>>> mixin inheritance modeling because of the potential for overlapping
>>> premature specialization. Also I note that typeclasses are nearly a
>>> complete solution to the Expression Problem and I do not recall which of
>>> the "issues" (are even really issues?) I had enumerated are due to the
>>> typeclass pattern and/or the coinductive type system of Haskell (where _|_
>>> is the Top type, not Bottom as in an inductive language such as Scala):
>>>
>>>
>>> http://www.coolpage.com/copute/dev/docs/Copute/ref/Complete%20solutions%20to%20the%20%93Expression%20Problem.htm
>>>
>>> (luckily I was able to capture the above document from a google cache
>>> after stackoverflow deleted it)
>>>
>>> A typeclass in Scala appears to me to just be a way of specifying an
>>> interface that many types can implement (and types can implement more than
>>> one interface without conflating them with their existential type) and then
>>> providing an implicit function to automatically inject them into the
>>> context where they are used:
>>>
>>>
>>> https://blog.safaribooksonline.com/2013/05/28/scala-type-classes-demystified/
>>>
>>> But as noted in my linked document above, automatic injection for
>>> Haskell doesn't play well with containers and perhaps inheritance (although
>>> perhaps that is due to other factors such as the coinductive type system).
>>>
>>> Thus it appears to me that explicit injection via functional programming
>>> is the most modular. Is the reason I find Haskell so confusing is because
>>> it is obscuring the boilerplate in invisible implicit typing?
>>>
>>> Did we somehow lose the plot along the way with Scala and the concept of
>>> merging functional with object oriented programming?
>>>
>>> I don't know the answer to that question, but here is one rabbit hole I
>>> found:
>>>
>>>
>>> https://apocalisp.wordpress.com/2010/07/02/higher-rank-polymorphism-in-scala/
>>>
>>> My current thinking (subject to change as I learn more) is the Scala
>>> roadmap towards Dependent Object Types is appropriate because it simplifies
>>> to intersections and unions of types, which appears to me to be an
>>> unavoidable consequence of covariant and contravariant container cases. I
>>> am not clear how much of the rest of Scala is not more harmful than needed?
>>>
>>> If the basic syntax and compiler could be radically simplified (thus
>>> hopefully must faster too), perhaps this could make Scala more appealing to
>>> a wider audience and use-cases[1]. Conceptually for the
>>> separation-of-concerns perhaps the other "features" could be done with
>>> macros operating on the AST. Appears by not modeling inheritance in DOT,
>>> this may be the conceptional direction being toyed with?
>>>
>>> I am trying to wrap my head around what would be the idea language for
>>> programming the "web 4.0" which I visualize as unification of app
>>> programming and server programming[1]. It should be light weight, because
>>> one thing that drives many startups away from Java is the heaviness of the
>>> toolset and learning curve as compared to Javascript.
>>>
>>> P.S. there may a lot (≈$millions) of money available to throw at this,
>>> if someone can elucidate the issues and optimal direction succinctly.
>>>
>>> [1] http://www.infoq.com/interviews/bracha-javascript-future
>>>
>>>
>>> On Tuesday, May 12, 2015 at 4:22:59 PM UTC+8, martin wrote:
>>>>
>>>> So, putting types in traits can be a
>>>> premature restriction of their usage.
>>>>
>>>> The alternative to cakes is essentially functional abstraction. Have
>>>> components parameterized by others.
>>>>
>>>  --
> 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.