On May 16, 2011, at 5:11 PM, Mike Samuel wrote: > 2011/5/16 Allen Wirfs-Brock <al...@wirfs-brock.com>: > >> The actual program might be encoded in EBCDIC or Hollerith card codes as >> long as there is a mapping of the characters actually used in that encoding >> to Unicode characters. > > For ES next, why not mandate that all ES harmony source files not > embedded in another language must be encoded using UTF-8. >
You are essentially saying that it would be non-complient to build a ES implementation that could take input directly for a UTF-16 or UTF-32 encoded file. Why? The language definition doesn't care about the external encoding. That's a matter for host environments and implementations to worry about. The current specification already unnecessarily over specifies this. Doing so adds non-essential complication to the specification that I had to tweak for ES5 and will probably have to tweak again for ES.next. Why not just get rid of the unnecessary complication. There are, however, two places we will still have to deal with encoding -- the interpretation of the arguments to eval and the Function constructor. Allen > There is precedent. > > http://golang.org/doc/go_spec.html : > """ > Source code representation > Source code is Unicode text encoded in UTF-8. > """ > > http://code.google.com/closure/templates/docs/concepts.html > """ > All Soy files must be encoded in UTF-8. > """ > > And some that establish UTF-8 as a default. > http://www.ietf.org/rfc/rfc4627.txt > """ > JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. > """ > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
