>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Actually, I've been rethinking this whole mess since last week, and
LW> am seriously considering cranking up the Ruby-o-meter here just a tad.
LW> At the moment I'm inclined to say that the *only* interpolators in
LW> double quotes are:
LW> \n, \t etc.
LW> $foo
LW> @foo[$i]
LW> %foo{$k}
LW> {EXPR}
LW> where the last provides a list context to EXPR. So all of these
LW> would require curlies:
LW> {foo()}
LW> [EMAIL PROTECTED]
LW> {%foo}
LW> {$foo.bar}
LW> {Dog.wag}
LW> {.count}
LW> {~localtime}
LW> [EMAIL PROTECTED]
LW> [EMAIL PROTECTED] '.'}
LW> {$x.as "%10.5d"}
and how do you force scalar context without a scalar() or $() wrapper
around the expression in {}? hard to say whether scalar or list context
is more popular and so would get the huffman prize. i liked @() and $()
for both context control and interpolation with context. it would do all
the above but allow $($foo) instead of {$($foo)} and that saves 2 chars
right there. maybe you could leave {} for list and have $() for scalar
but that is inconsistant and bletcherous too.
so whatever you do, make it symmetrical regarding context. even in perl5
the @{[]} and ${\EXPR} tricks are both list context which is annoying
(not that i use those tricks. i want the p6 style i mention above).
LW> Note that this not only fixes the Perl 6 "% in sprintf" issue, but
LW> also the Perl 5 "@ in email address" issue. It also generalizes the
LW> notion that curlies (almost) always indicate a closure everywhere.
LW> On the other hand, it undoes my stated A12 policy that $x.foo can be
LW> used anywhere $foo can. On the gripping hand, it enables "{.foo}"
LW> where we would have had a lot of "$_.foo", and I think that's an
LW> improvement in readability, at least for people who believe in topics.
so does @() as that is not possible in an email address AFAIK. and that
isn't a closure IMO as it is just an expression with no possibility for
arguments (unless you come up with a way for that! :).
i don't think "$foo.bar" should be a method call. it is too easy to
accidentally write and i bet many will fall into that trap. also it may
generate a very odd runtime (since it is not a method call with a
signature or declaration, it can't (easily?) be checked at compile time)
message that may be hard to actually tie back to the string in question.
so i would say, make interpolating method calls a little harder because
it won't be done as often as simpler stuff (huffman) and it should be
marked off as something completely different than simple variable
interpolation.
so method calls would need the $() or @() wrappers as do all expressions
beyond simple scalar value lookup. that means $foo, @foo[0], $foo[0],
%foo{'bar'} and $foo{'bar'} all interpolate and only their variants
(longer index/key expressions) do as well.
related question: given a ref to a scalar like $foo = \$bar, what is
interpolated in these?
"$foo" # similar to ref interpolation in p5?
"$($foo)" # similar to ref interpolation in p5 as this is
# just the scalar context op
# or does this do a dereference as p5 would do?
"${$foo)" # deref and interpolate that value
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
