Do Anonymous Exports Solve the Backwards Compatibility Problem?

Andreas Rossberg rossberg at google.com
Thu Dec 20 02:52:12 PST 2012


On 19 December 2012 23:05, David Herman <dherman at mozilla.com> wrote:

> On Dec 19, 2012, at 12:59 PM, Andreas Rossberg <rossberg at google.com>
> wrote:
>
> > It's also worth noting that Dave's comparison is somewhat inaccurate.
> The convention is used to name the _primary_ abstract type defined by a
> module, not the _only_ export
>
> That doesn't disagree with what I said. I don't really get the obsession
> with "just one value" either (it's some pretty dubious sophistry, IMO). I
> think the key is when you have a module that provides a primary
> *abstraction*. That's what I said in the meeting.


Yes, but unless it is the _only_ export, you cannot make it anonymous
anyway. That is, even if such an anonymous export feature existed in ML, it
would not be applicable to the case where the "t" convention is used.
(Which is part of the reason why I consider anonymous export very much a
corner case feature.)

I'd also like to note that the main motivation for the convention in Ocaml
(instead of just giving the type a proper name -- which, btw, is what
Standard ML prefers) is to ease the use of modules as arguments to other,
parameterised modules (a.k.a. functors). Such a feature does not even exist
in ES6, so in my mind, the analogy isn't really all that relevant.

In ML that can take the form of a type; in JS it can take the form of a
> constructor, class, and/or function. The concept you end up reaching for is
> unifying the idea of the module and the abstraction itself. That's what
> you're doing with .t in ML and that's what's going on in JS with jQuery,
> node-optimist, etc etc.
>

I think I disagree that that's an accurate description of what's going on
in ML. ;)

More importantly, though, convention is one thing, baking it into the
language another. I've become deeply skeptical of shoe-horning orthogonal
concerns into one "unified" concept at the language level. IME, that
approach invariably leads to baroque, kitchen sink style language
constructs that yet scale poorly to the general use case. (The typical
notion of a class in mainstream OO languages is a perfect example.)

One of the nicer aspects of pre-ES6 JavaScript is that it doesn't have too
much of that sort of featurism.

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121220/de5df812/attachment.html>


More information about the es-discuss mailing list