W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: New full Unicode for ES6 idea

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 20 Feb 2012 12:12:58 -0800
Cc: Gavin Barraclough <barraclough@apple.com>, public-script-coord@w3.org, Anne van Kesteren <annevk@opera.com>, mranney@voxer.com, es-discuss discussion <es-discuss@mozilla.org>
Message-Id: <64613888-0F62-4D62-B966-D705BC8E7F29@wirfs-brock.com>
To: Brendan Eich <brendan@mozilla.com>

On Feb 20, 2012, at 10:52 AM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
> ...
>> Another way to express what I see as the problem with what you are proposing about imposing such string semantics:
>> Could the revised ECMAScript be used to implement a language that had similar but not identical semantic rules to those you are suggested for ES strings.  My sense is that if we went down the path you are suggesting, such a implementation would have to use binary data arrays for all of its internal string processing and could not use ES string functions to process them.
> If you mean a metacircular evaluator, I don't think so. Can you show a counterexample?
> If you mean a UTF-transcoder, then yes: binary data / typed arrays are required. That's the right answer.

Not necessarily, metacircular...it could be support for any language that imposes different semantic rules on string elements.

You are essentially saying that a compiler targeting ES for a language X  that includes a string data type that does not confirm to your rules (for example, by allowing occurrences of surrogate code points within string data) could not use ES strings as the target representation of its string data type.  It also could not use the built-in ES string functions in the implementation of language X's built-in functions.  It could not leverage any optimizations that a ES engine may apply to strings and string functions.  Also, values of X's string type can not be directly passed in foreign calls to ES functions. Etc.

Received on Monday, 20 February 2012 20:13:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC