Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #59331 > unrolled thread

Oh look, another language (ceylon)

Back to article view | Back to comp.lang.python

Contents

  Oh look, another language (ceylon) Neal Becker <ndbecker2@gmail.com> - 2013-11-13 14:33 -0500
    Re: Oh look, another language (ceylon) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-11-17 16:41 +1300
      Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-17 15:10 +1100
      Re: Oh look, another language (ceylon) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-17 05:48 +0000
        Re: Oh look, another language (ceylon) jkn <jkn_gg@nicorp.f9.co.uk> - 2013-11-17 00:34 -0800
      Re: Oh look, another language (ceylon) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-17 12:41 +0000
        Re: Oh look, another language (ceylon) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-11-18 11:33 +1300
          Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-18 11:42 +1100
          Re: Oh look, another language (ceylon) Tim Daneliuk <tundra@tundraware.com> - 2013-11-17 16:48 -0600
            Re: Oh look, another language (ceylon) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-18 23:51 +0000
              Re: Oh look, another language (ceylon) Tim Daneliuk <tundra@tundraware.com> - 2013-11-18 18:31 -0600
      Re: Oh look, another language (ceylon) Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-17 16:18 -0800
        Re: Oh look, another language (ceylon) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-11-18 19:45 +1300
          Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-18 17:56 +1100
            Re: Oh look, another language (ceylon) wxjmfauth@gmail.com - 2013-11-18 01:44 -0800
              Re: Oh look, another language (ceylon) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-18 09:56 +0000
              Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-18 21:04 +1100
                Re: Oh look, another language (ceylon) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-18 13:31 +0000
                  Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-19 00:39 +1100
                  Re: Oh look, another language (ceylon) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-18 14:30 +0000
                    Re: Oh look, another language (ceylon) Dave Angel <davea@davea.name> - 2013-11-18 15:37 -0500
                      Re: Oh look, another language (ceylon) Steven D'Aprano <steve@pearwood.info> - 2013-11-19 02:29 +0000
                    Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-19 10:25 +1100
                      Re: Oh look, another language (ceylon) Steven D'Aprano <steve@pearwood.info> - 2013-11-19 02:13 +0000
                        Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-19 13:54 +1100
                        Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-19 13:56 +1100
                  Re: Oh look, another language (ceylon) wxjmfauth@gmail.com - 2013-11-19 01:10 -0800
                    Re: Oh look, another language (ceylon) Bob Martin <bob.martin@excite.com> - 2013-11-20 08:19 +0000
              Re: Oh look, another language (ceylon) Ian Kelly <ian.g.kelly@gmail.com> - 2013-11-18 05:29 -0700
              Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-18 23:36 +1100
                Re: Oh look, another language (ceylon) Piet van Oostrum <piet@vanoostrum.org> - 2013-11-18 10:31 -0400
                  Re: Oh look, another language (ceylon) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-18 15:06 +0000
          Re: Oh look, another language (ceylon) Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-18 19:33 -0800
            Re: Oh look, another language (ceylon) Steven D'Aprano <steve@pearwood.info> - 2013-11-19 07:00 +0000
              Re: Oh look, another language (ceylon) Chris Angelico <rosuav@gmail.com> - 2013-11-19 18:18 +1100
              Re: Oh look, another language (ceylon) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-11-20 18:25 +1300
    Re: Oh look, another language (ceylon) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-18 14:56 +0000

Page 2 of 2 — ← Prev page 1 [2]

#59904

On 18 Nov 2013 14:30:54 GMT, Steven D'Aprano 
<steve+comp.lang.python@pearwood.info> wrote:
> - 15 bits for a length.

> 15 bits give you a maximum length of 32767. There are ways around 
that. 
> E.g. a length of 0 through 32766 means exactly what it says; a 
length of 
> 32767 means that the next two bytes are part of the length too, 
giving 
> you a maximum of 4294967295 characters per string. That's an 8GB 
string. 
> Surely big enough for anyone :-)

If you use nearly all of the possible 2 byte values then adding 2 
more bytes won't give you anywhere near 4 bI'll ion characters. 
You're perhaps thinking of bringing in four more bytes when the 
length exceeds 32k.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#59933

On Mon, 18 Nov 2013 15:37:12 -0500, Dave Angel wrote:

