On Thu, Dec 20, 2007 at 03:24:30PM -0800, Michael G Schwern wrote:
: Jonathan Scott Duff wrote:
: > On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote:
: >> I think the issue is that bare vars don't interpolate anymore, but
: >> they still have sigils of their own, so adding to the default interp
: >> syntax is too noisy: ${$var} is not really much improvement over
: >> ${\(expr)}.
: >
: > That's not quite accurate. Scalars interpolate as they always have, but
: > aggregates need to be followed their respective bracketing construct
: > (e.g., "My array contains these items: @array[]")
: >
: > The only "issues" that I see from the original email are:
: > 1. interpolating scalars but not code
: > 2. having to be more careful about what type of string you're using
: >
: > Adriano answered #1 I think: $yaml = Q:!c"{ $key: 42 }";
: >
: > For the second one, if you're really just worried about how prevalent {}
: > appear in double-quotish strings, perhaps @Larry could be persuaded to
: > make them non-interpolative by default. (i.e., the adverb would be
: > required to make them interpolate)
:
: That pretty much sums up my concern.
Well, it's certainly a concern that we thought about a lot when
designing the interpolation originally, so I rather suspect I'm highly
unlikely to change my mind on this one. I've done (and read) a fair
amount of pugs programming since then, and while I can see that from a
Perl 5 perspective it looks like a problem, the situation doesn't arise
so often in practice, and when it does, it almost always results in
a compile-time error (which is a good thing). Perl 6 balances a lot
of subtle issues differently than Perl 5 does, and these all factor into
whether closures should interpolate by default or not. More on that
below.
But I will make one general remark at the start, which is that we
want Perl 6 programmer to look at curlies differently than Perl 5
programmers do. In Perl 5, curlies were overloaded many different
ways, and rarely did they mean a closure by themselves. In Perl 6,
it's almost always the case that bare curlies indicate a closure of
some sort throughout the rest of the language. So the visual and
psychological import of seeing and typing curlies is intentionally
weighted rather differently. Curlies are Perl 6's lambda. Whenever
the user sees curlies, we want them to stop and think. Even the
curlies used by the "built in" control operators are real lambdas
in the abstract, unlike in P5 where they are just hardwired in the
grammar. Bare curlies in regex are now special too.
(Going the other way, you'll note that, in various other spots where
P5 uses curlies such as in \x{...} or $x{foo}, P6 prefers things like
\x[...] or $x<foo> instead, to avoid the visual implication of code.)
: The gyrations to turn off interpolating code... it's nice to know that exists
: but not something I want to ever have to remember or type or even consider my
: quoting context.
In general, I would never use negative form myself. I'd be much more
likely to use qs// than qq:!c//. But since the negative adverbial
forms are already available, it seems better to go ahead and provide
them to work as expected, even if they inspire occasional nausea.
As for the Q base form, it's not really there so much for end-use,
but to provide the bare form from which all other quotes and quote-like
forms are constructed, including forms like rx//. Most user-defined
quotes should just be variants of q//. Or just use bare '' quotes,
since it's still possible to interpolate using \qq[$foo]. This is
huffmanly suitable for quoting large stretches of code that need only
occasional interpolations.
: "Interpolate" vs "not interpolate" is enough, I have more
: important things to worry about while coding. [1]
And, in fact, this can be taken as an argument for making closures
interpolate consistently in double quotes, if they interpolate at all.
To the first approximation, double quotes do all interpolations
and single quotes do none (ignoring backslashes). Positioning the
double quote semantics somewhere in the middle of the spectrum just
means you have to memorize which sequences interpolate by default
and which don't. And we're trying to avoid the need for the user to
memorize arbitrary lists.
: Non-interpolative by default... well I don't exactly want the feature to go
: away either. [2] I can see its uses [3] and it potentially eliminates some
: otherwise convoluted bits of code. And again, I don't want to be thinking
: about flipping interpolation features on and off for each string. Even qs//
: is more than I want to consider. [4]
In general, if you're interpolating a bunch of strings similarly,
you want to think about factoring that out. One of the reasons
we're reserving backticks for users is so they can use them for
any specialty quotes, not just for qqx//.
: Code execution in a string is a very powerful thing, so it's not the sort of
: thing one wants to accidentally trigger. Because it's using a common,
: innocent construct, this strikes me as being all too easy to trigger
: accidentally and unknowingly.
:
: $ pugs -wle 'sub key() { 42 } sub value() { 23 } say "{ key: value }"'
: 23
:
: Whoops.
Seems like you had to work pretty hard to contrive an example
that would parse. P6 is much pickier about random code than P5 is.
Naturally, the nature of what your quoting will influence how often
you might accidentally want literal curlies. C derived languages
want them frequently, but I'd like to point out that normal English
text makes very little use of curlies, and a good deal of the
quoting in Perl programs happens to be of English. Use of curlies
to interpolate into English is very easy to get used to.
And if you are quoting Perl code, you should generally be using
either single quote semantics (usually in a heredoc) or even better,
quasiquotes and macros. Program text munging is fun, but if the text
is headed for an eval(), there's usually a better way. We do allow
text-returning macros in P6, but since those are just source filters
writ small, we encourage people to return ASTs from quasiquotes
instead. That's why they're called "hygeinic macros", after all...
Of course, quoting other languages will have different needs, but
that's why we allow custom quoting. For quoting C you'd probably
want to stick with something that has qs semantics, since C
makes little use of $ but heavy use of {...}.
: It's also worth noting that ${} and @{} adding more context flexibility. It
: appears {} only happens in list context right now, though I admit I'm not up
: on all the new contexts.
We have to reserve ${} as a syntax that catches bogus P5-like uses.
(And in fact, the standard P6 grammar specifically checks for it.)
The use of the very odd " ${foo}bar " in Perl 5 is now dead and gone.
It was one of the stranger uses of curlies borrowed from shell culture,
and syntactically an exceedingly exceptional exception--one of those
things that drives you nuts if you read toke.c in P5.
By contrast, in Perl 6 it falls out naturally from curly interpolation
that you can write it " {$foo}bar " instead, with no special rule,
only the general closure interpolation rule.
Another message pointed out that $() and @() fill much the same role,
but there are problems with relying on those for general expression
interpolation. First, they're defined to fill a syntactic slot
identical to a normal variable. And since normal variables interpolate
by looking for the longest meaningful term that ends in brackets,
$() would do the same. That is, if you write
" $($foo)<bar> "
it's the same as
" {$foo<bar>} "
rather than the desired
" {$foo}<bar> "
The other minor problem is that $() doesn't establish a scope, so a
C<my> declaration inside one would extend outside of the string.
As for the context issue, all interpolations are really in string
context at the end. The decision to make {} provide list context
internally merely makes it easy to interpolate a list. However,
this is transparent to any function that returns a single item.
And you can always use $() to force an explicit scalar context and
interpolate, assuming you are interpolating scalars. Or use + or ~
inside to be explicit.
: [1] Note, I'm the sort of person that uses "" until I have a reason otherwise.
Well, me too, but P6 just provides a different set of reasons. :)
To you and me, the fact that there are single quotes means there's
something there to hide. But other people think the other way and
see double quotes as indicating there's something to interpolate.
I think PBP comes down on that side, but to me, single quotes are a
little harder to see. And maybe there's some bias from seeing double
quotes used non-interpolatively in American English.
: [2] Now being able to turn it ON in a single quoted string would be handy, but
: that's just because of my special case writing a lot of make generating
: code where $ already has meaning.
Indeed, for specialized uses, you probably want to define your
own quotes. S02 gives an example of this, and reserves all of
Unicode above Latin-1 for that purpose. File-scoped declarations
are appropriate for such linguistic shenanigans, especially
if well commented.
: [3] Although a lot of them are handled by the interpolation of $obj.method()
: which makes me happy.
But if you make that work, it doesn't prevent your other $
interpolations from happening if you turn on :s for the entire string.
You really need '\qq[]' in that case, or only interpolate closures, or
even @($foo) (shades of P5).
: [4] Which doesn't appear to be documented in S2.
It is, but by construction, not by exhaustive list. See the sentence
that begins: "You may omit the first colon..."
As a last resort, you can even redefine how double quotes work.
"All is fair if you predeclare." But I think some people would
construe that as antisocial.
Anyway, I'm pretty happy with the current design, and I think most
people will adapt to it pretty easily. And I don't really mind if
they cuss me out a few times while they're learning. :)
Larry
