<div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div dir="ltr"><div class="gmail_default" style>On 19 December 2012 23:05, David Herman <span dir="ltr"><<a href="mailto:dherman@mozilla.com" target="_blank">dherman@mozilla.com</a>></span> wrote:<br>

</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Dec 19, 2012, at 12:59 PM, Andreas Rossberg <<a href="mailto:rossberg@google.com">rossberg@google.com</a>> wrote:<br>


<br>
> 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<br>
<br>
</div>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.</blockquote>

<div><br></div><div style>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.)</div>

<div style><br></div><div style>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br>

</blockquote><div><br></div><div style>I think I disagree that that's an accurate description of what's going on in ML. ;)</div><div style><br></div><div style>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.)</div>

<div style><br></div><div style>One of the nicer aspects of pre-ES6 JavaScript is that it doesn't have too much of that sort of featurism.</div><div style><br></div><div style>/Andreas</div><div style><br></div></div>

</div></div></div>