Optional argument types

[Dmitry Soshnikov]

On Tue, Sep 25, 2012 at 7:37 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 25 September 2012 15:31, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120925/031db9ee/attachment.html>