Aaron Sherman:
# On Sat, 2002-01-26 at 12:01, Simon Cozens wrote:
# > A4 said that there were no barewords in Perl 6. Does this mean that
# > $foo{bar}
# > actually should be written
# > %foo{"bar"}
#
# Hmm... I'm curious, has anyone yet tackled printf("%d{x}",%d{x})? Is
# that a bug or do
On Sat, 2002-01-26 at 12:01, Simon Cozens wrote:
> A4 said that there were no barewords in Perl 6. Does this mean that
> $foo{bar}
> actually should be written
> %foo{"bar"}
Hmm... I'm curious, has anyone yet tackled printf("%d{x}",%d{x})? Is
that a bug or does it produce "n{x}" where n i
On Sun, Jan 27, 2002 at 03:44:07PM -0800, Peter Scott wrote:
> Count me among the crazed whales/mad dolphins/whatever you were referring
> to. It would make it easier to explain to beginners the rules for calling
> functions by eliminating a qualification ("You can leave empty parens off
> onl
At 01:16 PM 1/26/02 -0700, Tom Christiansen wrote:
>There is another way to resolve the ambiguity of foo meaning either
>"foo" or foo() depending on current subroutine visibility. This
>would also extend then to issue of $hash{foo} meaning either
>$hash{foo()} or $hash{"foo"}. Just use parens.
> On 1/27/02 9:57 AM, Simon Cozens wrote:
> > I can't help thinking that requiring quotes will
> > make it all nice and consistent, and completely
> > zap all these edge cases.
>
> Well, it'll sure make the subset of Perl programmers
> who have always quoted hash subscripts anyway (like
> me - us
On 1/27/02 9:57 AM, Simon Cozens wrote:
> I can't help thinking that requiring quotes will make it all nice and
> consistent, and completely zap all these edge cases.
Well, it'll sure make the subset of Perl programmers who have always quoted
hash subscripts anyway (like me--usually with single q
On Sat, Jan 26, 2002 at 10:33:54AM -0800, Peter Scott wrote:
> Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
> won't be because of the "no barewords" rule. If there were such a rule, I
> presume you'd also apply it to the LHS of =>?
It's only a bareword when the parse
Hi,
This is already handled in Perl 5 - which I guess will have
an influence on Perl 6. I doubt Larry is going to force
everyone to quote the hash subscripts (are you Larry? :)
Let a newish (6 < now < 12 months) non professional
(unemployed student ;) Perl programmer, like myself, look
at how h
>Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
>won't be because of the "no barewords" rule. If there were such a rule, I
>presume you'd also apply it to the LHS of =>?
There is another way to resolve the ambiguity of foo meaning either
"foo" or foo() depending on curre
At 05:43 PM 1/26/02 +, Simon Cozens wrote:
>On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote:
> > >%foo{"bar"}
>
>It's bare, and it's a word.
Maybe you want to come up with another term to describe it then... but it
isn't a "bareword" in Perl. Camel III p.64 footnote: "... It
On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote:
> >%foo{"bar"}
It's bare, and it's a word.
I presume you're also happy with these ambiguities:
$foo{shift} vs. $foo{"shift"}
$foo{bar} vs. sub bar() { ... } $foo{bar}
vs. $foo{+bar}
vs. $foo{b
At 05:01 PM 1/26/02 +, Simon Cozens wrote:
>A4 said that there were no barewords in Perl 6. Does this mean that
> $foo{bar}
>actually should be written
> %foo{"bar"}
>?
No. That's not a bareword.
>I'm vaguely hoping that the answer is yes, because then we could treat
>*all* instance
A4 said that there were no barewords in Perl 6. Does this mean that
$foo{bar}
actually should be written
%foo{"bar"}
?
I'm vaguely hoping that the answer is yes, because then we could treat
*all* instances of {...} as a block returning either a closure, a value
for subscripting, or an ano
13 matches
Mail list logo
