On Tue, Sep 25, 2012 at 7:37 AM, Andreas Rossberg <[email protected]>wrote:
> On 25 September 2012 15:31, Andrea Giammarchi > <[email protected]> wrote: > > That's a hell of a question ... shapes speaking I'd say structural, since > > AFAIK shapes are those boosted up more, isn't it? > > > > That would solve String VS string and Array VS Arguments which is, I > > believe, kinda desired. > > > > Which one would you chose ? > > I assume that most people would probably prefer structural types in > principle, but the problem is that they induce far, far more expensive > runtime checking (easily an order of magnitude). Which is why guards > and trademarks were proposed as a more conservative, nominal > mechanism. > > Generally speaking, retrofitting something type-like on an untyped > language is a *very* hard problem. It has been tried with many > languages and has succeeded for very, very few. You can read lots and > lots of research papers on the subject. > > Fortunately, though, we have top-notch expertise on that topic on > TC39, e.g. Sam TH. ;) > I believe all this is true, and this is why I underlined in the first letter that it's kind of not a "type system" by itself, but only the runtime (yes, runtime) check of the "type-tags" of the argument values. And only the argument values. That's said, introducing the types for casual vars, like: let x :: Number = 10; pushes the responsibility of type carrying to the variable. Thus changing the semantics of the environments model, where the vars don't carry the type, but just reference to the values which carry the type. The line above, if to accept such a "type system" would look like x = "foo" is the error then. Having this "type hints" only for arguments, reduces the problem only for checking the "type-tags" of the arguments, in the function's prologue. And it can be done only in runtime (a function can be applied in different ways, and it's not possible to determined lexically with what "types" of arguments, so only the runtime). By "type-tags" I mean a generic way of testing. Not the `typeof` result, not the `instanceof`. But e.g. the [[NativeBrand]] (for natives) + `instanceof` for custom constructors (the later is just an extension). This gives the ability not to think about it as a "type system", but just as "type hints for arguments". Because again, after the arguments have been checked for the "type-tag" at activation, the argument vars themselves can be rebound to the values of different types, underlining that the variable are not related with the types, and the type annotations for function arguments are just type annotations for checking the types of passed values at only activation. This is kind of scheme I have in mind. I understand all the consequences of (not)optimizations and runtime coasts, but if devs are need these type checks, then they do this anyway manually (and usually in the prologue of the functions) at runtime today. So providing this would make it just implicit. Still with understanding that this is a runtime check, which may decrease the speed of function execution -- but it's already decreased once they do this manually anyway. This model btw is used in PHP as well (type hints only for function arguments, but any var can be reassigned to the value of different type, underlining that this not a "type system"). Today's check to which we can compile our sources with a build-tool is: function foo(String bar, Widget baz) { ... } is: if (bar.[[NativeBrand]] != "String") throw TypeError(...); if (!(baz instanceof Widget)) throw TypeError(...); (it's easy to distinguish which type-tag, either [[NativeBrand]] or the instanceof, to use in order to check which value, natives are known, and all others may be checked with the instanceof). Thus, the later is just an extension, we can check only for natives, not bothering with constructors/classes. Anyways, since it's hard to implement it now and since it may coast too much in respect of VMs optimizations, I think any big project may solve this problem with own implementations with pre-processors/compilers. Thus, some exact syntactic form (if it will be widely adopted by some big community) can be then reused for standardization. P.S.: and to think about type-system in JS is hard, since it doesn't have it. It has just a mess with `typeof` vs. `instanceof` vs. [[NativeBrand]] vs. "ducks" (aka "[[NativeBrand]]-like objects"). And therefore, again, those "type-hints" for args are not about a "type-system". Dmitry
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
