[Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

Sat Feb 13 07:31:52 UTC 2016

>I never understood SML's module system. [...] but I never found an
explanation "why" they were doing it.

http://stackoverflow.com/questions/23006951/encoding-standard-ml-modules-in-oo
http://homepages.inf.ed.ac.uk/mfourman/teaching/mlCourse/notes/sml-modules.html
https://existentialtype.wordpress.com/2011/04/16/modules-matter-most/
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/ckcusvi?context=1

Some quotes from http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf
- ML Modules and Haskell Type Classes: A Constructive Comparison

5.1

>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.

>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.)

>Signatures in ML are essentially anonymous because named signatures can be
removed from the language without losing expressiveness. Haskell type
classes cannot be anonymous.

>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.

>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. (
http://research.microsoft.com/en-us/um/people/simonpj/papers/assoc-types/at-syns.pdf
<--- probably mean this paper but I don't totally get how this brings about
abstraction)

>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)

5.2

>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.

>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.

>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.

>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.

----

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.

>From http://www-plan.cs.colorado.edu/diwan/class-papers/ML-doc.pdf in 3.1
"The Modules System" by Harper, the emphasis in the opening paragraph is
educative in where the priorities are:

>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.

>ML's conception of a program unit is that it is a reified environment.

>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.

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

HTH

On Sat, Feb 13, 2016 at 1:03 AM, Joachim Durchholz <jo at durchholz.org> wrote:

> Am 13.02.2016 um 07:11 schrieb Rustom Mody:
>
>> I would have thought that SML would be the one which had the most
>> sophisticated module-sublanguage.  Would be interested to know how SML and
>> Java stack up against each other in that respect.
>>
>
> 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.
>
> 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.
> 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.
>
> [Please don't mail directly and CC to Haskell-cafe, this defeats my
> mailer's "reply to list" function.]
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160213/873aa9e7/attachment.html>