Re: backticks (or slash, maybe)
Sean O'Rourke wrote:
I'm saying division is now defined such that when the numerator is
a hash(-ref), the result is the set of values associated with the
denominator. I've never tried to divide a hash or hashref by
something without it being a bug.
Right...in Perl 5.
In Perl 6, a hash in a numeric context returns the number of entries it
contains. So I can readily imagine:
sub decimate_hash (%hash is rw) {
for 1..%hash/10 {
delete %hash{ pick any(keys %hash) };
}
}
Damian
Re: backticks (or slash, maybe)
Miércoles 14 Abril 2004 14:18, Juerd wrote:
I propose to use ` as a simple hash subscriptor, as an alternative
to {} and . It would only be useable for \w+ keys or perhaps
-?\w+. As with methods, a simple atomic (term exists only in
perlreftut, afaix, but I don't know another word to describe a
simple scalar variable) scalar should be usable too.
If we really need a ultra-huffman encoding for hash subscriptors, I
have always dreamt of being able to do:
%hash/key
$hashref/foo/bar/baz/quux
...
If only because of the filesystem analogy. Because a filesystem is
really just a very big tied hash, isn't it?
The idea would be be to replace the %hash{'key'} notation by the slash
one, thus making {} always mean a closure without nothing to do with
subscripting.
It would work just like with methods so we would have:
%hash/key # like $obj.method
%hash/$key # like $obj.$method
%hash/{ some_func() } # dynamic key
%hash/«key1 key2» # hash slice
%hash/['key', 'key2'] # the same
The benefits I see in terms of clarity are:
* {} means one thing (closure) and just one
* « and » have only two meanings (literal array and hyperoperator)
instead of three
* «a b» and ['a', 'b'] are always substitutable, ever
The cultural assumption of / as a subscripter is further reinforced
with the omnipresence of xpath these days. We could play some tricks
with this, too. A xml library could make every node a tied hash,
effectively embedding a good portion of xpath within perl:
my $price = $doc/books[14]/price;
for $doc/books - $book {
print Price is $book/price and title is $book/title;
}
(scalar and array context with help us to overcome the an xpath
expression always returns a sequence syndrome)
Pushing the analogy a bit too further away, one could hack the grammar
so that a leading / does indicate the root directory in the system
(and a leading ./ indicates the current directory), thus letting me
write:
for /home/angel - $file {
print $file;
}
Which looks cute for shell scripting, althought a bit dangerous maybe.
And so on...
The beauty (?) of this is not so much in that we should play these
tricks, but in that we are reusing a good deal of cultural background
in them.
Oh, and saving a few keystrokes when you are dealing with hashes the
whole day (say, because you are using DBI, or extracting some data
from an XML document, or whatever) is not totally unpleasing.
-angel
Re: backticks (or slash, maybe)
Angel Faus skribis 2004-04-19 22:43 (+0200):
If we really need a ultra-huffman encoding for hash subscriptors, I
have always dreamt of being able to do:
%hash/key
$hashref/foo/bar/baz/quux
...
I'd hate to give up dividing slash. It's one of the few operators that I
sometimes type without whitespace. Simple because 1/10 is good enough
and 1 / 10 is very wide.
Other than that, I like it. But it isn't really doable.
%hash/{ some_func() } # dynamic key
%hash/«key1 key2» # hash slice
%hash/['key', 'key2'] # the same
I think this is not a good idea.
* «a b» and ['a', 'b'] are always substitutable, ever
Only because they are here, doesn't mean they are everywhere.
A xml library could make every node a tied hash, effectively embedding
a good portion of xpath within perl
Hmm... If only the slash weren't used by something extremely important.
for /home/angel - $file {
That would mean giving up // for regexes (i.e. making the m mandatory).
And I think having quotes for strings other than very simple ones
(anything containing a / is not a simple string imho) is good for
readability.
Juerd
Re: backticks (or slash, maybe)
[EMAIL PROTECTED] (Juerd) writes:
Angel Faus skribis 2004-04-19 22:43 (+0200):
If we really need a ultra-huffman encoding for hash subscriptors, I
have always dreamt of being able to do:
%hash/key
$hashref/foo/bar/baz/quux
...
I'd hate to give up dividing slash. It's one of the few operators that I
sometimes type without whitespace. Simple because 1/10 is good enough
and 1 / 10 is very wide.
You can have both, though.
for /home/angel - $file {
That would mean giving up // for regexes (i.e. making the m
mandatory).
Since modifiers have to be up front, and since hash slices won't have
a trailing '/', I don't think there's any ambiguity -- anything ending
in a '/' is a regex, anything otherwise is a hash slice.
/s
package DH;
require Tie::Hash;
@ISA = 'Tie::StdHash';
sub TIEHASH {
return bless {}, 'DH';
}
sub SCALAR {
return shift;
}
sub STORE {
my ($h, $k, $v) = @_;
$h-{$k} = $v;
}
use overload '/' = sub {
my ($x, $y, $rev) = @_;
if (!$rev) {
if (ref $y eq 'ARRAY') {
return [EMAIL PROTECTED]@$y}];
} else {
return $x-{$y};
}
} else {
return $y / keys %$x;
}
};
package main;
my %h;
tie %h, 'DH';
%h = qw(a 1 b 2 c 3);
my $xs = %h / [qw(a c)];
print %h / 'a', \n;
print @$xs\n;
Re: backticks (or slash, maybe)
Sean O'Rourke skribis 2004-04-19 15:11 (-0700): I'd hate to give up dividing slash. It's one of the few operators that I sometimes type without whitespace. Simple because 1/10 is good enough and 1 / 10 is very wide. You can have both, though. But not in a way that makes $foo/$bar divide $foo by $bar, if $foo is a hashref. That would mean giving up // for regexes (i.e. making the m mandatory). Since modifiers have to be up front, and since hash slices won't have a trailing '/', I don't think there's any ambiguity -- anything ending in a '/' is a regex, anything otherwise is a hash slice. I don't understand. Could you give some examples? Is this in the context of bare /path/to/foo, even? Juerd
Re: backticks (or slash, maybe)
[EMAIL PROTECTED] (Juerd) writes:
Sean O'Rourke skribis 2004-04-19 15:11 (-0700):
I'd hate to give up dividing slash. It's one of the few operators that I
sometimes type without whitespace. Simple because 1/10 is good enough
and 1 / 10 is very wide.
You can have both, though.
But not in a way that makes $foo/$bar divide $foo by $bar, if $foo is a
hashref.
I'm saying division is now defined such that when the numerator is
a hash(-ref), the result is the set of values associated with the
denominator. I've never tried to divide a hash or hashref by
something without it being a bug.
That would mean giving up // for regexes (i.e. making the m
mandatory).
Since modifiers have to be up front, and since hash slices won't have
a trailing '/', I don't think there's any ambiguity -- anything ending
in a '/' is a regex, anything otherwise is a hash slice.
I don't understand. Could you give some examples? Is this in the context
of bare /path/to/foo, even?
Sure:
/foo/ # trailing slash -- so it's a regexp (m/foo/)
/foo\/bar/ # trailing slash -- syntax error (m/foo/ bar/)
/foo/a # hash-path -- no trailing slash ($_.{'foo'}{'a'})
/foo\/bar # hash-path -- no trailing slash ($_.{'foo/bar'})
/foo\/ # hash-path -- no trailing slash ($_.{'foo/'})
/s
Re: backticks (or slash, maybe)
On Mon, Apr 19, 2004 at 03:34:13PM -0700, Sean O'Rourke wrote:
in a '/' is a regex, anything otherwise is a hash slice.
I don't understand. Could you give some examples? Is this in the context
of bare /path/to/foo, even?
/foo/ # trailing slash -- so it's a regexp (m/foo/)
/foo\/bar/ # trailing slash -- syntax error (m/foo/ bar/)
/foo/a # hash-path -- no trailing slash ($_.{'foo'}{'a'})
/foo\/bar # hash-path -- no trailing slash ($_.{'foo/bar'})
/foo\/ # hash-path -- no trailing slash ($_.{'foo/'})
I think this is highly ambiguous.
$x = /foo * $bar/and +bar();
would that be:
$x = m/foo* $bar/ (+bar());
or
$x = $_.{'foo'} * $bar.{'and'} + bar();
?
As much as I see the appeal of this syntax, the / is simply too heavily used
already.
--
Matthijs van Duin -- May the Forth be with you!
Re: backticks (or slash, maybe)
Sean O'Rourke skribis 2004-04-19 15:34 (-0700):
I'm saying division is now defined such that when the numerator is
a hash(-ref), the result is the set of values associated with the
denominator. I've never tried to divide a hash or hashref by
something without it being a bug.
I understand now. But that means the meaning of the / is unknown until
runtime, which means $foo/0 can't be a compile time error.
And it doesn't quote the thing after it, which means still doing a lot
of typing.
$foo/bar should be a compile time error (Perl 6 has no barewords) if
$foo is not a hashref, but be $foo{'bar'} if it is. Waiting for runtime
is bad, I think.
/foo/ # trailing slash -- so it's a regexp (m/foo/)
/foo\/bar/ # trailing slash -- syntax error (m/foo/ bar/)
/foo/a # hash-path -- no trailing slash ($_.{'foo'}{'a'})
/foo\/bar # hash-path -- no trailing slash ($_.{'foo/bar'})
/foo\/ # hash-path -- no trailing slash ($_.{'foo/'})
Thanks. Now I'm sure I don't like the bare path idea. After a hash,
perhaps it's doable, and even if -r /etc/passwd is doable, but there
are too many allowed characters in filenames (on my system: any
character except \0 and /).
Juerd
