Re^4: Two more Features Perl 5 Maybe Needs

[LanX]

> with the sigils I would still have to make distinction between a hash and a hash ref

why??? €arr is an arr_ref ¥hash is a hash_ref nothing else. You wouldn't need to use @arr and %hash anymore (but you still could, if you want, it's compatible)

> the only thing I would save is an ocassional -> or %{}

well following PBP I always try to postfix references with _ref, or sometimes with "_aref", "_href" and "_cref". With more sigils there is no need for this anymore. And "occasional" @{} are really ugly to read.

what is easier to read and maintain?

for $x ( @{ $hash_ref->{k1}[2] } { ...}

or

 for $x ( @¥hash{k1}[2] ) { ... }

as a subconscious proof of bad maintainability I forgot a paren in the first example.

You are already used to all these occasional extra symbols, but try to think about beginners who struggle to understand them and eventually switch to other languages.

I can understand that symbols beyond char 127 are not optimal, but the perlparser is so overloaded with antique features and patches that you can't move a millimeter anymore. Just have a look at how complex it is to allow slices with hash- and array-refs! Slicing with Arrow-Operator possible in 5.12?

This could be cleaned up with € and ¥. And contrary to perl6 my approach is still compatible, because you can transform them back into standard perl5.

[chromatic]

Contrary to Perl 6 my approach is still compatible, because you can transform them back into standard Perl 5.

... until the first time you run into a precedence problem, for example with hash or list slices.

[LanX]

> ... until the first time you run into a precedence problem, for example with hash or list slices.

Don't know what you mean ... all my examples were parenthesized so precedence problems shouldn't occur !?!

There was no example with slices but I think

€ar[1][5..6]    ==  @{ $ar->[1] } [5..6]

shouldn't leave place for ambiguity.

Actually it's practically impossible to implement this with a simple code-filter, (see my first approach) because one can't tell by static parsing where the dereferencing ends ( here the last array-index ) and where to put the closing curly.

Or do you mean it's not necessarily clear at compiletime if the last expression (here [5..6]) is a list and leads therefore to slicing-syntax???

[chromatic]

Don't know what you mean ... all my examples were parenthesized so precedence problems shouldn't occur !?!

I mean exactly:

Actually it's practically impossible to implement this with a simple code-filter, (see my first approach) because one can't tell by static parsing where the dereferencing ends ( here the last array-index ) and where to put the closing curly.

In other words, you're arguing to add more syntax to Perl, syntax that's difficult to type, to make the simple cases easy (except that they're more difficult to type) -- except that the syntax doesn't actually make the difficult cases any easier, because either it's ambiguous to parse because of the precedence and associativity of the new dereferencing operator, or you enforce a fixed amount of dereferencing and have to use the existing syntax to isolate and disambiguate the reference.

I won't say that it's impossible to get this to work, but it's going to be very difficult, and the exceptions are probably going to be difficult to understand, and no one's going to use it.

[Jenda]

Waitasecond. So is your €arr the array referenced by $arr or the array @arr or what??? Or is it a whole different variable? In that case what does each of those mean?

€one = @two;
@one = €two;
@one = @two;
€one = €two;
€one = \@two;

The first is making an alias €one to the array @two? The second copying all values referenced by €two to @one? The third copying all elements of @two to @one? The fourth setting €one to point to the same array €two points to? The fifth god only knows what?

This is one of the cases when I disagree with PBP (it's allowed), I do not use any such suffixes and do not ever remember being bitten by that.

An ocassional @{} is necessary. Just as is an ocassional ( ) in expressions. Suppose you have this @¥hash{foo,bar}[2], what does the @ belong to? Is it @{¥hash{foo,bar}}[2] or @{¥hash{foo,bar}[2]}? Do we want the second element of the array referenced by the value of the ('foo'.$;.'bar') key of the hash referenced by ¥hash or the array referenced by the second element of the hash slice?

I would not worry about what character to use, I'd rather worry about what are all the rules governing the intended use and whether the result is not way too complex.

P.S.: You said you are sometimes using _cref ... looks like you'd need (at least) one more sigil. For the coderefs. And then scalar refs and maybe object refs ...

[LanX]

No, it's not as complicated, €, ¥, £ and ¢ are currency symbols like $. A simple €arr is a scalar which is meant to hold a array_ref. It's identical to $arr! Unlike @arr which has another place in the symbol table, changing $arr also means changing €arr (or ¥arr, there is no typechecking *). Just the dereferencing syntax is different!

€one = @two;
@one = €two;
@one = @two;
€one = €two;
€one = \@two;

# is translated to

$one = @two;
@one = $two;
@one = @two;
$one = $two;
$one = \@two;

> Suppose you have this @¥hash{foo,bar}[2], what does the @ belong to? Is it @{¥hash{foo,bar}}[2] or @{¥hash{foo,bar}[2]}?

the grouping of @€[..] is indented to be the opposit of @$[..], that means "listyfy" the biggest possible part, so it is @ {¥hash{foo,bar}[2]}.

Think of it as

sub aref2list ($) { return  @{ $_[0] } }
aref2list($hash->{foo,bar}[2]);

The first alternative can be achieved as you typed it @{¥hash{foo,bar}}[2] which is identical with  @{ $hash->{foo,bar} }[2]. You can still use curlies for grouping, just the default grouping was changed. and if you want the old default behavior just write  @$hash{foo,bar}[2].

Some remarks::

1. I'd prefer to get rid of this old multi-dimensional hash syntax. With the new sigils there is no need anymore to use it. If we abandon it we can use the notation for slices.

2. I'm not sure anymore if using @€ and %¥ this way is a good choice ... maybe better *€ and *¥, which is closer to perl6. ( or identical? I can't tell ...)

> P.S.: You said you are sometimes using _cref ... looks like you'd need (at least) one more sigil.

Yes, and I think ¢ is a good choice! 8 ) but the benefit of writing  ¢coderef(paras) instead of  $coderef->(paras) alone doesn't justify this discussion. That's why I'm focussing on arrays and hashes!

PS: There seems to be a bug in the board's software. Occasionally previewing ¥ is translated to Â¥ by the cgi. Can't reproduce when and why! I have to correct every symbol manually! : (

UPDATE: (*) To be precise, i can't realize typechecking with a codefilter, but I think it's worth thinking about a runtime typechecking and warning, if the scalar in €arr is an array_ref or not. A (slow) solution could be achieved with tieing the scalar and checking with ref when STORE is called.