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

On further thought, why can't the future compiler expand that boilerplate 
for us, even the match-cash 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.