Re: LSP

Shelby <[email protected]>
Newsgroups gmane.comp.lang.scala
Message-ID <[email protected]>
On Saturday, June 20, 2015 at 3:36:01 AM UTC+8, Shelby wrote:

> [3] 
> http://stackoverflow.com/questions/7266596/why-avoid-subtyping/8352969#8352969
>

Reviewing the discussion[5] linked from one of the comments I made in the 
above cited reference, and the linked discussion within that[6], I got off 
to thinking that representing S-modularity in Haskell may be more fugly 
because heterogeneous types can't be naturally encoded as unions in the 
type system and instead must be simulated with HList and afaik collections 
can't be covariant on a universal type parameter?

Then it occurred to me that a union of types which per my proposed idea for 
compiler assisted S-modularity (c.f. my idea in the thread, "The cake’s 
problem, dotty design and the approach to modularity") is not intended to 
contain subtypes could also include a collection, i.e. a parameterized 
type, that allows subtypes because it is covariant on its type parameter. 
Thus if the compiler is automatically doing the boilerplate as I proposed 
in the cake problem thread, it would somehow have to know how to distribute 
an interface across a parameterized type. Then I refer back to the 
observation I made in [3] that category theory preserves function 
composition on parameterized types, e.g. if the interface in question 
results with a modification of the input then such a compiler could 
automatically supply the boilerplate for a monadic parameterized type.

Conclusion is we will need to build category theory into our parameterized 
types and compiler if we want to eliminate boilerplate along with true 
S-modularity. Haskell seems to be much further along, but maybe sacrificing 
the terseness of S-modularity in exchange for terseness of I-modularity 
with its global inference, coinductive type system.

P.S. the lazy by default evaluation strategy of Haskell gains benefits of 
functional composition (without the deforestation that would be required 
with Scala's eager default) at the expense of runtime non-determinism[7] 
and the optimal balance may be category theory[8].

[5] 
https://groups.google.com/forum/#!msg/scala-language/PIhmEeMg-Ms/3AE0udamW5EJ 


[6] 
http://scala-language.1934581.n4.nabble.com/scala-usefulness-of-OOP-tp2000320p2000380.html

[7] 
http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html#4642367335333855323
     
https://existentialtype.wordpress.com/2011/04/24/the-real-point-of-laziness/

[8] 
http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html#3997003365498848881

-- 
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.