Oh look, another language (ceylon)
rosuav at gmail.com
Tue Nov 19 03:54:57 CET 2013
On Tue, Nov 19, 2013 at 1:13 PM, Steven D'Aprano <steve at 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
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 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
However, Ceylon can actually be implemented on multiple backends (Java
"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.
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
bug-compatibility stupid-code that encodes all strings UTF-16 before
indexing into them). It would be an overall improvement, methinks.
More information about the Python-list