> If you use nearly all of the possible 2 byte values then adding 2 more
> bytes won't give you anywhere near 4 bI'll ion characters. You're
> perhaps thinking of bringing in four more bytes when the length exceeds
> 32k.

Yep, I screwed up. Thanks for the correction.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#59918

On Tue, Nov 19, 2013 at 1:30 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I suppose that's not terrible, except for the O(n) string operations
> which is just dumb. Yes, it's better than buggy, broken strings. But
> still dumb, because those aren't the only choices. For example, for the
> sake of an extra two bytes at the start of each string, they could store
> a flag and a length:

True, but I suspect that _any_ variance from JS strings would have
significant impact on the performance of everything that crosses the
boundary. If anything, I'd be looking at a permanent 32-bit shim on
the string (rather than the 16-or-32-bit that you describe, or the
16-or-48-bit that Dave clarifies your theory as needing); that would
allow strings up to 2GB (31 bits of pure binary length), and exceeding
that could just raise a RuntimeError. Then, passing any string to a JS
method would simply mean trimming off the first two code units.

But the problem is also with strings coming back from JS. Every time
you get something crossing from JS to Ceylon, you have to walk it,
count up its length, and see if it has any surrogates (and somehow
deal with mismatched surrogates). Every string, even if all you're
going to do is give it straight back to JS in the next line of code.
Potentially quite expensive, and surprisingly so - as opposed to
simply saying "string indexing can be slow on large strings", which
puts the cost against a visible line of code.

ChrisA

[toc] | [prev] | [next] | [standalone]

#59931

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.

Since the Ceylon compiler controls what Javascript operations get called 
(the user never writes any Javascript directly), the compiler can tell 
which operations potentially add surrogates. Since strings are immutable 
in Ceylon, a slice of a BMP-only string is also BMP-only; concatenating 
two BMP-only strings gives a BMP-only string. I expect that uppercasing 
or lowercasing such strings will also keep the same invariant, but if 
not, well, you already have to walk the string to convert it, walking it 
again should be no more expensive.

The point is not that my off-the-top-of-my-head pseudo-implementation was 
optimal in all details, but that *text strings* should be decent data 
structures with smarts, not dumb arrays of variable-width characters. If 
that means avoiding dumb-array-of-char naive implementations, and writing 
your own, that's part of the compiler writers job.

Python strings can include null bytes, unlike C, even when built on top 
of C. They know their length, unlike C, even when built on top of C. Just 
because the native Java and Javascript string types doesn't do these 
things, doesn't mean that they can't be done in Javascript.


> - as opposed to simply saying "string
> indexing can be slow on large strings", which puts the cost against a
> visible line of code.

For all we know, Ceylon already does something like this, but merely 
doesn't advertise the fact that while it *can* be slow, it can *also* be 
fast. It's an implementation detail, perhaps, much like string 
concatenation in Python officially requires building a new string, but in 
CPython sometimes it can append to the original string.


Still, given that Pike and Python have already solved this problem, and 
have O(1) string indexing operations and length for any Unicode string, 
SMP and BMP, it is a major disappointment that Ceylon doesn't.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#59934

On Tue, Nov 19, 2013 at 1:13 PM, Steven D'Aprano <steve@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

[toc] | [prev] | [next] | [standalone]

#59935

On Tue, Nov 19, 2013 at 1:13 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Still, given that Pike and Python have already solved this problem, and
> have O(1) string indexing operations and length for any Unicode string,
> SMP and BMP, it is a major disappointment that Ceylon doesn't.

And of course, the part that's "solved" here is not the O(1) string
indexing, but the fact that UTF-32 semantics with less memory usage
than UTF-16. It's easy to get perfect indexing semantics if you don't
mind how much space your strings take up.

ChrisA

[toc] | [prev] | [next] | [standalone]

#59966

Le lundi 18 novembre 2013 14:31:33 UTC+1, Steven D'Aprano a écrit :
> 
> 
> ...   choose one of the three bad choices:  ...
> 
> 
> 
> * choose UTF-16 or UTF-8, and have O(n) primitive string operations (like 
> 
> Haskell and, apparently, Ceylon);
> 
> 
> 
> * or UTF-16 without support for the supplementary planes (which makes it 
> 
> virtually UCS-2), like Javascript;
> 
> 
> 
> * choose UTF-32, and use two or four times as much memory as needed.
> 
> 
> 

