<div dir="ltr">><span style="font-size:12.8px">I never understood SML's module system. [...]</span><span style="font-size:12.8px"> but I never found an explanation "why" they were doing it.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><a href="http://stackoverflow.com/questions/23006951/encoding-standard-ml-modules-in-oo">http://stackoverflow.com/questions/23006951/encoding-standard-ml-modules-in-oo</a></span><br></div><div><span style="font-size:12.8px"><a href="http://homepages.inf.ed.ac.uk/mfourman/teaching/mlCourse/notes/sml-modules.html">http://homepages.inf.ed.ac.uk/mfourman/teaching/mlCourse/notes/sml-modules.html</a></span><br></div><div><span style="font-size:12.8px"><a href="https://existentialtype.wordpress.com/2011/04/16/modules-matter-most/">https://existentialtype.wordpress.com/2011/04/16/modules-matter-most/</a></span><br></div><div><span style="font-size:12.8px"><a href="https://www.reddit.com/r/haskell/comments/2foggq/why_does_david_turner_say_type_classes_were_a_bad/ckbw3g7">https://www.reddit.com/r/haskell/comments/2foggq/why_does_david_turner_say_type_classes_were_a_bad/ckbw3g7</a></span><br></div><div><span style="font-size:12.8px"><a href="https://www.reddit.com/r/haskell/comments/2foggq/why_does_david_turner_say_type_classes_were_a_bad/ckcusvi?context=1">https://www.reddit.com/r/haskell/comments/2foggq/why_does_david_turner_say_type_classes_were_a_bad/ckcusvi?context=1</a></span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Some quotes from <a href="http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf">http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf</a> - </span>ML Modules and Haskell Type Classes:
A Constructive Comparison</div><div><br></div><div>5.1</div><div><br></div><div>>ML modules provide proper namespace management,
whereas Haskell type classes do not: It is not possible that two different type
classes (in the same Haskell module) declare members of the same name.</div><div><br></div><div>>Signatures and structures in ML may contain
all sorts of language constructs, including substructures. Type classes and
instances in Haskell 98 may contain only methods; extensions to Haskell 98 also
allow type synonyms [6] and data types [5]. However, there exists no extension
that allows nested type classes and instances. (Ed. untrue save for the last bit given extent of use of GHC extensions now.)<br></div><div><br></div><div>>Signatures in ML are essentially anonymous
because named signatures can be removed from the language without losing
expressiveness. Haskell type classes cannot be anonymous.</div><div><br></div><div>>In ML, matching a structure against a
signature is performed by comparing the structure and the signature componentwise;
the names of the structure and the signature—if present at all—do not
matter. This sort of signature matching is often called structural matching. Our
Haskell analog of signature matching is verifying whether the type representing a
structure is an instance of the type class representing the signature. The name of
a class is crucial for this decision. Therefore, we characterize our Haskell analog
of signature matching as nominal.</div><div><br></div><div>>In ML, abstraction is performed by sealing a structure with a translucent
or opaque signature. In Haskell, we perform abstraction inside instance
declarations through abstract associated type synonyms. (<a href="http://research.microsoft.com/en-us/um/people/simonpj/papers/assoc-types/at-syns.pdf">http://research.microsoft.com/en-us/um/people/simonpj/papers/assoc-types/at-syns.pdf</a> <--- probably mean this paper but I don't totally get how this brings about abstraction)</div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span>A sealed structure in ML may look different depending
on whether we view its body from inside or outside the signature seal: Inside,
more values and types may be visible, some types may be concrete, and some
values may have a more polymorphic type than outside. For our Haskell analog,
the same set of types and values is visible and a value has the same type,
regardless of whether we view the instance from inside or outside. (Hand wobble)</div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">5.2</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span>Overloading in Haskell is resolved
implicitly by the compiler. When type classes are simulated with ML modules,
overloading has to be resolved explicitly by the programmer, which leads to
awkward and verbose code.</div><div><br></div><div>>Our current translation scheme is unable to handle constructor
classes because there is not direct counterpart of Haskell’s higher-oder
types in ML. We consider it as interesting future work to investigate whether
an encoding of higher-order types as functors would enable a translation of constructor
classes to ML modules.<br><br></div><div>>Type classes in Haskell may be recursive in the sense that
a class can be used in a constraint for a method of the same class. We cannot
translate such recursive classes to ML because signatures cannot be recursive.</div><div><br></div><div>>Haskell type classes may contain default definitions
for methods. With our approach, such default definitions cannot be
translated properly to ML because signatures specify only the types of value
components and cannot contain implementations of value components.<br><br></div><div>----</div><div><br></div><div>My two cents: focusing on different priorities WRT "abstraction". Typeclasses started out focusing on ad-hoc polymorphism and making that convenient. ML modules started out focusing on abstraction and modularity. They've both (GHC extensions, applicative module functors) been plucking their way into their respective local maxima in terms of what they can do for both.</div><div><br></div><div>From <a href="http://www-plan.cs.colorado.edu/diwan/class-papers/ML-doc.pdf">http://www-plan.cs.colorado.edu/diwan/class-papers/ML-doc.pdf</a> in 3.1 "The Modules System" by Harper, the emphasis in the opening paragraph is educative in where the priorities are:</div><div><br></div><div>>The ability to decompose a large program into a collection of relatively independent
modules with well-defined interfaces is essential to the task of building
and maintaining large programs. The ML modules system supplements
the core language with constructs to facilitate building and maintaining large
programs.</div><div><br></div><div>>ML's conception
of a program unit is that it is a reified environment.</div><div><br></div><div>>Now the fundamental notion underlying program modularization is that the
aim is to partition the environment into chunks that can be manipulated
relatively independently of one another.</div><div><br></div><div>This is not how people think about, talk about, or motivate typeclasses in my experience. I haven't run into anyone fool-hardy enough to suggest a global namespace of unique instances getting provided by the compiler is a vehicle for modularity-via-(abstraction|sealing|etc.) YMMV</div><div><br></div><div><br></div><div>HTH</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 13, 2016 at 1:03 AM, Joachim Durchholz <span dir="ltr"><<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am 13.02.2016 um 07:11 schrieb Rustom Mody:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would have thought that SML would be the one which had the most<br>
sophisticated module-sublanguage.  Would be interested to know how SML and<br>
Java stack up against each other in that respect.<br>
</blockquote>
<br></span>
I never understood SML's module system. The explanations I found were focused on the "what", and very intricate, but I never found an explanation "why" they were doing it. My impression was that it was quite sophisticated in its possibilities to adapt a module during import, but I was never sure whether SML's notion of module was even similar to that in other languages.<br>
<br>
The Java module system isn't spectactular, essentially an import establishes visibility and nothing more (adaptation is separate, and limited to type parameters), and you have a hierarchical namespace.<br>
The only thing that sets Java apart is that the DNS namespace is used as the basis, and that's not even a language rule, just a recommendation; the fascinating thing is that a mere recommendation was enough to make clear who's responsible for fixing a name conflict, and virtually eliminate name conflicts from the Java world.<br>
<br>
[Please don't mail directly and CC to Haskell-cafe, this defeats my mailer's "reply to list" function.]<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Chris Allen<br><div><span style="font-size:12.8000001907349px">Currently working on </span><a href="http://haskellbook.com" target="_blank">http://haskellbook.com</a></div></div></div></div></div></div>
</div>