On Sat, Jun 11, 2005 at 03:38:28AM -0000, David Formosa (aka ? the Platypus) 
: 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__";
: ...
: 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


would actually be the equivalent of


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.


Reply via email to