Jonathan Lang writes:
> Smylers wrote:
>
> > Jonathan Lang writes:
> >
> > > Translating this to perl 6, I'm hoping that perl6 is smart enough
> > > to let me say:
> > >
> > > s(pattern) { doit() }
> > >
> > > Instead of
> > >
> > > s(pattern) { { doit() } }
> >
> > That special case is nasty if you don't know about it -- you
> > inadvertently execute as code something which you just expected to
> > be a string. Not a good trap to have in the language.
>
> If you expected it to be a string, why did you use curly braces?
Because it isn't possible to learn of all Perl (5 or 6) in one go. And
in general you learn rules before exceptions to rules.
In general in Perl the replacement part of a substitution is a string,
one that takes interpolation like double-quoted strings do.
In general in Perl if the default delimiter for something is
inconvenient you can pick a different delimiter -- this includes
patterns, and also strings. And if you pick any sort of brackets for
your delimiters then they match -- which is handy, cos it means that
they can still be used even if the string inside contains some of those
brackets.
So it's quite possible for somebody to have picked up all the above, and
have got used to using C<qq[long string]> or C<qq{long string}> when he
wishes to quote long strings. The form with braces has the advantage
that they are relatively uncommon in text (and HTML, and SQL, and many
other typically encountered long strings).
At which point if he wants to do substitution with slashes in at least
one of the pattern or the replacement text (perhaps it's a URL or a
filename) then he's likely to pick some other arbitrary characters for
doing the quoting. And braces seem as likely to be picked as anything
else. Unless he specifically knows about an exception there's no reason
not to pick them.
I refer simply to "Perl" above. The above situation could just as
easily arise (or already have arisen) in Perl 5 -- in which case the
programmer's expectations would've been met and the code interpreted
fine. Your proposal would make that no longer the case in Perl 6.
And, apart from people learning Perl fresh, there's also a large number
of existing Perl 5 programmers who also won't be expecting this
exception.
Yes, Perl 6 isn't supposed to be compatible with Perl 5, and obviously a
Perl 5 coder is going to have to learn lots of new things anyway. But
usually they are significantly different, or the old way of doing things
will be a syntax error. This is a situation where the old syntax
continues to work but does something quite different.
That's unfortunate, but probably liveable with in general. But in this
particular case the particular behaviour involves _executing as Perl
code something which the programmer never intended to be code in the
first place_. That's crazily dangerous.
It's like having a Perl 5 to Perl 6 translator that randomly sticks
"eval" statements in front of some of your double-quoted strings.
> While I'm completely on board with the idea that _pattern_ delimiters
> shouldn't affect the _pattern's_ semantics, the second half of the
> search-and-replace syntax isn't a pattern. Conceptually, it's either
> a string or an expression that returns a string.
Sure. Or rather, it's a string (but braces inside strings can be used
to embed expressions in them).
To be consistent your proposal should also suggest that these become
equivalent:
* "{ function() }"
* qq[ {function() }]
* qq{ function() }
* eval "function()"
and, naturally, that these no longer are:
* "string"
* qq[string]
* qq{string}
And if braces are special as delimiters for C<qq> consistency would say
they should be for C<q> as well -- effectively just another way of
spelling C<eval>, but one that doesn't stand out so much.
Smylers
