A request to everyone who wants to discuss this again: please, read the
Backticks thread. Almost everything that can be said about this subject
has already been said before. It is a huge thread, and let's not copy
everything here.



Alexey Trofimenko skribis 2004-11-30 14:34 (+0300):
> but it puts big restrictions on what can be part of the name (actually,  
> thoose which match to <ident> only), so $package'$varname won't work.
> I meant only that your ` can't be replacement to « » because latter allows  
> MUCH more freedom in key names. Actually, only space has special meaning  
> here.

I suggest that you re-read the Backticks thread of April this year.
Summarized in reaction to above snippet: it would not be the only place
where Perl's syntax is optimized for the most common use, but has an
alternative available. I don't recall ever having said that %hash`key
was a *replacement* for %hash«key».

> so, could you be more explicit, what rules your syntax have?

I cannot be much more explicit than in referenced thread, but since you
ask specific questions, I will answer them.

> $a`$b+$c`$d, is it equivalent of
> $a[$b+$c][$d] or $a[$b]+$c[$d] ?

The latter. I intended whetever is seen as a string in Perl 5 $hash{key}
to be valid. In general, that is: any valid identifier (except it may
start with a digit, and optionally have a - before it).

Should you want to play with the syntax, then use Matthijs' patch for
Perl 5, which enables the backticks for hash element selection.

> and I think, polymorphic treating of ` as either {} or [] adds some  
> overhead.. and unstability of your code.

Then have it just for hashes. I don't think it is at all true, though.

> Especially in cases like $a`$b,  
> when compiler just can't see in compiler time, what could be contained in  
> $b - number or string.

I suggested deciding based on the value of the RHS once, but no longer
support that. The decision should be based on the LHS alone, and if the
LHS supports both postcircumfix:«{ }» and postcircumfix:«[ ]», then the
{} wins.

> no spaces allowed, no expressions, and it is always a HASH subscript.

No expressions, but a simple "atomic" scalar variable should be allowed,
as is true for methods too:

    $foo.bar
    $foo.$bar

Re spaces, I don't see any reason to disallow them on either side.
They're allowed around . too.


Juerd

Reply via email to