Re: String to multiple-item list coercion
Re: String to multiple-item list coercion
- Subject: Re: String to multiple-item list coercion
- From: Steven Angier <email@hidden>
- Date: Sat, 21 Sep 2002 22:00:39 +1000
On 21/9/02 7:47 PM, "has" <email@hidden> wrote:
>
Steven Angier wrote:
>
>
> At one time, "Item" was a property of lists only.
>
>
Must've been a really old version of AS. IIRC, 'item of str' worked back in
>
AS1.3.7... maybe older. Don't suppose you know the cutoff point?
No, but if I had to guess it would be when AppleScript made just about
everything coercible to string (e.g. dates, booleans etc.) -- 1.3.x.
>
Steven Angier also wrote:
>
>
>>> set {a, b, c, d, e} to "abcdefgh"
>
>>> return {a, b, c, d, e}
>
>>> --> {"a", "b", "c", "d", "e"}
>
>>
>
>> This isn't a coercion, it's a multiple assignment. Comparable to:
>
>>
>
>> set {a, b, c, d, e} to {"a", "b", "c", "d", "e", "f", "g", "h"}
>
>
>
> No, it's a coercion, THEN a multiple assignment. (How do you suppose you got
>
> an a list of characters to assign in the first place?)
>
>
Actually, I don't think either of us can say for certain what goes on under
>
the surface. We're working on assumptions, based on what we see go in and
>
come out, but have no insight as to the magic in the middle. Only the AS
>
engineers could tell you that.
I think that the "magic in the middle" is called coercion :-)
>
BUT you _don't_ need to convert a string to a list of characters before you
>
can access those characters individually, and there's absolutely nothing in
>
the above example to indicate any conversion ever occurs. And what would
>
the point of doing this be anyway? Its only achievement would be to bog
>
down AS's performance even further without conferring any practical
>
benefit. Lastly, there's no visible sign of this happening - we never see a
>
list of characters ourselves - and visible signs to suggest it doesn't - ie:
>
>
set {a, b, c, d, e} to "abcdefgh"
>
--> "abcdefgh" -- no change here
What were you expecting to see changed? Coercion is casting: turning a copy
of a value into another type for the purposes of evaluating a single
expression. Coercion does not change the original data and the coerced value
is destroyed as soon as the statement is evaluated.
>
So I don't think there's any reason to assume a coercion ever occurs (and
>
several to suggest it shouldn't). What I think you see happening above is:
>
>
set {a, b, c, d, e} to characters of "abcdefgh"
>
>
but with the 'characters of' bit occurring completely out of sight. But I
>
think you're reading far more into it than is needed to explain what's
>
going on.
Yes, it is a coercion to a list of characters. IMO this is a bug. Why not
turn it into a list of words?
>
>> repeat with aChar in aString
>
>> ...
>
>> end repeat
>
>
>
> This is another example of the same bug (assuming that aString is a string).
>
>
I don't agree this is a bug. I can't think of any reason why iterating
>
across a string _shouldn't_ be allowed. It's quite in keeping with the
>
nature of the data structure, and a beneficial behaviour as a whole (though
>
it'd be considerably more beneficial if it were also considerably much
>
faster;).
It's not in keeping with the documentation.
>
>>> The ASLG (v1.3.7) indicates that this shouldn't work.
>
>>
>
>> Does it mention it at all? (I could see 'characters of...', etc. described,
>
>> but I only had a quick flick-through. Did I miss something specific?)
>
>
>
> Page 83 of the ASLG (v1.3.7) states "AppleScript also supports
>
> coercion of a string to a single-item list...".
>
>
Nothing in that statement indicates that 'item of str' shouldn't work.
In the ASLG, "item" is not listed as an element of class string. It is also
not used in any of the examples. This leads me to believe that it is not an
intended feature of the language, but a bug.
>
> Also, the coercion matrix on
>
> page 364 indicates that strings cannot be coerced into multiple-item lists.
>
>
But if no coercion occurs in the first place anyway, and I very much doubt
>
one does myself [see "Occam's Razor"], and even if it did it wouldn't be
>
something the user ever saw and is therefore not their problem, then this
>
statement is quite correct and it's your initial premise that's faulty.
>
Sorry.:)
Users don't see coercions! They're invisible! That's their MO!
>
> And I think that the same underlying AppleScript "bug" is also apparent in:
>
>
[snip handler examples]
>
>
It may not be a "bug", merely a behaviour. Probably one that isn't
>
described nearly well or often enough, mind you.
I think it is unintended behaviour (a.k.a "bug"), related to the others
shown in the code you snipped.
>
Whether it'd be safe to change the language or not is another question,
>
however. Changing an established behaviour always runs the risk of breaking
>
existing scripts. Heck, even fixing bugs in AS can be a risky prospect <g>
>
(consider how many folks use the inappropriate but almost "canonical" 'path
>
to me', for example).
"Path to me" is perfectly appropriate for many situations. Provided you know
how it works, you will never be surprised by it. But this is a whole 'nother
argument.
>
>> I would prefer that too few items set to a list errored the same way that
>
>> too many items does, instead of being coerced to a subset of the list.
>
>
Repeat after me: there is no coercion here. There is no coercion here. :)
I suggest you go and sit in the corner until you know how to coerce :-)
What exactly do you think coercion is?
>
> I agree. One could argue for either behaviour (error or truncation), but its
>
> the inconsistency that you mention that is the real problem.
>
>
It's consistent. It's just not what might be expected.
I will obviously disagree.
>
Sometimes you can't have it all ways, and AS's designers have inevitably
>
made tradeoffs between <cough> "intuitive" and usefulness.
The feature/bug in question was not introduced by the AppleScript designers;
it came at least 8 years later by the hands of the "maintainers". I think it
is more likely that someone dropped a spanner into the object model and
hoped nobody would notice.
Steven Angier
Macscript.com
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.