Nothing can beat the coding schemes endorsed by Unicode.

They are all working on the smallest possible entity
level (Unicode Transformation *Units*) with a unique
set of these entities.

To not forget. A set of characters is an artificial
construction and by nature it can not follow the
logic of a more "natural" set, eg. integers.

jmf

[toc] | [prev] | [next] | [standalone]

#60060

in 710625 20131119 091055 wxjmfauth@gmail.com wrote:
>Le lundi 18 novembre 2013 14:31:33 UTC+1, Steven D'Aprano a =E9crit=A0:
>>
>>
>> ...   choose one of the three bad choices:  ...
>>
>>
>>
>> * choose UTF-16 or UTF-8, and have O(n) primitive string operations (like=
>=20
>>
>> Haskell and, apparently, Ceylon);
>>
>>
>>
>> * or UTF-16 without support for the supplementary planes (which makes it=
>=20
>>
>> virtually UCS-2), like Javascript;
>>
>>
>>
>> * choose UTF-32, and use two or four times as much memory as needed.
>>
>>
>>
>
>Nothing can beat the coding schemes endorsed by Unicode.
>
>They are all working on the smallest possible entity
>level (Unicode Transformation *Units*) with a unique
>set of these entities.
>
>To not forget. 

Is that an egg-corn?  

[toc] | [prev] | [next] | [standalone]

#59857

[Multipart message — attachments visible in raw view] — view raw

On Nov 18, 2013 3:06 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> I'm trying to figure this out. Reading the docs hasn't answered this.
> If each character in a string is a 32-bit Unicode character, and (as
> can be seen in the examples) string indexing and slicing are
> supported, then does string indexing mean counting from the beginning
> to see if there were any surrogate pairs?

The string reference says:

"""Since a String has an underlying UTF-16 encoding, certain operations are
expensive, requiring iteration of the characters of the string. In
particular, size requires iteration of the whole string, and get(), span(),
and segment() require iteration from the beginning of the string to the
given index."""

The get and span operations appear to be equivalent to indexing and slicing.

[toc] | [prev] | [next] | [standalone]

#59859

On Mon, Nov 18, 2013 at 11:29 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>
> On Nov 18, 2013 3:06 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
>>
>> I'm trying to figure this out. Reading the docs hasn't answered this.
>> If each character in a string is a 32-bit Unicode character, and (as
>> can be seen in the examples) string indexing and slicing are
>> supported, then does string indexing mean counting from the beginning
>> to see if there were any surrogate pairs?
>
> The string reference says:
>
> """Since a String has an underlying UTF-16 encoding, certain operations are
> expensive, requiring iteration of the characters of the string. In
> particular, size requires iteration of the whole string, and get(), span(),
> and segment() require iteration from the beginning of the string to the
> given index."""
>
> The get and span operations appear to be equivalent to indexing and slicing.

Right, that's what I was looking for and didn't find. (I was searching
the one-page reference manual rather than reading in detail.) So, yes,
they're O(n) operations. Thanks for hunting that down.

ChrisA

[toc] | [prev] | [next] | [standalone]

#59874

Chris Angelico <rosuav@gmail.com> writes:

> On Mon, Nov 18, 2013 at 11:29 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>
>> On Nov 18, 2013 3:06 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
>>>
>>> I'm trying to figure this out. Reading the docs hasn't answered this.
>>> If each character in a string is a 32-bit Unicode character, and (as
>>> can be seen in the examples) string indexing and slicing are
>>> supported, then does string indexing mean counting from the beginning
>>> to see if there were any surrogate pairs?
>>
>> The string reference says:
>>
>> """Since a String has an underlying UTF-16 encoding, certain operations are
>> expensive, requiring iteration of the characters of the string. In
>> particular, size requires iteration of the whole string, and get(), span(),
>> and segment() require iteration from the beginning of the string to the
>> given index."""
>>
>> The get and span operations appear to be equivalent to indexing and slicing.
>
> Right, that's what I was looking for and didn't find. (I was searching
> the one-page reference manual rather than reading in detail.) So, yes,
> they're O(n) operations. Thanks for hunting that down.
>
> ChrisA

