[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: another take on hackers and painters
At 3:25 PM -0500 5/21/03, mcguire@cs.utexas.edu wrote:
>Dan Sugalski <dan@sidhe.org> wrote:
> >[...] and both sides *are* numbers, after all. Why not coerce to types
> >based on value? Seems the logical extension to dynamic typing to me.
>
>What about 1 + "three"? :-)
I'd generally not consider that a number, for two reasons:
1) There are all sorts of localization issues--"three" doesn't mean
much in Taipei.
2) If the parser saw 1 + three in the code stream it wouldn't do the
math, so I'd generally assume that 1 + "three" wouldn't either.
Both statements are language-local--I wouldn't be surprised to find a
language that allowed "three" either as a string constant or bareword
to translate to the number three. I'd expect it wouldn't be as useful
a feature as the more simplistic "if it looks like a number to the
parser, it looks like a number at runtime" rule, but I've not had
reason to deal with a language that does get fancy, so it might be
useful.
Someone sent me private mail that boiled down to "Well, should 1 + '2
* 5' evaluate to 11, then?" which is a separate albeit related
question--should variables with strings in them interpolate at
runtime and be evaluated, either in full or limited form? And,
well... I've used languages like that (DCL, anyone?) and it's
actually quite useful, but that's a case where caution would argue
against it without extra notation. Evaluating "3" as 3 is one thing,
and the worst-case failure mode is reasonably harmless if it's really
wrong. Doing a full eval would make 1 + foo rather nasty if foo
happened to have the string "system('rm -rf /')" in it.
Still, it's all points in an n-dimensional continuum. Different tools
for different jobs, and all that.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk