need some clarification on compile-time type vs. run-time type

[Brendan Eich]

On Nov 13, 2007, at 10:40 PM, Yuh-Ruey Chen wrote:

> I don't see how that's workable. I mean, technically it is, since |is|
> is a runtime check. But it creates another "incompatibility" between
> type annotations and |is|, and you seem pretty adamant to keep the two
> as coherent as possible.

You're right, there are problems with unifying type and value  
expressions, giving type expressions priority. There may even be  
problems with just type expression syntax as proposed, see http:// 
bugs.ecmascript.org/ticket/309.

>>> d) x instanceof function(p: int): int {} // syntax error?
>>
>> Oh, I see -- on second thought I meant nothing like allowing (d) --
>> sorry. instanceof only takes a value expression on its right, but if
>> that evaluates to a type meta-object, it does something sane and
>> "instance-of"ish.
>
> So I take that |x instanceof {p: int}| won't work, and we'd have to  
> use
> |T = type {p: int}; x instanceof T| instead?

No, the restriction on instanceof comes from ES3, which introduced  
it, along with object initialisers. So x instanceof {p:int} (given a  
binding for 'int' of course) is perfectly valid ES3 and ES4. It  
throws an error in ES3 implementations that do not reserve  
'int' (e.g. SpiderMonkey):

js> int = function (){}
function () {
}
js> x = 42
42
js> x instanceof {p:int}
typein:3: TypeError: invalid 'instanceof' operand ({p:(function () {})})

> I truly doubt there is any code out there with (d). It's a backwards
> incompatibility I'd be willing to break. If there is code out there  
> with
> this, well, the new syntax error should tell them that they're doing
> something really stupid.

You're no doubt right, but why mess with instanceof to take a type  
expression on the right? We still have to work out type expression  
grammar as it intrudes into value expressions to everyone's  
satisfaction. I'd rather keep instanceof's right operand a value  
expression and fry other fish.

> Plenty of discussion going on in ticket 300 concerning this. Ugh, this
> semi-merging of value and type exprs is getting awkward. We're  
> ending up
> with just as many gotchas as we had before at this rate.

Yes, this merge attempt failed already -- it was doomed from the  
start. We need to get type expressions by themselves working. I'm  
pretty sure we can resolve all grammatical issues to-do with type  
expressions, and in that event, allowing a runtime name instead of  
insisting only on a fixed type name will be easy.

> Alright, overview time again. Our current goals are:
> 1) Make |is| less restrictive and allow it accept (some) value exprs.

At this point (some) means name expressions, not restricted to be  
fixed type names.

> 2) Keep |is| and type annotations coherent.

Check, but allowing arbitrary names in type annotations is out. Still  
coherent enough. Call it compromise, if you must -- I think 'is' the  
operator has to compromise because it has too many connotations, and  
different use-cases from type annotations.

> 3) Keep |is| and |instanceof| (somewhat) coherent.

We should define coherence more precisely:

* 'is' takes a type expression on the right, but allows runtime name  
in addition to fixed type name.
* instanceof takes a value expression per ES3 but if its result lacks  
a [[HasInstance]] internal method (new formalism for ES4 needed, I'm  
using ES3 meta-methods here), it checks for a meta-object result and  
does 'is' -- else it throws TypeError.

> 4) Keep all the type operators coherent (to a certain extent).

Let's see:

* 'cast' requires a fixed type expression on the right (no variable  
name)
* 'wrap' and 'like' require fixed type expressions.

> 5) Try not to introduce too many exceptions to the rule a.k.a.  
> gotchas.

Yup.

> Whatever we do to advance one goal, another goal becomes more
> compromised. Maybe we can place priorities on these goals? If we can
> abandon one or two of these in favor of the other goals, this job  
> would
> be much simpler. Need to think on this some more...

Let me know what you think of my interpretations and elaborations  
just above. Thanks,

/be