It would be so much better to use the Flexible String Representation.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [next] | [standalone]

#59878

On 18/11/2013 14:31, Piet van Oostrum wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Mon, Nov 18, 2013 at 11:29 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>>
>>> On Nov 18, 2013 3:06 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
>>>>
>>>> I'm trying to figure this out. Reading the docs hasn't answered this.
>>>> If each character in a string is a 32-bit Unicode character, and (as
>>>> can be seen in the examples) string indexing and slicing are
>>>> supported, then does string indexing mean counting from the beginning
>>>> to see if there were any surrogate pairs?
>>>
>>> The string reference says:
>>>
>>> """Since a String has an underlying UTF-16 encoding, certain operations are
>>> expensive, requiring iteration of the characters of the string. In
>>> particular, size requires iteration of the whole string, and get(), span(),
>>> and segment() require iteration from the beginning of the string to the
>>> given index."""
>>>
>>> The get and span operations appear to be equivalent to indexing and slicing.
>>
>> Right, that's what I was looking for and didn't find. (I was searching
>> the one-page reference manual rather than reading in detail.) So, yes,
>> they're O(n) operations. Thanks for hunting that down.
>>
>> ChrisA
>
> It would be so much better to use the Flexible String Representation.
>

I agree but approximately 0.0000000142857% of the world population 
disagrees.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#59936

I've never *really* been crazy about the plus operator
concatenating strings anyhow, however, the semantics of "+"
seem to navigate the "perilous waters of intuition" far
better than "*".

    Addition of numeric types is well defined in maths:
    Take N inputs values and *reduce* them into a single
    value that represents the mathematical summation of
    all inputs.
        
    HOWEVER, 
    
    Addition of strings (concatenation) requires
    interpreting the statement as a more simplistic
    "joining" process of : take N inputs and join them
    together in a *linear fashion* until they become a
    single value.
    
As you might already know the latter is a far less elegant
process, although the transformation remains "sane". Even
though in the first case: with "numeric addition", the
individual inputs are *sacrificed* to the god of maths; and
in the second case: for "string addition", the individual
inputs are *retained*; BOTH implementations of the plus
operator expose a CONSISTENT interface -- and like any good
interface the dirty details are hidden from the caller!

    INTERFACES ARE THE KEY TO CODE INTEGRITY and LONGEVITY!

HOWEVER, HOWEVER. O:-)

There is an inconsistency when applying the "*" operator
between numerics and strings. In the case of numerics the
rules are widely understood and quite logical, HOWEVER, in
the case of "string products", not only are rules missing,
any attempt to create a rule is illogical, AND, we've broken
the consistency of the "*" interface!

    py> "a" * "4"
    'aaaa'
    
Okay, that makes sense, but what about:

    py> "a" * "aaaa"

That will haunt your nightmares!

But even the previous example, whilst quite logical, is
violating the "contract of transformations" and can ONLY
result in subtle bugs, language designer woes, and endless
threads on Pyhon-ideas that result in no elegant solution.

    THERE EXISTS NO PATH TO ELEGANCE VIA GLUTTONY

Operator overloading must be restricted. Same goes for
syntactic sugars. You can only do SO much with a sugar
before it mutates into a salt.

    TOO MUCH OF A GOOD THING... well, ya know!

[toc] | [prev] | [next] | [standalone]

#59955

On Mon, 18 Nov 2013 19:33:01 -0800, Rick Johnson wrote:

> I've never *really* been crazy about the plus operator concatenating
> strings anyhow, however, the semantics of "+" seem to navigate the
> "perilous waters of intuition" far better than "*".
> 
>     Addition of numeric types is well defined in maths: Take N inputs
>     values and *reduce* them into a single value that represents the
>     mathematical summation of all inputs.

Which sum would that be?

Addition of vectors, matrices, quaternions, tensors, something else?

Do you perhaps mean the Whitney Sum?
http://mathworld.wolfram.com/WhitneySum.html

Ah, no, you're talking about addition of Real numbered values, where 
nothing can *possibly* go wrong:

    py> 0.1 + 0.1 + 0.1  == 0.3
    False

