Re: IDL: number types

On Mar 20, 2013, at 9:28 AM, Marcos Caceres wrote:

> Cc'ing Yehuda, as he was the one that brought this up during the TAG meeting this week. He can articulate his concerns and the confusion better…   
> 
>> ...
> 
> I agree - and this is the value of WebIDL. What I meant was that, if we do away with the actual types, we could still leave the algorithms in the spec (or somewhere) for editors to use.  
> 
> What I am trying to understand is what types are being used by authors today and why? For instance, why does the XHR spec really need to use an "unsigned short" for a set of constants that go from 0-4 (instead of an octet)? And so on.   
> 
>>> I think the are potentially helpful, but you could have them as generic prose algorithms and not part of WebIDL itself.
>> 
>> I would be fine with generic prose algorithms in a centralized location,  
>> so they're only done once. But what's the benefit of that over having  
>> them just available in IDL?
> 
> I also don't mind where these things end up, just about their utility and availability. The argument (complaint?) being made, as I understand it, is that the current numeric types in WebIDL don't have equivalents in ES itself (and apparently, this leads to confusion in certain cases - I personally don't get confused, but I can see why other people might).


Let me offer some thought from the ES perspective and experience writing the current specification of most of the ES built-in functions.

First, given the semantics of ES, it is probably a mistake to think about the various WebIDL numeric types as C++/Java/C#/etc. style nominal types.  It is probably better to think of then as  constraints/assertions about the expected ranges of parameters/results.  Such range annotations are useful documentation for both implementers and consumers of the APIs when they accurately describe the real requirements.  However, saying "unsigned short" or "octet" doesn't does help anyone when the real constraint is "Range(0,4)".

A specification issue with all such constraints is what happens when a parameter constraint isn't satisfied.  There seldom is one right answer.  For example, in ES the violation of an Uint32 range constraint might in different situations: truncate to 32-bits, apply a modulo 32 transformation, or throw an exception. Which one is most appropriate is situational and may be mandated by an legacy.

Another issue is when and if to perform coercion among Number/String/Boolean/Object values.  ES provides both automatic and manual coercions among these primitive "types". Regardless of what an WebIDL description says, ES is going to pass as an argument value whatever the caller provided and when the callee function is coded in ES the corresponding paramter values will generally be automatically coerced when operated upon in any manner that requires the coercion.  (A given value might even be coerced to multiple different types).

The important concept is that from a ES programmer's perspective the following generally are all valid ways to pass a numeric argument to a function f:
    f(42)
    f("42")
    f({valueOf: function() {return 42})

It's important that the order in which a function actually performs any such coercions or constraint checks is carefully specified because those operations can have observable side-effects.  We get reduced interoperability if different implementations perform them in differing orders.

In the ES spec. we take care of these issues by having a set of specification level coercion "abstract operations" that a spec. writer is expected to explicitly apply at the appropriate sequence points in the pseudo-code specification.  Everything is explicit in the pseudo-code.

WebIDL tries to automatic the coercions by bundling all the of the parameter coercions into an extremely complex "overload resolution algorithm" which essentially stands between the actual ES call site and entry into the actual target function.

While this is a fair reflection of how web APIs have been historically implemented (using C++ or some other lower level implementation language) it is a terrible match to ES and makes it very difficult to actually implement web APIs using ES code.  The reason is the complication of interposing the overload resolution algorithm between an ES call site and the body to the target ES function.  Using ES5 level semantics there is only one way to do it.  The ES programmer must execute an ES implementation of the overload resolution algorithm as the very first step of each function.  In practice, I'm sure nobody does this because the overload resolution algorithm is too complex to reasonably understand and if you look at it in any specific usage context it does all sorts of things that are probably not necessary in that context.

In ES6, a Proxy over functions might be used to factor the overload resolution algorithm into one common place. But requiring every ES implemented web API to use a WebIDL Proxy will preclude use of important language features such as defining methods using the new class declaration syntax.

So, what's a solution?  I appreciate that the ES specification technique perhaps requires too high of a skill level for a broad set of spec. writers.  So, my solution would be to require all new Web APIs to be specified using ES code (which in some cases may wrap pseudo-code)  The ES code would do all the necessary implicit or explicit argument corrosions using normal ES  coercion code patterns.  The reason for this are:
1.  Web APIs should be designed first for ES.  The best way to do this is to actually do an initial ES implementation and check it's usability.
2.  It is reasonable to expect Web API designers to know ES, if they don't they probably shouldn't designing APIs for ES programmers.
3.  API designer won't specify things (in particular overloads) that are unnatural or hard to implement using ES.
3.  By using ES as the specification language, coercions will occur in a natural ES manner and the Ecma-262 spec. will provide the semantics for implementing such specifications (if they are implemented in a language other than ES.

Allen

Received on Wednesday, 20 March 2013 18:41:08 UTC