On Sat, Jun 11, 2005 at 03:38:28AM -0000, David Formosa (aka ? the Platypus)
wrote:
: From my exprence
: with perl5 and from playing around with pugs I've noticed that when
: eval(Str $evalstring) is used I mostly use it like this (in perl5)
:
: eval "..."; Or
:
: eval <<"__EVALEND__";
: ...
: __EVALEND__
:
: It seems a natural analogy with s:e/.../.../; That I would be able to
: do the following.
:
: q:2:e/.../;
:
: q:2:e:to/__EVALEND__/;
: ...
: __EVALEND__;
There's a couple of little flaws with that line of reasoning.
The first is that there is a construct s:e/.../.../ in Perl 6 that
corresponds to Perl 5's s/.../.../e. There isn't, because it can
be just as easily done with s/.../{...}/ using the curlies as the
generalized expression interpolator. The second problem is that
you're thinking the first occurrence of /e in Perl 5 't actually
implies an eval. It doesn't. All it implies is that the right side
is to be treated as code. So the hypothetical
q:e/1+/
would actually be the equivalent of
(1+)
rather than
eval "1+"
which is why it would produce an error at compile time rather than
run time.
: > I personally don't think string eval should be made too easy|simple.
:
: I would prefer a perl that didn't put speed bumps in the way just
: because it thought that it knew better.
And I would prefer that you not blame perl for my decisions. :-)
Deciding where (and where not) to put the speed bumps is a pretty
good description of my job. It's impossible to have a language without
bumps, so I reserve the right to put the necessary bumps where I think
they'll do the most good and/or least harm.
: The old Unix tradition of
: "Don't prevent something stupid incase someone intelligent finds a
: clever use for it".
In this case we're not preventing something either stupid or clever,
but rather suggesting a clearer way to do the clever thing. It is
not good to have a retroactive /e like Perl 5 did, and in Perl 6 it's
better to have nearby context like {...} than distant context like
:e, especially insofar as {...} can be applied to bits of the string,
while a :e would only be able to operate on the string as a whole.
And quite apart from all that, anything as dangerous as "eval"
really ought not to be hidden in the details. So in the Perl 5
case of /ee where you really are doing an eval for the second /e,
in Perl 6 you have to use {eval...} to make the real eval explicit,
and clearly distinguish the two things that Perl 5 confuses.
Larry