Hmmm. Oh well, at least we know that adding 1 to a number is guaranteed 
to make it bigger:

    py> 1e16 + 1 > 1e16 
    False

Surely though, the order you do the addition doesn't matter:

    py> 1.5 + (1.3 + 1.9) == (1.5 + 1.3) + 1.9
    False


Dammit maths, why do you hate us so???


So, explain to me again, what is the *precise* connection between the 
mathematical definition of addition, as we learn about in school, and 
what computers do?


>     HOWEVER,
>     
>     Addition of strings (concatenation) requires interpreting the
>     statement as a more simplistic "joining" process of : take N inputs
>     and join them together in a *linear fashion* until they become a
>     single value.


Ah, you mean like addition in base-1, otherwise known as the unary number 
system, also known as a tally.

So if you want to add (decimal) 3 and 5 using base-1, we would write:

    ||| + |||||

and concatenating the tallies together gives:

    ||||||||


which if I'm not mistaken makes 8 in decimal.


> There is an inconsistency when applying the "*" operator between
> numerics and strings. In the case of numerics the rules are widely
> understood and quite logical, HOWEVER, in the case of "string products",
> not only are rules missing, any attempt to create a rule is illogical,
> AND, we've broken the consistency of the "*" interface!

A foolish consistency is the hobgoblin of little minds.

Just because you can't define a sensible meaning for str * str doesn't 
mean you can't define a sensible meaning for str * int.


>     py> "a" * "4"
>     'aaaa'
>     
> Okay, that makes sense, but what about:
> 
>     py> "a" * "aaaa"
> 
> That will haunt your nightmares!

You're easily terrified if you have nightmares about that. I can't 
imagine what you would do if faced with the M-combinator applied to 
itself.



> But even the previous example, whilst quite logical, is violating the
> "contract of transformations" 

What contract of transformations?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#59960

On Tue, Nov 19, 2013 at 6:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>>     py> "a" * "4"
>>     'aaaa'
>>
>> Okay, that makes sense, but what about:
>>
>>     py> "a" * "aaaa"
>>
>> That will haunt your nightmares!
>
> You're easily terrified if you have nightmares about that. I can't
> imagine what you would do if faced with the M-combinator applied to
> itself.

Not to mention that he has to construct his own nightmares. This not
being PHP, it's unlikely to work quite the way he thinks it does:

>>> "a" * "4"
Traceback (most recent call last):
  File "<pyshell#51>", line 1, in <module>
    "a" * "4"
TypeError: can't multiply sequence by non-int of type 'str'

Unless he has some strange Python interpreter that coalesces
integer-like strings to integers, of course, in which case I
completely understand why he's having nightmares.

ChrisA

[toc] | [prev] | [next] | [standalone]

#60053

Steven D'Aprano wrote:
> Which sum would that be?
> 
> Addition of vectors, matrices, quaternions, tensors, something else?

Considering vectors, multiplying a vector by a scalar
can be thought of as putting n copies of the vector
together nose-to-tail.

That's not very much different from putting n copies
of a string one after another.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#59877

On Wed, 13 Nov 2013 14:33:27 -0500, Neal Becker wrote:

> http://ceylon-lang.org/documentation/1.0/introduction/


I must say there are a few questionable design choices, in my opinion, 
but I am absolutely in love with the following two features:


1) variables are constant by default;

2) the fat arrow operator.


By default, "variables" can only be assigned to once, and then not re-
bound:

String bye = "Adios";        //a value
bye = "Adeu";  //compile error

variable Integer count = 0;  //a variable
count = 1;     //allowed


(I'm not sure how tedious typing "variable" will get, or whether it will 
encourage a more functional-programming approach. But I think that's a 
very exciting idea and kudos to the Ceylon developers for running with 
it!)


Values can be recalculated every time they are used, sort of like mini-
functions, or thunks:

String name { return firstName + " " + lastName; } 

Since this is so common in Ceylon, they have syntactic sugar for it, the 
fat arrow:

String name => firstName + " " + lastName;


If Python steals this notation, we could finally bring an end to the 
arguments about early binding and late binding of default arguments:


def my_function(a=[early, binding, happens, once],
                b=>[late, binding, happens, every, time]
                ):
    ...


Want!

These two features alone may force me to give Ceylon a try.




-- 
Steven

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web