Re: set myList to myList & ...(Digest, Vol 2, Issue 493)
Re: set myList to myList & ...(Digest, Vol 2, Issue 493)
- Subject: Re: set myList to myList & ...(Digest, Vol 2, Issue 493)
- From: "Mark J. Reed" <email@hidden>
- Date: Wed, 27 Jul 2005 15:32:58 -0400
Well-said, though I object to the characterization of Python as
non-brain-damaged. It's had its share of severe head trauma along
the way, too. :) All languages are brain-damaged in some way or
another.
I think the least brain-damaged scripting language of the lot is
Ruby. Then again, it's also the youngest. I figure brain
damage will probably set in along the way as it gets more popular and
usable. :)
Perl6 has a lot of promise to rectify the severe brain-damage in Perl5,
but its only partially specified, and the only implementation of that
partial spec is in Haskell and not exactly speedy. I don't
think it will be a viable option for several more years.
On 7/27/05, has <email@hidden> wrote:
Jonathan Levi MD wrote:
>With all respect to has and Paul, and with no wish to be tendentious:
>has quotes a previous writer (himself, possibly: I don't know):
> >>>...you've misread the problem. This has nothing to do with set vs
> >>>copy. It's about the concatenation operator not returning a new
> >>>object in certain situations. Example: [...]
>
>However,
in the example that followed and is reproduced below, the comment
"Wrong!" by (a second) previous writer has to do to with
value-vs-reference, not concatenation:
>
> >>set l to
{1}
(1)
> >>set a to l &
{} (2)
>
>>set b to {} &
l (3)
>
>>
(4)
> >>set l's item 1 to
2 (5)
>
>>log a -->
{1} (6)
> >>log b --> {2} -- Wrong! Should be {1} (7)
(All three quotes are mine.)
Yeesh...
Okay, one last time: the issue has bugger all to do with assignment. I
know how assignment works [1] and I've a pretty shrewd notion of how
concatenation is *supposed* to work, so when I say "the problem is in
the concatenation operator" I do mean "the problem is in the
concatenation operator", and not "I just got off the boat yesterday".
>The
second writer doesn't object that a concatenated value is missing
somewhere: He objects that the value shown by "log b" in line (7) is
the wrong value,
The bug occurs on line 3. Mutating the content
of the object bound to 'l' (line 5) and viewing the value of 'b' (line
7) shows that the object bound to 'l' in line 1 has ended up bound to
'b' in line 3. And the only way that can happen is if the concatenation
operation in line 3 has returned one of its operands *as-is* instead of
*joining* the two operands to create a *new object*. One can
hypothesise on the reason for this odd behaviour - most likely it's an
internal performance optimisation gone awry - but that's by-the-by. The
point is that it's contrary to both common sense and official
documentation would indicate, inconsistent with the operator's other
behaviour and introduces a subtle but unpleasant gotcha into users'
code.
BTW, here's the same example in a non brain-damaged language for comparison:
#!/usr/bin/python
l = [1]
a = l + []
b = [] + l
l[0] = 2
print a # --> [1]
print b # --> [1]
It's a bug, somebody file a report before I run outta possible ways to rephrase it, and let's move on already.
has
[1] It's by-value, where that value is a reference to a heap-allocated object. Just to be precise.
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden