Additional language features

David Herman dherman at
Sat Mar 5 14:38:01 PST 2011

> But I miss the linear algebra library to go with it.

Can you send references to example libraries for other systems that you would like to see?

> Especially for the "binary data" approach, as it's removing an order
> that might be implicitly known - sorry, I don't know how to express that
> better, so I'll make an example:
> // A point or vector in projective geometry - as usually used for 3D
> // and advanced 2D:
> const Vec3D = new StructType({ x: float32, y: float32, z: float32, w:
> float32 });

I'm not sure if the wiki page mentions this, but objects are ordered in JavaScript, and the intention of the spec is to exploit this. The data would be laid out in order, so that for example when copying the data to a WebGL buffer, you would get them in the order they appear in the type.

> My suggestion is to create a "duality" for access, i.e.:
> v = new Vec3D;
> v.x = 1.0;
> v[0] == v.x; // -> true

This seems like a reasonable convenience, and maybe also a way to enforce the ordering of struct fields a little more explicitly in the spec.

(As an aside: part of the purpose of the binary data spec was to avoid casting. By giving programmers a more expressive library of type descriptors, they can create compound types that express the kinds of data needed for applications like WebGL. And we'd really rather avoid providing cast operations, since they expose platform-specific characteristics like endianness, leading to portability hazards. So for that reason, I'm loath to allow struct types to be *cast* to array types. But I don't think there's any harm in allowing indexed access to struct members.)

> => But this would also require that the order of the elements in the
> {...} of the StructType({...}) is 1:1 mapped to the array positions.

As I say, that was already the intention.

> (AFAIK is currently the order of elements in an Object undefined
> although all browsers seem to keep the initialisation order)

This is something we intend to specify explicitly in the next edition of the spec. See:

> And, to make sure that a highly optimized implementation (SIMD
> instructions...) is possible, the language standard should predefine the
> most common types (i.e. Vec2Dfloat, Vec3Dfloat and Vec4Dfloat) and
> supply a library to handle those (especially the scalar product, matrix
> vector product and the matrix matrix product)

Yeah, a matrix library would be nice to have. OTOH, we tend to avoid putting too many libraries in the standard, preferring instead to let the community experiment with libraries. Your point about optimization is good, though: a matrix library could be highly optimized by the JS engines, more so than many other kinds of libraries. Still, in the end it comes down to resources: do we have the time and people to spec the library; do implementors have the resources to implement the library; or does someone have the resources to write an open source implementation that could potentially be shared by the many VM's...

Thanks for your feedback!


More information about the es-discuss mailing list