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: Axel Luttgens <email@hidden>
- Date: Sun, 19 Aug 2001 18:36:20 +0200
- Organization: ---
Paul Berkowitz wrote:
>
On 8/18/01 6:02 PM, I wrote:
>
>
> I can't figure out what the bad logic is that produces {} or "" or 0
>
or,
>
> more probably 'null', when you don't evaluate with 'get' or specify
>
each
>
> item's data type.
>
>
>
>
Actually, only
>
>
{} as string
>
>
evaluates to ""
>
>
I remember some discussion a month or so ago where Chris Nebel told us
>
that
>
there was a bug whereby AS was treating something or other as a record
>
>
instead of as a list. Maybe we're getting something of the sort here.
Wasn't it about dates that may be viewed as records, without having
every flavors of records ?
Now, coming back to the coercion problem, I'm of the opinion it could
really be called a bug: even if there were some kind of warning about
it, for example in the ASLG (but I couldn't find them), it is abnomal
that "{1, Dte's month, 2000} as string" results in an incomplete
evaluation instead of a run-time error.
As every interpreted language, AS surely internally relies on some kind
of general recursive evaluation function for the evaluation of
expressions.
And that function is clearly broken as soon as evaluation of references
are involved.
The question is then: is it broken in other ways too?
And aren't there some other effects of that bug in the evaluation chain
of nested expressions?
On the other hand, there always is a penalty when a language doesn't
strictly adhere to its basic specifications.
1. Programmers have to remember to make unobvious things (isn't the
obvious enough to struggle with?).
2. Code tends to become larger (memory) and less clear (maintenance).
3. As it is the case with every interpreted language, execution time
grows as you code additional steps that the interpretor could (should)
perform internally.
Ah! The latter is somewhat quantifiable:
== SCRIPT'S START =>
-- The timing loops have been removed for clarity.
-- Number of loops for each case: 300,000.
-- With the usual cautions about timing comparisons...
set Dte to {day:1, month:3, year:2000}
-- That's the fully explicit way to get what we want (100 time units)
set X1 to (Dte's day as string) & (Dte's month as string)
& (Dte's year as string)
-- Well, that's unfair for AS, as we need separators too (as in
"1/3/2000"):
-- the fully explicit way would be slower.
-- Deferring evaluation (52)
set X2 to {Dte's day, Dte's month, Dte's year}
set X2 to X2 as string
-- So, letting the interpretor do the job as far as possible remains
better.
-- Ouf! (in french)
-- Dereferencing (58)
set X3 to {get Dte's day, get Dte's month, get Dte's year} as string
-- Seems to be slighty worse.
-- Dereferencing (58)
set X4 to (get {Dte's day, Dte's month, Dte's year}) as string
-- I would have expected a slight speed improvement (too marginal
perhaps).
-- So, deferring evaluation seems to be the less bad choice.
-- But there must still be a time penalty. Let's try to have a guess.
set D to 1
set M to 3
set Y to 2000
-- The "official" way (23)
set X5 to {D,M,Y} as string
-- Deferring (30)
set X6 to {D,M,Y}
set X6 to X6 as string
-- So, 7 time units slower.
-- One may be tempted to infer that being able to directly write
-- set X to {Dte's day, Dte's month, Dte's year} as string
-- would take 45 units only on our time scale (52 - 7).
<= SCRIPT'S END ==
But now back to my original question.
Has AS shown that behavior since the beginning?
Have I lived all those scripting nights in such a perillous way?
And thanks to all who replied.
PS: Sorry, Paul. I didn't check the recipient of my post...