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.