Re: String to multiple-item list coercion
Re: String to multiple-item list coercion
- Subject: Re: String to multiple-item list coercion
- From: has <email@hidden>
- Date: Sat, 21 Sep 2002 10:50:58 +0100
[sorry if this is a DP]
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?
>
BTW: my simple testing indicates that "text n thru n" is still about 10%
>
faster than either "character" or "item" (at least on short strings):
>
>
StartTicks()
>
repeat 100000 times
>
--set theResult to item 5 of "abcdefgh" -- 238
>
--set theResult to character 5 of "abcdefgh" -- 238
>
set theResult to text 5 thru 5 of "abcdefgh" -- 213
>
end repeat
>
return {StopTicks(), theResult}
Note: we're talking about microseconds' worth of difference here. 99.999%
of the time, it will make absolutely no difference to overall runtime which
form you use, therefore use the one most appropriate to the task (i.e.
'character' if you're working with strings specifically).
>
>> The ASLG (v1.3.7) indicates that this shouldn't work. I think that this
>
>> behaviour is a bug or, at best, a bad idea.
>
>
>
> I like it. :)
>
>
It was a very hard to find "bug" for me in one of my older libraries.
If you were using 'item' with a view to throwing an exception if the user
passes a string, not a list, then this can be a risky practice (for the
reasons you note: language changes, code breaks). I do this myself
sometimes (with dubious justification at best), but the proper solution
here is likely to be to do type checking to make sure inappropriate data
types don't slip past the front door to begin with.
-------
Paul Berkowitz wrote:
>
> BTW: my simple testing indicates that "text n thru n" is still about 10%
>
> faster than either "character" or "item" (at least on short strings):
>
>
It's much more than 10% difference with long strings, immensely so. Aside
>
from the fact that you'll hit "stack overflow" when you get to about 4060
>
characters or items.
If you mean '(characters i thru j of str) as string', this is voodoo
garbage and should never be used in place of 'text i thru j of str' to
begin with. It's not applicable to this debate in any case. Steve was
using 'text *i* thru *i*' as a direct substitute for 'character i', but the
speed difference for that is absolutely trivial (and y'all know what I'd
say if anyone used it...:p).
--
And:
>
Side issue: this exposes a coercion that feels like a bug to me, but I
>
suppose is intentional.
>
>
set ls to {1, 2, 3, 4, 5, 6}
>
set {a, b, c, d, e} to items of ls
>
-- {1, 2, 3, 4, 5, 6}
Sort out the individual issues here: what you're having a problem with here
is multiple assignment, not coercion or anything else. ie:
set {a, b, c} to {1, 2, 3, 4}
return {a,b,c}
--> {1, 2, 3}
I honestly don't know if it'd be appropriate for the language to insist
both lists be balanced when making assignments like these, but AS never
has. Anyone know how do other languages do it?
-------
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.
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
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.
[And I think I should've included the usual 'obligatory disclaimer' to
cover my back in my initial reply.;]
...
>
> - I think it makes sense for
>
> string and list types to display some behaviours in common. For example,
>
> consider:
>
>
>
> 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;).
>
>> 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.
>
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.:)
--
And:
>
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.
>
That's lots of head-scratching gotchas for newbies.
This might in itself be a good justification for the language to insist on
balanced lists when performing multiple assignments. AS is supposed to make
scripting easy, and one of the ways to do that is to meet users'
expectations as much as possible. Doing something merely because it's
techically correct/possible isn't always sufficient justfication for doing
it.
>
> 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 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.
Like 'repeat with anItem in theList', which assigns anItem a reference to a
list item, rather than the item itself. This behaviour makes sense and is
useful, but also freqently catches out folk who draw assumptions about the
nature of 'anItem'.
Sometimes you can't have it all ways, and AS's designers have inevitably
made tradeoffs between <cough> "intuitive" and usefulness.
-------
Quite a complex discussion, and perhaps some kindly Apple engineer will do
us the favour of bailing us all out.[1]
HTH
has
[1] e.g. Engineer: "Nope, everybody's wrong; it's all done using tiny
gnomes who live in your computer." ;)
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
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.