On Tue, Nov 19, 2013 at 1:13 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, 19 Nov 2013 10:25:00 +1100, Chris Angelico wrote: > >> But the problem is also with strings coming back from JS. > > Just because you call it a "string" in Ceylon, doesn't mean you have to > use the native Javascript string type unchanged.
Indeed not, but there are going to be many MANY cases where a JS string has to become a Ceylon string and vice versa - a lot more often than CPython drops to C. For instance, suppose you run your Ceylon code inside a web browser. Pick up pretty much any piece of JavaScript code from any web page - how much string manipulation does it do, and how much does it call on various DOM methods? In CPython, only a small number of Python functions will end up dropping to C APIs to do their work (and most of those will have to do some manipulation along the way somewhere - eg chances are print()/sys.stdout.write() will eventually have to encode its output to 8-bit before passing it to some byte-oriented underlying stream, so the actual representation of a Python string doesn't matter); in browser-based work, that is inverted. However, Ceylon can actually be implemented on multiple backends (Java and JavaScript listed). It's fully possible that an "application-oriented" backend might use Pike-strings internally, while a "browser-oriented" backend could still use the underlying string representation. The questions are entirely of performance, since it's been guaranteed already to have the same semantics. I would really like to see JavaScript replaced in web browsers, since the ECMAScript folks have stated explicitly (in response to a question from me) that UTF-16 representation *must* stay, for backward compat. JS is a reasonable language - it's not terrible - but it has a number of glaring flaws. Ceylon could potentially be implemented in browsers, using Pike-strings internally, and then someone could write a JavaScript engine that compiles to Ceylon (complete with bug-compatibility stupid-code that encodes all strings UTF-16 before indexing into them). It would be an overall improvement, methinks. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
