Re: Coercing a list to string (nasty behaviour IMHO)
Re: Coercing a list to string (nasty behaviour IMHO)
- Subject: Re: Coercing a list to string (nasty behaviour IMHO)
- From: Nigel Garvey <email@hidden>
- Date: Wed, 22 Aug 2001 11:20:22 +0100
Axel Luttgens wrote on Tue, 21 Aug 2001 23:25:06 +0200:
>
-- Example 1
>
on f(X)
>
log {1, X, 2000} as string
>
end f
>
set X to {7, 8}
>
f(X)
>
--> 1782000
[...]
>
First example has just been written to make clear that we are working with
>
references.
No. There are no references here. The value of X is the list {7, 8}.
>
This may even go deeper, as in:
>
>
-- Example 3
>
set X to {5, 6}
>
set Y to {7, 8}
>
set Z to {X, Y}
>
log {1, Z, 2000} as string
>
--> "156782000"
>
>
So, it appears that the interpretor is smart enough to recursively evaluate
>
the components of an expression, going as deep as needed, and to convert
>
references to their contents when needed.
Again, no. The value of Z is {{5, 6}, {7, 8}} - another list - which has
been built in stages by running the three lines before the coercion.
There's no recursive evaluation involved.
>
> References themselves are not coercible types. In a multi-item list,
>
> their interpretation as value or expression is a scripting matter.
>
>
>
> {1, Dte's month, 2000} as string
>
>
>
> ... means "coerce a list containing the number 1, the reference 'Dte's
>
> month', and the number 2000 to a string."
>
>
I think it should be spelled a bit differently:
>
>
... means: "considering that '{1, Dte's month, 2000} as string' is of the
>
form 'Exp as Cls', where Exp appears to be a list and Cls is 'string',
>
(recursively) evaluate each item of the list, convert each evaluated item to
>
a string (if possible), and concatenate resulting items.
>
>
That way, we tend to obtain an operational definition of "coercing a list to
>
a string".
However, the way it *is* spelled is probably as I've described:
>
> The operation fails at the
>
> second item, not because of an AppleScript fault but because the scripter
>
> hasn't properly described what he/she wants. What's intended is:
>
>
>
> {1, Dte's month, 2000}
>
> result as string
>
>
So, programmers have to be explicit about what they want.
>
I fully agree with you :-)
[...]
>
-- Example 5
>
log "1" & item 1 of {3,4} & 2000
>
--> "132000"
>
log {"1", item 1 of {3,4}, 2000} as string
>
--> "1"
>
>
Why doesn't the first line hang at the reference 'item 1 of {3,4}'?
>
Why should the programmer be considered more precise while writing the first
>
line instead of the second one?
Because in the first line, the reference is part of the instruction
itself: 'Concatenate item 1 of {3, 4} to "1".') The second line is an
instruction to do something with a list that contains the reference as a
value of class reference. The list - as written in the line - doesn't
require any evaluation in order to exist and so is interpreted "as is".
It's a passive object.
If you leave off the 'as string', the line becomes an instruction to
*get* a list. The list as written then becomes an active description of
the list that you want and the reference is "evaluated" as part of that.
Put another way, the list *is* the instruction in that line. Running it
produces the result {"1", 3, 2000} which can then be coerced to string as
a separate operation.
The two operations can be combined in one line like so:
(get {"1", item 1 of {3, 4}, 2000}) as string
Alternatively, you can run just the reference first and specify the
result in the list:
item 1 of {3, 4}
{"1", result, 2000} as string
... which combines as:
{"1", get item 1 of {3, 4}, 2000} as string
In both these cases, the written list contains an active ingredient that
AppleScript *has* to evaluate before the actual list can exist.
NG