On Tue, Jul 20, 2004 at 08:42:48PM -0400, Uri Guttman wrote:
: 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.
Many expressions are naturally scalar even in list context. Most
operators force scalar context unless you hyper them. In particular,
the new unary operators C<+>, C<~>, and C<?> are specifically designed
to force scalar context in a huffmanly efficient way. Seems a little
silly to duplicate that with something longer.
: 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).
If you want symmetry you can always use a redundant C<*> in C<[EMAIL PROTECTED]>
to go with the redundant C<~> in C<{~$bar}>.
: 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! :).
No, that only helps if you train everyone to always say @(@foo).edu
rather than @foo.edu.
: 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.
That's the direction we're heading.
: 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.
I'm inclining more towards the "only interpolate things that end with
brackets or parens" rule. That would allow $foo.bar() to interpolate,
but not $foo.bar.
: 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
Unlike in Perl 5, Perl 6's references will (by default) autodereference
to their representation in string context. (Not to be confused with
scalar context, where they remain references.) You have to do something
explicit to get the SCALAR(0xdeadbeef) form of output. I don't know what
that syntax is yet.
I probably shouldn't be thinking about that anyway. Can you all tell
I'm putting off writing my OSCON talk? :-)
Larry
