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

Reading this thread (and the linked Scalable Component Abstractions paper) 
is my first exposure to the "Cake pattern". Gulp. Burp.

I try to search for a generative essence of each issue I study. I am 
thinking (Dunning-Kruger effect?) the more general premature restriction is 
requiring types implement interfaces, i.e. the more general notion of an 
existential type 
(http://stackoverflow.com/questions/292274/what-is-an-existential-type/30837163#30837163).

For example, afaik a function which requires a type with a specific 
interface can only be adapted to other types by using the hack "pimp my 
library" pattern in Scala:

implicit pimp(a: Other) = new Desired ...
def f(a: Desired) ...

And "pimp my library" doesn't play well with containers:

def f(a: List[Desired]) ...

Whereas, the modular design is inversion-of-control where the desired 
interface dependency is injected orthogonal to the other types the caller 
may possess:

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.