Re: Backticks (was: Angle quotes and pointy brackets)
Jon Ericson writes: Matthew Walton [EMAIL PROTECTED] writes: James Mastros wrote: Larry Wall wrote: Well, yes, but sometimes the weights change over time, so it doesn't hurt (much) to reevaluate occasionally. But in this case, I think I still prefer to attach the exotic characters to the exotic behaviors, and leave the angles with their customary uses. ...of which they have plenty already. Backtick has exactly one, and not an often-used one at that... I'm fine with axing it. Of course, there are a lot more people in the world then just me. I'm fine with it too. I use it a fair bit but I think it's important to have a very clear mark where you're going to an external program Not when you're writing a quick one-liner. Maybe stdout capturing backticks should be disallowed when using strict, but allowed on the command line.[1] Let me clarify before this thread takes off. We had a long discussion about the role of backticks back in April. Larry weighed in after a long, long consideration. Here's the answer: http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.orgrnum=1clarify before this thread takes off. We had a long discussion about the role of backticks back in April. weighed in after a long, long consideration. Here's the answer:clarify before this thread takes off. We had a long discussion about the role of backticks back in April. weighed in after a long, long consideration. Here's the answer: It says that backticks won't be used at all in Perl 6. That's (the) one key of the keyboard that we're leaving to user-definition. You can spare a few extra characters in a command line script. Don't be afraid. They won't bite. Oh, and anything you have to say about them has already been said back in April. Luke
Re: Backticks (was: Angle quotes and pointy brackets)
Luke Palmer skribis 2004-11-29 16:10 (-0700): http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.orgrnum=1clarify It says that backticks won't be used at all in Perl 6. That's (the) one key of the keyboard that we're leaving to user-definition. It says that, but after saying Leaving aside the use of C`` as a term And that use of backticks is what this subthread appears to be about. As I interpret it, backsticks for qx, unless elsewhere declared gone, are still there. Juerd
Re: Backticks (was: Angle quotes and pointy brackets)
Juerd writes: Luke Palmer skribis 2004-11-29 16:10 (-0700): http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.orgrnum=1clarify It says that backticks won't be used at all in Perl 6. That's (the) one key of the keyboard that we're leaving to user-definition. It says that, but after saying Leaving aside the use of C`` as a term And that use of backticks is what this subthread appears to be about. As I interpret it, backsticks for qx, unless elsewhere declared gone, are still there. Sorry, I misread. Luke
Re: Backticks (was: Angle quotes and pointy brackets)
Juerd writes: Luke Palmer skribis 2004-11-29 16:10 (-0700): It says that backticks won't be used at all in Perl 6. It says that, but after saying Leaving aside the use of C`` as a term And that use of backticks is what this subthread appears to be about. As I interpret it, backsticks for qx, unless elsewhere declared gone, are still there. Although Larry did end by saying that qx probably needs to be completely rethought anyway, so it's quite possible that even though C`` have been left on the side they don't actually get used when putting this thing back together. Smylers
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
community involvement - Was: Re: backticks
Since this horse came back to life, I'm going to give it a good thrashing, and
I've got goons to help me.
I've asked the Phoenix Perl Mongers for their take on the situation. I've posted
a _completely_ unbiased synopsis of the situation. Here are excerpts from the replies:
Tony's take:
Rename Perl 6 to something else.
Tony never posts more than a single line in reply to anything but replies to
everything.
This comment appears to be in response to %foobar, the gullimets, and the behavior
of %foo{shift} changing to mean %foo{'shift'} with no reguard for %foo`bar except to
dismiss it.
Perl 6 i going to end up looking like Morse Code. =)
This was a second, seperate reply, also consisting of a single line. I corrected Tony,
reminding him that Morse Code only has dots and dashes - no gullimets. Ada is the
common analogy, and I reitterated this. Tony then pointed out that he worked at the
Pentagon and many contractors refused to use Ada, holding out with Jovial until after
the Ada push had passed. Funny that now days many government workers hold out
against other languages, refusing to give up Ada.
Eden's take:
I like it, but I don't see why perl can't just adopt the dot like Java and C.
I forgot to mention that . was unusable because Perl 6 autoboxes, so this
misunderstanding
was my fault, not Eden's. Eden went on with a discussion of string concatonation versus
subscripting which made me nod my head. Eden also wanted to know that currying was
still
going to be there - yes, though it is no longer automatic.
Andrew's take:
Scott, I can tell you without hesitation that I /hate/ this. Mostly for
the cons you've already specified.
I agree wholeheartedly here, and with the poster that said, call it
something besides Perl 6.
In a later post, Andrew conceded that %hash`foo isn't really more complex
(I pointed out that it is up in the air whether %hash`foo is more or less
complex), and goes on to say:
True, and I do generally like JavaScript, and do like that syntax
feature. OTOH, it also looks a bit like PHP, and I generally hate PHP.
I've attached my summerized pros and cons at the end for reference. Andrew writes
meticulously clean Perl. He went on to express hope for reduction of complexity
and fewer synonyms in Perl 6.
Doug's take:
Personally, I don't mind typing the {} [edited], so I don't particularly feel the
need for extra syntax. ... I probably just won't use the new syntax.
The new syntax was used to describe %foo`bar specifically. Doug is the head
Perl monger and an unfailing voice of reason.
Victor's take:
I've worked in APL. Terse is *not good*. (Although having
matrix inversion built into the language definitely rocks.)
Sign me stuck in the mud. If the mud is Perl 5.8, it's not
half bad.
Victor wrote a two page email that was interesting and entertaining.
I've attached a slightly edited version to the end of this document.
Michael's take:
... I'd vote against using backtick
in this instance. For one thing, it'll throw my editor's syntax
coloring off, because it assumes that you'll always have a matched
pair. :-)
In general, though, I'm with the group that says there's nothing wrong
with being verbose. I'd rather have a clear %foo{bar()} and
%foo{'bar'} which fit my existing ideas of programming syntax* than
something involving single quote marks.
But, TMTOWTDI, and since I'll never use the single backtick in any
related context, it really doesn't matter for my personal coding.
Michael went on to praise Perl, in its current incarnation, for still being
readable by programmers of other languages, citing ==, =, , and so on,
concluding that standard usage of symbols is a Good Thing, even though it
stretches the use of the symbols a bit.
Michael also writes Java and has shown disposition towards clean code,
having done an excellent presentation on writing tests as a way to
life and increased productivity.
Summary:
I'm doing this as an experiment towards community interest - both generating
it and making it visible.
Unlike PerlMonks or IRC, Phoenix Perl Mongers is a reasonable representation of
people who use Perl - PerlMonks, IRC, and lists tend to attract power users,
academiacs, and hackers.
This makes Phoenix Perl Mongers an interesting test bed. They're largely
professional Perl programmers. They show up to presentations that expose how
other companies are using Perl, share time saving techniques, and explain
how difficult problems were solved. Examples of production code draw
crowds. Academic topics and advanced features are less interesting, but there
is an interest in how things are done outside of the Perl world.
5 people believe they wouldn't use %foo`bar. 1 person likes it. Resolve not
to use it seemed to be the common message. Only a few people hinted that they
would prefer it not be in the language at all, suggesting that there are too
many ways (or agreeing with that point in the Cons). More people cited TMTOWTDI
than complained of too many
Re: backticks
On Fri, 16 Apr 2004 23:45:48 +0200, Juerd wrote:
Jonathan Scott Duff skribis 2004-04-16 15:51 (-0500):
Except that you've put things in this explanation that shouldn't be
there IMHO. The %varnamekey is a special case, but not of getting a
single item from a hash, rather it's a special case of a one element
list generated from evaluating to the element. So, if you remove
that bit, it's the same as the two below just with different syntax.
I think %hashkey key key is best explained as %hash{ key key
key } with implicit curlies, not as an alternative to curlies.
In that case, why aren't you suggesting something more in line with that?
Here's what I'd like to see instead of your suggestion:
%hashkey key key === %hash{key key key}
%hash'key'=== %hash{'key'}
%hashkey=== %hash{key}
That has
* as few keystrokes as perl5's $hash{key}
* delimiters at both ends, so you can even use non-bareword constants
* existing syntax reused in the same way as the variant
* interpolation allowed in the double quoted variant.
That said, I really wish we could keep perl5's $hash{key}. It's obviously a
subscript, and I use constant bareword keys much more frequently than zero-arg
sub/builtin calls in hash subscripts.
--
Peter Haworth [EMAIL PROTECTED]
The capacity of human beings to bore one another seems to be vastly greater
than that of any other animals. some of their most esteemed inventions
have no other apparent purpose, for example, the dinner party of more than
two, the epic poem, and the science of metaphysics. -- H. L. Mencken
Re: backticks
Peter Haworth skribis 2004-04-20 14:56 (+0100):
I think %hashkey key key is best explained as %hash{ key key
key } with implicit curlies, not as an alternative to curlies.
In that case, why aren't you suggesting something more in line with that?
Here's what I'd like to see instead of your suggestion:
%hashkey key key === %hash{key key key}
%hash'key'=== %hash{'key'}
%hashkey=== %hash{key}
That has
* as few keystrokes as perl5's $hash{key}
* delimiters at both ends, so you can even use non-bareword constants
* existing syntax reused in the same way as the variant
* interpolation allowed in the double quoted variant.
Hm, not bad. Doesn't do anything to arrays yet, but I like the idea.
We could maybe even treat hashes and arrays as list operators. That
would allow whitespace, and also:
@array 15
But I liked about the backtick that it's special syntax, which makes it
recognisable. Still, your idea is doable.
Juerd
Re: backticks
Juerd writes:
Peter Haworth skribis 2004-04-20 14:56 (+0100):
I think %hashkey key key is best explained as %hash{ key key
key } with implicit curlies, not as an alternative to curlies.
In that case, why aren't you suggesting something more in line with that?
Here's what I'd like to see instead of your suggestion:
%hashkey key key === %hash{key key key}
%hash'key'=== %hash{'key'}
%hashkey=== %hash{key}
That has
* as few keystrokes as perl5's $hash{key}
* delimiters at both ends, so you can even use non-bareword constants
* existing syntax reused in the same way as the variant
* interpolation allowed in the double quoted variant.
Hm, not bad. Doesn't do anything to arrays yet, but I like the idea.
We could maybe even treat hashes and arrays as list operators. That
would allow whitespace, and also:
@array 15
Yeah, look at that! Wow. What a spectacle. Gee, if it weren't in
severe violation of RFC 28 I'd jump on the idea.
Luke
[1] http://dev.perl.org/perl6/rfc/28.pod
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
Re: backticks
Juerd wrote: Sean O'Rourke skribis 2004-04-15 8:55 (-0700): I find that there are still plenty of contexts in which `` is nice and security is irrelevant. This is the second time in this thread that I read about security being unimportant. I still don't know what to say about it, though I feel like ranting. Security is of course extremely important, but changing a language so that doing anything insecure becomes impossible or at least extremely difficult strikes me as a bit too much nannying. One should of course never accept user input without validating it first - especially stuff coming in over a network - but once you know what's in it, there's nowt wrong with interpolating that into a `` or qx// kind of structure. Well, other than the usual mistakes you can make by forgetting how it's going to interact with the shell, but this really doesn't bother me in the slightest. And as has been said, there's a vast amount of one-liners and short utility scripts out there which use backticks quite happily and safely. As with many things, they're only dangerous if you don't know what you're doing. Probably you know when you can use qx safely, but many, MANY people out there have no clue whatsoever and use qx with interpolation *because* it is easy. Which is exactly why I use it. I'm just not foolish enough to trust the variables I'm interpolating into it unless I've constructed them entirely myself and I know the code that constructs them is bug-free. Having said all that about lack of knowledge though, I'm sure everyone on this list knows about how to deal with tainted data and such things, but there are a lot of fresh Computer Science graduates and other people learning programming who never hear a thing about it. I don't see that as an excuse to turn Perl into a hand-holding nanny language though.
Re: backticks
John Williams skribis 2004-04-16 18:32 (-0600): You didn't answer his question, which is less complicated? Wasn't that a rhetociral question? Juerd
Re: backticks
In a message dated Fri, 16 Apr 2004, Juerd writes: Except for the shocking number of closed-minded people on this list. Stop it, stop it, STOP IT. I'm not asking you to stop voicing your opinion about the discussion at hand--that would be closed-minded, after all. I'm asking you to stop interpreting disagreement as censorship, prejudice, closed-mindedness, or whatever else. It's not. In any case, the argument in re 'what operator to access keywordishly-keyed hashes' is spinning out of control and not getting anywhere. This is precisely why we leave it to Larry (and @Larry) to exercise his benevolent dictatorship. Open issues in regards to what to do with qx() (I'll post my thoughts on that a bit later) and discussion thereof, or on a truly new syntax (other than the ones proposed by Larry and Juerd or a return to Perl 5 ambiguity) or some other brilliant unification in regards to hash keys would I think still be welcomed here. But the argument back and forth--which is prettier, which takes more keystrokes, what's a keystroke, isn't it too much like some-other-language-we-don't-like, no it's more like yet-another-language-we-do-like, etc. ad nauseam is just petty bickering at this point. Can we all just take a deep breath here and let the issue be resolved as time fulfills? No progress is being made at this point. Let it rest. (No, Juerd, I'm not being closed-minded or censoring you. This equally applies to everyone who just wants to restate some new wrinkle of a point already discussed to death.) Trey -- Trey Harris Vice President SAGE -- The System Administrators Guild (www.sage.org) Opinions above are not necessarily those of SAGE.
Re: backticks
Folks, this discussion seems to be spinning. All the points, on both sides, have been made and are being repeated with only slight variation. We've all made our cases--why don't we drop the issue for a while and let Larry ruminate? I think we can all agree that he will give the idea a fair hearing and make a good decision...and I know that I'll be glad if, tomorrow, I *don't* have 30 mails in my box about backticks. : --Dks
Re: backticks
Trey Harris skribis 2004-04-16 12:05 (-0700): I'm asking you to stop interpreting disagreement as censorship, prejudice, closed-mindedness, or whatever else. It's not. I never did interpret disagreement as anything but disagreement, and never said that I think everyone who disagrees is closed-minded. Instead of asking me to stop interpreting disagreement as close-mindedness, ask yourself to stop interpreting closed-minded as disagreeing. There is no 'between the lines' in my messages. Stop looking for it. Juerd
Re: backticks
Brent 'Dax' Royal-Gordon writes:
If the inside of a hash indexer consists entirely of \w characters, it
will be interpreted as the name of a hash key. If you want it to call a
subroutine instead, add a ~ stringifying operator to the beginning of
the call, or a pair of parentheses to the end of it. Simple, clear,
and doesn't shift around based on subroutine definitions. (It's not
what Perl 5 does, but that's Perl 5's fault.)
It's not? With the exception of a leading -, I thought that was
precisely what Perl 5 did. It's not, currently, what Perl 6 does.
Just to recap (I can't tell if you were misunderstanding or not...),
%foo{bar} is equivalent to %foo{bar()} ; %foobar is equivalent to
%foo{'bar'}.
Luke
Re: backticks
Juerd wrote:
Brent 'Dax' Royal-Gordon skribis 2004-04-15 16:56 (-0700):
1. Allow %hashfoo to be typed as %hashfoo. There would be a
conflict with numeric less-than, but we can disambiguate with
whitespace if necessary. After all, we took the same solution with
curlies.
Curlies which, as said, I also don't like typing.
I referred to the curlies only to point out that we're already
disambiguating with whitespace with one of the other indexers.
On a US Dvorak or QWERTY keyboard,
{'foo'} is 9 key presses and 7 characters
foo is 9 key presses and 7 characters
foo is 7 key presses and 5 characters
`foo is 4 key presses and 4 characters
Number of keystrokes isn't our only concern here. This is Perl, not
APL--we care about the size of the language and its intuitiveness too.
(Perhaps not much, but we do.)
I don't like %hash{'foo'} because it's ugly. I don't like %hashfoo
because it's ugly and adds syntax. I don't like %hash`foo because it's
ugly, adds syntax, and looks nothing like an indexing operator. (I'll
revisit this third point soon.) I think it will be easier to fix
%hash{'foo'} or %hashfoo than %hash`foo.
Also important when picking a character is its glyph. ` is light weight,
like the . that we use for methods. I don't want whitespace around this
operator, so the operator must not be fat, like %, @ or #.
I agree that none of those are suitable. That's why I didn't propose them.
The biggest deficiency with the two syntaxes that are already there is
that they both use a pair of characters.
Why is this a deficiency? I've never felt put out by the fact I had to
type an extra character to index an array or hash.
It's also worth noting that, except for Javascript, every language I can
think of uses paired characters for indexing. Perl 5 uses {} and [];
the C-like languages I know use []; Visual Basic (ugh) uses ().
In Javascript, the dot syntax is a clever generalization, allowing the
language's underlying hash-like data structures to look like both hashes
and objects. This isn't the case with Perl.
I dislike XML and HTML because they're a lot of typing (not only because
of the redundancy in the closing tags).
If the proposal was for a syntax like:
index type=hash
var%hash/var
stringfoo/string
/index
I'd be inclined to agree with you. But we're talking about *one*
*extra* *character* here. That's two keys. It's hardly the end of the
world.
Compare:
$foobarbazquux
$foo`bar`baz`quux
In fact, I encourage everyone to type the above two lines a few times.
I'm not arguing that your syntax isn't shorter or easier to type. I'm
arguing that shorter and easier to type aren't enough to justify it.
2. Allow barewords in curlies as a special case. We're already allowing
them on the left side of = (I think), which is even more ambiguous.
It would require some character to disambiguate again, or you have the
unquoted strings that Perl 5 has, but restricted to hash usage. Adding a
sub or method that happens to have the same name as a hash's key should
not break any code.
If the inside of a hash indexer consists entirely of \w characters, it
will be interpreted as the name of a hash key. If you want it to call a
subroutine instead, add a ~ stringifying operator to the beginning of
the call, or a pair of parentheses to the end of it. Simple, clear,
and doesn't shift around based on subroutine definitions. (It's not
what Perl 5 does, but that's Perl 5's fault.)
3. Define hash indexing with a pair to index on the key. This would
allow the syntax %hash{:foo}. (This could even be achieved by making
C~$pair eq $pair.key.)
{:foo} is 8 key presses. A too small step to be worth anything in
practice.
It looks better to me and doesn't add any syntax.
4. Define a bareword-quoting prefix operator (i.e. one that turns the
next \w+ into a string) and use the normal hash indexer, {}. I have
no suggestion for this operator's name, although if you wanted to rip
out the current unary backticks, it could be a candidate:
%hash{`key}.
Same as 3, but with another character.
The only syntax it adds is something more generally useful than your
proposal, in that it could be used anywhere you want a bareword.
To make my position clear: WE DO NOT NEED THREE WAYS TO INDEX A HASH.
I don't really think we need two. All we really need is one way with a
good enough syntax to meet all of our needs.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: backticks
[EMAIL PROTECTED] (Juerd) writes:
I think it has to go because `pwd`, `hostname`, `wget -O - $url`
should not be easier than the purer Perl equivalents and because
``'s interpolation does more harm than good.
I have to disagree with you here. The Perl way is not always the Perl
way -- the beauty of Perl is that it makes it as easy as possible to
take advantage of existing tools. Sometimes this is best done with a
foreign interface like XS, but sometimes it's adequate and easier to
simply shell out and collect the output. I don't see purity as a
good motive here; in fact, rigid purity makes languages like Java and
Smalltalk somewhere between frustrating and useless.
As for it doing more harm than good, do you mean that `` is a security
threat? I find that there are still plenty of contexts in which `` is
nice and security is irrelevant.
Of course, I'd be fine with the slightly longer qx{}...
/s
Re: backticks
On Thu, Apr 15, 2004 at 12:27:12PM -0700, Scott Walters wrote: * Rather than eliciting public comment on %hash`foo (and indeed %hashfoo) the proposal is being rejected out of hand (incidentally, the mantra of the Java community Process seems to be you don't need X, you've got Y, and it took .Net before they woke up and realized that maybe they should consider their community in the community process - after ignoring a universal call for generics for over 5 years it's little wonder .Net ate their cake) Is that: X = `command args` Y = qx/command args/ or: X = %hash'foo Y = %hashfoo I'm not sure which camp you consider to be the pot and which is the kettle. Anyhow, both are grey, not black. X is useful. and Y is an alternative to X. lead to the questions like How useful? and Is there value in having both?. However, the first is an argument to remove a feature that is already present and the second is arguing to add a new feature, so a case can be made for requiring different standards of acceptance for the argument in the two cases. (For the record, I find `command` extremely useful, especially in short scripts, which is where huffman encoding is most valuable. I've never used qx// at all. Nor, in shells, have I ever used $(...) in place of `...`. My fingers got trained long ago and I don't see sufficient benefit to go to the bother of retraining them. I can backwack embedded `'s, and while pulling nested command invokations out into a separate variable assignment is necessary with `` syntax, it is much easier to read even when $( ) syntax makes embedding possible.) --
Re: backticks
Brent 'Dax' Royal-Gordon skribis 2004-04-15 16:56 (-0700):
1. Allow %hashfoo to be typed as %hashfoo. There would be a
conflict with numeric less-than, but we can disambiguate with
whitespace if necessary. After all, we took the same solution with
curlies.
Curlies which, as said, I also don't like typing.
On a US Dvorak or QWERTY keyboard,
{'foo'} is 9 key presses and 7 characters
foo is 9 key presses and 7 characters
foo is 7 key presses and 5 characters
`foo is 4 key presses and 4 characters
Also important when picking a character is its glyph. ` is light weight,
like the . that we use for methods. I don't want whitespace around this
operator, so the operator must not be fat, like %, @ or #.
The biggest deficiency with the two syntaxes that are already there is
that they both use a pair of characters. That is needed because for some
reason every syntax apparently needs to support every feature that Perl
has. That is: slices.
I do not use hash slices often enough to use the arcane syntax all the
time. I like bracketing delimiters for code blocks and for lists of
things. They are not something I wish to type every line.
I dislike XML and HTML because they're a lot of typing (not only because
of the redundancy in the closing tags).
Perl 6's leaving out the parens with if/foreach/while/until is a very
good step in the right direction.
Compare:
$foobarbazquux
$foo`bar`baz`quux
In fact, I encourage everyone to type the above two lines a few times.
2. Allow barewords in curlies as a special case. We're already allowing
them on the left side of = (I think), which is even more ambiguous.
Same problem, and it would mean reversing an earlier decision that in my
opinion was a sane one.
It would require some character to disambiguate again, or you have the
unquoted strings that Perl 5 has, but restricted to hash usage. Adding a
sub or method that happens to have the same name as a hash's key should
not break any code.
3. Define hash indexing with a pair to index on the key. This would
allow the syntax %hash{:foo}. (This could even be achieved by making
C~$pair eq $pair.key.)
{:foo} is 8 key presses. A too small step to be worth anything in
practice.
4. Define a bareword-quoting prefix operator (i.e. one that turns the
next \w+ into a string) and use the normal hash indexer, {}. I have
no suggestion for this operator's name, although if you wanted to rip
out the current unary backticks, it could be a candidate:
%hash{`key}.
Same as 3, but with another character.
Juerd
Re: backticks
Austin Hastings skribis 2004-04-15 19:37 (-0400): I'm sure that if Juerd or someone were to write a PublicHash class, they would cleverly reverse the access so that some collision-unlikely path would get the methods. I'm sure I have explained several times already why I think using the . operator for this purpose is a bad idea. Juerd
Re: backticks
On 2004-04-15 at 19:39:25, Austin Hastings wrote: Of course you used for buffers that were not powers of 2. Had they been powers of 2, you would have used or ~. The fact that you didn't use a power of 2 is pretty questionable. The dread Unix wizards will no doubt have questions for you about this. :-) What are you talking about? The biggest use of modulus is in implementing hashes and when you are implementing hashes you want the number of buckets to be a prime number, not a power of two. -Mark
Re: backticks
On 2004-04-16 at 00:25:51, Brent 'Dax' Royal-Gordon wrote: Number of keystrokes isn't our only concern here. This is Perl, not APL--we care about the size of the language and its intuitiveness too. (Perhaps not much, but we do.) In any case, Perl is far more typable than APL unless you have an APL keyboard *and* lots of experience using it. There's more to typability than number of keystrokes. :) It's also worth noting that, except for Javascript, every language I can think of uses paired characters for indexing. JavaScript does, too. foo.bar is a special case only usable for literal keys that fit the lexical category of word; the usual subscript operator is [] (foo.bar is equivalent to foo['bar']). Visual Basic (ugh) uses (). Hey, don't blame Visual Basic for that. It inherited it from non-visual BASIC, which in turn inherited it from FORTRAN, which was designed to run on systems with 6-bit character sets that had no other brackets. :) I'm not arguing that your syntax isn't shorter or easier to type. I'm arguing that shorter and easier to type aren't enough to justify it. Agreed. To make my position clear: WE DO NOT NEED THREE WAYS TO INDEX A HASH. I don't really think we need two. All we really need is one way with a good enough syntax to meet all of our needs. Amen. -Mark
Re: backticks
On 2004-04-16 at 09:23:44, Mark J. Reed wrote: On 2004-04-15 at 19:39:25, Austin Hastings wrote: Of course you used for buffers that were not powers of 2. Had they been powers of 2, you would have used or ~. The fact that you didn't use a power of 2 is pretty questionable. The dread Unix wizards will no doubt have questions for you about this. :-) What are you talking about? Sorry for the tone - that was uncalled-for on my part. The biggest use of modulus is in implementing hashes Rather, one of the biggest uses. I don't have documentation to support the claim that it is the biggest, and there are certainly others - date arithmetic, astronomy etc. I probably should have my morning caffeine before replying to the list. :) -Mark
Re: backticks
[EMAIL PROTECTED] (Mark J. Reed) writes:
The biggest use of modulus is in implementing hashes
Rather, one of the biggest uses. I don't have documentation to support
the claim that it is the biggest, and there are certainly others -
date arithmetic, astronomy etc.
I'll bet you the actual most *common* use of modulus is:
until ( my ($percent_done=done()) == 100 ) {
do_work();
print $percent_done,\n unless $percent_done % 10;
}
--
A word to the wise: a credentials dicksize war is usually a bad idea on the
net.
(David Parsons in c.o.l.development.system, about coding in C.)
Re: backticks
On Apr 16, 2004, at 7:19 AM, Simon Cozens wrote:
I'll bet you the actual most *common* use of modulus is:
until ( my ($percent_done=done()) == 100 ) {
do_work();
print $percent_done,\n unless $percent_done % 10;
}
And I'll bet it's something like this:
for my $i (0..$#thingies) {
my $css_class = $i % 2 ? 'blue' : 'yellow';
print tr class=$css_classtd$thingies[$i]/td/tr\n;
}
Pretty useful, actually.
Regards,
David
RE: backticks
-Original Message- From: Mark J. Reed [mailto:[EMAIL PROTECTED] On 2004-04-15 at 19:39:25, Austin Hastings wrote: Of course you used for buffers that were not powers of 2. Had they been powers of 2, you would have used or ~. The fact that you didn't use a power of 2 is pretty questionable. The dread Unix wizards will no doubt have questions for you about this. :-) What are you talking about? The biggest use of modulus is in implementing hashes and when you are implementing hashes you want the number of buckets to be a prime number, not a power of two. I'm totally willing to agree with you, Mark. So: A) Do you code hashing algorithms so frequently that you need a special, low-cost-of-access operator built in to the language to support it? Or: B) Could you give up % as an operator in exchange for using, say, infix:mod or mod(n,d) in your hashing code, so that some operation (like hash access, or iteration, or method calls, or some-as-yet-unspecified-thing) that actually does occur on nearly every line of code could use the good character? =Austin
RE: backticks
-Original Message-
From: David Wheeler [mailto:[EMAIL PROTECTED]
On Apr 16, 2004, at 7:19 AM, Simon Cozens wrote:
I'll bet you the actual most *common* use of modulus is:
until ( my ($percent_done=done()) == 100 ) {
do_work();
print $percent_done,\n unless $percent_done % 10;
}
And I'll bet it's something like this:
for my $i (0..$#thingies) {
my $css_class = $i % 2 ? 'blue' : 'yellow';
print tr class=$css_classtd$thingies[$i]/td/tr\n;
}
Pretty useful, actually.
But any real Jolt-swilling, bit-banging 'C' coder would write:
for (i = 0; i num_thingies; ++i) {
fprintf(ostr, tr class=\%s\td%s/td/tr\n,
(i 1 ? blue : yellow),
thingies[i]);
}
:-)
(The COBOL PL/1 guys, who use the operators just like they're supposed to
be used, would need % because they are used to three-color bar paper,
anyway. But they should be happy with mod anyway, for obvious reasons.)
=Austin
Re: backticks
On Fri, 2004-04-16 at 10:56, David Wheeler wrote:
On Apr 16, 2004, at 7:19 AM, Simon Cozens wrote:
I'll bet you the actual most *common* use of modulus is:
[...]
print $percent_done,\n unless $percent_done % 10;
And I'll bet it's something like this:
my $css_class = $i % 2 ? 'blue' : 'yellow';
Those are both the same, really. In the first case:
do_every(10, $percent_done, sub {print $percent_done, \n});
where the second is:
do_every(2, $i, sub {$css_class = 'blue'}, sub {$css_class = 'yellow'});
Only a subtle variation. do_every would look like:
sub do_every(int $n, int $current, code $doit, code $elsedoit = undef) {
if $n % $current == 0 {
$doit();
} elsif defined $elsedoit {
$elsedoit();
}
}
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: backticks
On 2004-04-16 at 11:17:41, Austin Hastings wrote: I'm totally willing to agree with you, Mark. A) Do you code hashing algorithms so frequently that you need a special, low-cost-of-access operator built in to the language to support it? Nope. I'd be perfectly happy if the modulus operator were spelled mod instead of %, which has never struck me as particularly intuitive. My point was simply that % is not necessarily redundant with in its most common uses. You can certainly still make a good argument for its repurposing on other grounds, but not that one. :) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: backticks
Mark J. Reed wrote: Nope. I'd be perfectly happy if the modulus operator were spelled mod instead of %, which has never struck me as particularly intuitive. I always saw it as being a funny division sign. See the little slash in there? -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
RE: backticks
-Original Message- From: Mark J. Reed [mailto:[EMAIL PROTECTED] Sent: Friday, 16 April, 2004 11:43 AM To: [EMAIL PROTECTED] Subject: Re: backticks On 2004-04-16 at 11:17:41, Austin Hastings wrote: I'm totally willing to agree with you, Mark. A) Do you code hashing algorithms so frequently that you need a special, low-cost-of-access operator built in to the language to support it? Nope. I'd be perfectly happy if the modulus operator were spelled mod instead of %, which has never struck me as particularly intuitive. My point was simply that % is not necessarily redundant with in its most common uses. You can certainly still make a good argument for its repurposing on other grounds, but not that one. :) I wasn't arguing that % is redundant with . I was arguing that inclusion of a special operator in 'C' was a failure, since the most common implementation of modulo was done with anyway. Frankly, KR should have used % for printf or return, and stuck modulo() into the standard library someplace. Maybe if they'd had % available, 'C' would have associative arrays... :-) =Austin
Re: backticks
On 2004-04-16 at 08:50:38, Brent 'Dax' Royal-Gordon wrote: Mark J. Reed wrote: Nope. I'd be perfectly happy if the modulus operator were spelled mod instead of %, which has never struck me as particularly intuitive. I always saw it as being a funny division sign. See the little slash in there? Yeah, I know that's what motivated its choice in C (or was it inherited from B or BCPL?), but the fact remains that it already had a mathematical interpretation that is in conflict with that use - a conflict which is nowhere more evident then in the behavior of dc(1) with k=0 (% = modulus) vs k0 (% = percentage). -Mark
Re: backticks
On Apr 16, 2004, at 10:14 AM, Juerd wrote: Even with the xx Inf? Why? Oh, right, missed that. Sorry. David
Re: backticks
Juerd wrote:
Brent 'Dax' Royal-Gordon skribis 2004-04-16 0:25 (-0700):
I don't like %hash{'foo'} because it's ugly. I don't like %hashfoo
because it's ugly and adds syntax. I don't like %hash`foo because it's
ugly, adds syntax, and looks nothing like an indexing operator. (I'll
revisit this third point soon.) I think it will be easier to fix
%hash{'foo'} or %hashfoo than %hash`foo.
I have no doubt that between fixing existing things to make them nice
enough to use very, very often and just implementing %hash`foo, the
latter is by far the easiest to do.
But it isn't the *right* thing to do.
It's also worth noting that, except for Javascript, every language I can
think of uses paired characters for indexing. Perl 5 uses {} and [];
the C-like languages I know use []; Visual Basic (ugh) uses ().
Template toolkit uses a . for methods, indexes and keys. It's great for
indexes. It's not so great for keys when there is a key that has the
same name as one of the virtual methods.
Template Toolkit is a templating toolkit, not a language. It's meant
for use in more limited places than Perl in general.
(And don't let this devolve into a flamefest about TT.)
Also, other languages are irrelevant, except for inspiration.
Perl 6 mustn't be a copy of existing languages. It must be BETTER.
I thought that to make Perl a better language than all the other
languages, we were supposed to be open minded about new ideas. But
instead, many of the perl6-language subscribers keep referring to
existing non-Perl-6 languages.
Better doesn't necessarily mean different. I'm sure there are
symbols for addition that are objectively better than +. I'm sure
there's a name that's objectively better for 'wait'. These things
stay the way they are because they're conventions.
Similarly, circumfix indexers are a convention in computer science.
There are very few places where it *doesn't* hold true.
Your two examples are:
1. A templating system.
2. A scripting language that uses it as a clever way to get an OO
system.
I do not see a general-purpose programming language that added it in
just for the hell of it in the above list.
I dislike XML and HTML because they're a lot of typing (not only because
of the redundancy in the closing tags).
I'd be inclined to agree with you. But we're talking about *one*
*extra* *character* here. That's two keys. It's hardly the end of the
world.
One extra character, two keys. EACH time. Still indeed not really a very
big problem. However, bracketing operators are very heavy, visually.
Unconsciously, you're matching them, counting them, seeing them.
The case we're talking about is a (probably) short, one-word key. I may
be unconsciously matching and counting them, but it's not a difficult task.
(Although I wouldn't mind seeing go.)
Amen to that, at least.
If the inside of a hash indexer consists entirely of \w characters, it
will be interpreted as the name of a hash key. If you want it to call a
subroutine instead, add a ~ stringifying operator to the beginning of
the call, or a pair of parentheses to the end of it. Simple, clear,
and doesn't shift around based on subroutine definitions. (It's not
what Perl 5 does, but that's Perl 5's fault.)
That looks to me like exactly what Perl 5 does, except you use ~ instead
of +.
The difference is that the rule is more limited--it only applies inside
a hash indexer. Barewords are not a bad idea if they're carefully
limited and defined.
It looks better to me and doesn't add any syntax.
It adds one hell of an ugly special case for the :pair syntax.
Better to add semantics than to add syntax.
To make my position clear: WE DO NOT NEED THREE WAYS TO INDEX A HASH.
We don't even NEED two!
We don't need convenient aliasses in regexes.
We don't need threads.
We don't need lexical variables.
We don't need junctions.
We don't need any dwimmery.
But please, let's write Perl 6 instead of another Java-wannabe.
We don't NEED anything except zeroes and ones.
But all these nice features are damn nice to have!
Regex aliases, threads, lexicals, junctions, and dwimmery make things a
*lot* easier to program. This syntactic sugar you're proposing doesn't.
It saves you a few keystrokes at the cost of complicating the language.
I don't really think we need two. All we really need is one way with a
good enough syntax to meet all of our needs.
Or three syntaxes of which you can choose, depending on what you mean
and like to write.
I thought Perl minded people were used to TIMTOWTDI, but I'm proven
wrong once again.
TMTOWTDI means don't let redundancy stop you from adding a good
feature. It doesn't mean accept every feature that's proposed, no
matter its merits.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: backticks
Sean O'Rourke skribis 2004-04-15 8:55 (-0700):
[EMAIL PROTECTED] (Juerd) writes:
I think it has to go because `pwd`, `hostname`, `wget -O - $url`
should not be easier than the purer Perl equivalents and because
``'s interpolation does more harm than good.
I have to disagree with you here. The Perl way is not always the Perl
way -- the beauty of Perl is that it makes it as easy as possible to
take advantage of existing tools. Sometimes this is best done with a
foreign interface like XS, but sometimes it's adequate and easier to
simply shell out and collect the output. I don't see purity as a
good motive here; in fact, rigid purity makes languages like Java and
Smalltalk somewhere between frustrating and useless.
Yes, executing programs should still be easy. But it doesn't happen
enough to give away the beatiful backticks, in my opinion. And the
backticks encourage interpolation.
I find that there are still plenty of contexts in which `` is nice and
security is irrelevant.
This is the second time in this thread that I read about security being
unimportant. I still don't know what to say about it, though I feel like
ranting.
Of course, I'd be fine with the slightly longer qx{}...
IMHO, best would be to have only readline (which should take a
system()-like LIST!), and I think qx is acceptable. But `` is too nice
to sacrifice, and makes it too easy to not think about security.
Probably you know when you can use qx safely, but many, MANY people out
there have no clue whatsoever and use qx with interpolation *because* it
is easy.
Juerd
Re: backticks
Brent 'Dax' Royal-Gordon skribis 2004-04-16 0:25 (-0700):
Number of keystrokes isn't our only concern here. This is Perl, not
APL--we care about the size of the language and its intuitiveness too.
(Perhaps not much, but we do.)
Not the only concern, but to me, it is as important as readability.
I don't like %hash{'foo'} because it's ugly. I don't like %hashfoo
because it's ugly and adds syntax. I don't like %hash`foo because it's
ugly, adds syntax, and looks nothing like an indexing operator. (I'll
revisit this third point soon.) I think it will be easier to fix
%hash{'foo'} or %hashfoo than %hash`foo.
I have no doubt that between fixing existing things to make them nice
enough to use very, very often and just implementing %hash`foo, the
latter is by far the easiest to do.
It's also worth noting that, except for Javascript, every language I can
think of uses paired characters for indexing. Perl 5 uses {} and [];
the C-like languages I know use []; Visual Basic (ugh) uses ().
Template toolkit uses a . for methods, indexes and keys. It's great for
indexes. It's not so great for keys when there is a key that has the
same name as one of the virtual methods.
Also, other languages are irrelevant, except for inspiration.
Perl 6 mustn't be a copy of existing languages. It must be BETTER.
I thought that to make Perl a better language than all the other
languages, we were supposed to be open minded about new ideas. But
instead, many of the perl6-language subscribers keep referring to
existing non-Perl-6 languages.
I dislike XML and HTML because they're a lot of typing (not only because
of the redundancy in the closing tags).
I'd be inclined to agree with you. But we're talking about *one*
*extra* *character* here. That's two keys. It's hardly the end of the
world.
One extra character, two keys. EACH time. Still indeed not really a very
big problem. However, bracketing operators are very heavy, visually.
Unconsciously, you're matching them, counting them, seeing them.
But do note: I think %foo{EXPR} and %fooWORDS are perlfect and can stay
if %foo`key is implemented. I am not suggesting removing or changing {}
and . (Although I wouldn't mind seeing go.)
If the inside of a hash indexer consists entirely of \w characters, it
will be interpreted as the name of a hash key. If you want it to call a
subroutine instead, add a ~ stringifying operator to the beginning of
the call, or a pair of parentheses to the end of it. Simple, clear,
and doesn't shift around based on subroutine definitions. (It's not
what Perl 5 does, but that's Perl 5's fault.)
That looks to me like exactly what Perl 5 does, except you use ~ instead
of +.
It looks better to me and doesn't add any syntax.
It adds one hell of an ugly special case for the :pair syntax.
To make my position clear: WE DO NOT NEED THREE WAYS TO INDEX A HASH.
We don't even NEED two!
We don't need convenient aliasses in regexes.
We don't need threads.
We don't need lexical variables.
We don't need junctions.
We don't need any dwimmery.
But please, let's write Perl 6 instead of another Java-wannabe.
We don't NEED anything except zeroes and ones.
But all these nice features are damn nice to have!
I don't really think we need two. All we really need is one way with a
good enough syntax to meet all of our needs.
Or three syntaxes of which you can choose, depending on what you mean
and like to write.
I thought Perl minded people were used to TIMTOWTDI, but I'm proven
wrong once again.
Juerd
Re: backticks
David Wheeler skribis 2004-04-16 9:58 (-0700):
for @thingies, qw(blue yellow) xx Inf - $thingy, $class {
print qq[tr class=$classtd$thingy/td/tr\n;
}
I think that $class would be Cundef after the second record in
@thingies, unfortunately.
Even with the xx Inf? Why?
Juerd
Re: backticks
Aaron Sherman skribis 2004-04-16 9:52 (-0400):
3. You proposed (late in the conversation) that both could co-exist, and
while that's true from a compiler point of view, it also leads to:
`stuff``stuff`stuff
Huh? No. That is a syntax error.
$a`a=$a`b~`a` # Try to tell your editor how to highlight that!
Try to tell your editor how to highlight:
print $foo{ / (\d+) { $1 eq 10 or $1 ~~ /5/ and fail } / ?? $1 : };
Better hurry, because it (or something close to it) will soon be valid
syntax.
Also, try using sane spacing and then having confusing syntax.
`$a`b`c` # May or may not give an error, but shocking either way
Syntax error.
One of the things that I absolutely despise about auto-quoting is that I
keep running into the second most popular reason for code ugliness:
$x`y = 1;
$x{y} = 1;
$x`z = 2;
$x{z} = 2;
$x{a b} = 3; # Ooops, can't use ` for that one
$x{a b} = 3; # Oops, can't use unquoted string for that one.
In this case, you should probably have used {} for each of the options.
Most hashes are there mainly to keep a bunch of variables organized, and
let me show you something else:
$y = 1;
$z = 2;
${a b} = 3; # Oops? No!
There is no oops.
` is what you use when you know every key will be a \w+ one, or at least
most will be. Or what you use if one of the keys is \w+ and you do not
care about mixing syntaxes.
Now, mind you: if you WANT to add this to Perl 6, there is nothing
stopping you from writing your own syntax module for it. Go to town, and
I won't try to stop you!
Keep repeating it and it will become more true.
I know that trick too and will also repeat one message:
I'm not asking if this is possible. I know it is. I'm suggesting we put
it in the core.
For reasons to want it in the core, see Scott's summary.
I very probably will have and will use this syntax. I'm not talking
about me. I suggest this feature because I think it's good for Perl and
the people who use it.
Except for the shocking number of closed-minded people on this list.
Fortunately, they can still use {} whenever they want.
I think I have presented two cases. The removal of `` and the
introduction of %hash`key. Either can be implemented without breaking
the other, though I obviously think both letting `` go and introducing
the infix ` is better.
And others disagree. Why can't we leave it at that, and if the consensus
goes toward implementation of your idea, more the better.
Most of those who disagree so far do that they either don't understand
that `` does not have to go, or because they find the ` ugly.
Fortunately, there are also people who absolutely love the proposed
%foo`bar.
Juerd
Re: backticks
David Wheeler skribis 2004-04-16 7:56 (-0700):
And I'll bet it's something like this:
for my $i (0..$#thingies) {
my $css_class = $i % 2 ? 'blue' : 'yellow';
print tr class=$css_classtd$thingies[$i]/td/tr\n;
}
Probably.
Can't we in Perl 6 just use something like this?
for @thingies, qw(blue yellow) xx Inf - $thingy, $class {
print qq[tr class=$classtd$thingy/td/tr\n;
}
Juerd
Re: backticks
On Fri, Apr 16, 2004 at 10:44:47AM -0700, Brent 'Dax' Royal-Gordon wrote:
Regex aliases, threads, lexicals, junctions, and dwimmery make things a
*lot* easier to program. This syntactic sugar you're proposing doesn't.
But it *does* make an oft-used construct easier to type. That adds up
over time and as the amount of code increases. Or do you dispute that
$hash{'key'} is oft-used or that %hash{'key'} will be oft-used?
It saves you a few keystrokes at the cost of complicating the language.
The amount it complicates the language seems infinitesimally
small to me (compare it to all of the added complexity in perl6
so far). Disambiguation based on context works. Show me the
complications you see.
-Scott
--
Jonathan Scott Duff Division of Nearshore Research
[EMAIL PROTECTED] Senior Systems Analyst II
Re: backticks
On Fri, Apr 16, 2004 at 07:12:44PM +0200, Juerd wrote:
Aaron Sherman skribis 2004-04-16 9:52 (-0400):
3. You proposed (late in the conversation) that both could co-exist, and
while that's true from a compiler point of view, it also leads to:
`stuff``stuff`stuff
Huh? No. That is a syntax error.
Actually, no, it's valid and means qx/stuff/.{stuff}.{stuff} which is
of course bogus, but not a syntax error.
A slightly saner example would be: `blah``-1 to get the last line of output
from blah.
I agree with Aaron it looks awful, but that simply means a programmer
shouldn't do that. If you try hard enough, you'll always be able to write
horribly ugly code with some effort.
`$a`b`c` # May or may not give an error, but shocking either way
Syntax error.
This is indeed a syntax error afaics.
Again, saying look you can combine things to make something ugly is very
poor reasoning. Just because you can write code like
perl -e'connect$|=socket(1,2,1,$/=select+1),pack sa14,2,\nDBo\$\36;printd ! @ARGV\nq\n;print$/ +1=~/.+?^(.*?)^\./sm' perl
doesn't mean the language is bad. It means I wrote awful code here.
So the only thing I can say in response to these convoluted examples is don't
do that then.
--
Matthijs van Duin -- May the Forth be with you!
Re: backticks
Larry Wall skribis 2004-04-16 11:50 (-0700): On Fri, Apr 16, 2004 at 07:12:44PM +0200, Juerd wrote: : Except for the shocking number of closed-minded people on this list. You seem to be one of them. From my point of view, you've had your ego plastered all over this proposal from the start, and no one can disagree with it without becoming your enemy. Please consider that some people may have thought about your proposal a long time before weighing in. Myself, I'm still thinking about it. Please don't call me closed-minded if I decide against it, however. There are many considerations to weigh, and nobody is going to give them all the same weight. I think there is a misunderstanding about when I think someone is not open-minded. shocking number was exaggeration. To clarify: only when someone disagrees based on only that it has not been done before or other languages don't do it, I think they should be more open. When you decide, it will not be based only on emotion. Personal taste will of course influence the decision, but everyone can tell that you at least considered it thoroughly, looking at more than just a few aspects. Clearly, indeed some people have thought about it for a long time before responding. But they are probably not the people I call closed-minded. However, I could be guessing badly. It could be that someone who says Perl 6 should not have a third syntax because there are already two really has thought about it. We have many ways of saying foo() if not $bar in Perl 5 and I use most of them. I like that in Perl, and hope that in Perl 6 there will still be more than one way to do it. Anyone can disagree without becoming my enemy. None of the people who have contributed to this discussion are my enemy. I am thankful for every message, because they all either tell me why the proposals are not liked, or that my original post should have been more clear. I cannot and will not argue about the 'ugliness' of the backtick. Nevertheless, I do think that this is an important issue. If most find it ugly, then implementing this in the core is probably a bad idea. Juerd
Re: backticks
Jonathan Scott Duff wrote:
On Fri, Apr 16, 2004 at 10:44:47AM -0700, Brent 'Dax' Royal-Gordon wrote:
Regex aliases, threads, lexicals, junctions, and dwimmery make things a
*lot* easier to program. This syntactic sugar you're proposing doesn't.
But it *does* make an oft-used construct easier to type. That adds up
over time and as the amount of code increases. Or do you dispute that
$hash{'key'} is oft-used or that %hash{'key'} will be oft-used?
I don't claim that they won't be used often. I claim that the *best*
solution is to fix the syntax we already have, not add more. Failing
that, we should make sure that the syntax we add is as globally useful
as possible. The form of backticks you're proposing are good for only
one thing: indexing hashes (and possibly arrays). Clever definition of
the colon operator, or creation of a bareword-quoting operator, would
allow you to use barewords anywhere you wanted to.
It saves you a few keystrokes at the cost of complicating the language.
The amount it complicates the language seems infinitesimally
small to me (compare it to all of the added complexity in perl6
so far). Disambiguation based on context works. Show me the
complications you see.
The complications I see are in things like:
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
Compare that to (assuming barewords are allowed in hash indexers):
To get an item out of a hash, you can write %varname{key}. If
the key doesn't have any characters in it except for letters,
numbers, and underscores, you can write %varname{key}.
Or, with the colon proposal:
To get an item out of a hash, you can write %varname{key}. If
the key doesn't have any characters in it except for letters,
numbers, and underscores, you can write %varname{:key}.
Which explanation is shorter? Which is more logical? Which has the
fewest special cases?
I'm going to throw in one more argument at this point. It's based on a
game you all played as children: Which One Of These Doesn't Belong?
stuff(1)
@stuff[1]
%stuff{1}
%stuff«1»
%stuff`1
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: backticks
Brent 'Dax' Royal-Gordon skribis 2004-04-16 13:17 (-0700):
Clever definition of the colon operator, or creation of a
bareword-quoting operator, would allow you to use barewords anywhere
you wanted to.
Defining ` to be a bareword quoting operator would be only one step away
from what I suggested initially:
1. %hash`key
2. %array`5
3. :key`value
4. say `hello;
This would make it like now, but allowing only one bareword, and
only if it is simple (identifier-ish). Oh, and much easier to read and
type :)
I like the idea of making a bareword quoting operator!
(But only 1 and 2 really matter to me. 1 more than 2.)
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
That's not a great way to teach a langage, and for a reference manual, I
think separation into three paragraphs will make things much clearer.
Or a table, like in perlcheat :)
Basically, if ` is made a generic bareword quoter, is its plural
form. That makes it easier to explain.
I'm going to throw in one more argument at this point. It's based on a
game you all played as children: Which One Of These Doesn't Belong?
stuff(1)
@stuff[1]
%stuff{1}
%stuff«1»
%stuff`1
Hm...
print if not $foo;
if (not $foo) { print }
print unless $foo;
unless ($foo) { print }
$foo or print;
And there are many more examples in Perl. I personally like having two
ways to write exactly the same thing. If the two ways are very
different and one is because of that much easier than the other, I like
having the alternative even more.
Juerd
Re: backticks
On Fri, 2004-04-16 at 12:35, Juerd wrote: backticks encourage interpolation. ... and? From the point of view of a Web developer who deals with (potentially) hostile data, I see the problem (though the solution is smarter tainting, not removing functionality). From the point of view of a general purpose programmer who might just want the result of `id $user`... no, you're trying to apply the (important!) best practices of one area of programming to the rest of the world. The guy who does nothing but write genetic modeling systems is scratching his head wondering why the heck you're so worried about interpolation, and rightly so. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: backticks
On Fri, Apr 16, 2004 at 01:17:10PM -0700, Brent 'Dax' Royal-Gordon wrote:
I don't claim that they won't be used often. I claim that the *best*
solution is to fix the syntax we already have, not add more. Failing
that, we should make sure that the syntax we add is as globally useful
as possible. The form of backticks you're proposing are good for only
one thing: indexing hashes (and possibly arrays). Clever definition of
the colon operator, or creation of a bareword-quoting operator, would
allow you to use barewords anywhere you wanted to.
Hmm. Who's to say that ` isn't the bareword-quoting operator?
(This is where Larry chimes in with *I* say it isn't so :-)
I'm not sure what fixing the existing syntax would mean. A big
advantage of %hash`foo for me is that the delimiters (all 4 of them)
are gone. Can you fix the syntax and remove the delimiters? I think
these things are irreconcilable in your universe (since you seem to
want to keep the curlies)
The complications I see are in things like:
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
Except that you've put things in this explanation that shouldn't be
there IMHO. The %varnamekey is a special case, but not of getting a
single item from a hash, rather it's a special case of a one element
list generated from evaluating to the element. So, if you remove
that bit, it's the same as the two below just with different syntax.
Compare that to (assuming barewords are allowed in hash indexers):
To get an item out of a hash, you can write %varname{key}. If
the key doesn't have any characters in it except for letters,
numbers, and underscores, you can write %varname{key}.
Or, with the colon proposal:
To get an item out of a hash, you can write %varname{key}. If
the key doesn't have any characters in it except for letters,
numbers, and underscores, you can write %varname{:key}.
Which explanation is shorter? Which is more logical? Which has the
fewest special cases?
All of them! The last two seem to imply that %hashfoo will be
going away and it doesn't look like it will at all. To be fair each
of those descriptions should mention %hashfoo if the first one
does.
I'm going to throw in one more argument at this point. It's based on a
game you all played as children: Which One Of These Doesn't Belong?
stuff(1)
@stuff[1]
%stuff{1}
%stuff1
%stuff`1
I have nothing to say to this other than so what? Really, does it
matter that much? Are delimiters really that important here?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: backticks
On Fri, Apr 16, 2004 at 09:16:15PM +0200, Juerd wrote: However, I could be guessing badly. It could be that someone who says Perl 6 should not have a third syntax because there are already two really has thought about it. We have many ways of saying foo() if not $bar in Perl 5 and I use most of them. I like that in Perl, and hope that in Perl 6 there will still be more than one way to do it. Three variations of syntax that are used in the same syntactical context for slightly varying meanings suggests that at least one of them is wrong. Of the many variotions of foo() if not $bar, there are block level (if-statement), statement level (statement modifiers) and expression level ( || and or; perhaps you can argue that ? : is also a variant to the same extent that an if statement is). However, the set of characters following %foo to denote the hash index are all happening in the same sort of expression level context, and three variations seems like too many. That said, in perl5 I use the bareword hash subscript *very* often, and having to quote them would be a major regression to perl3. I far less often use a function call as a hash subscript (at least an order of magnitude less often, maybe two). --
Re: backticks
Jonathan Scott Duff skribis 2004-04-16 15:51 (-0500):
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
Except that you've put things in this explanation that shouldn't be
there IMHO. The %varnamekey is a special case, but not of getting a
single item from a hash, rather it's a special case of a one element
list generated from evaluating to the element. So, if you remove
that bit, it's the same as the two below just with different syntax.
I think %hashkey key key is best explained as %hash{ key key
key } with implicit curlies, not as an alternative to curlies.
This is where ` as a bareword-quoter would provide a somewhat consistent
interface, as %hash`key would then just be %hash{`key}, but without the
curlies. And :fooa and :foo`a would be :foo(a) and :foo(`a)
without the parens.
But I also like to think that // is m// with implicit m, instead of the
other way around.
Juerd
Re: backticks
On Fri, 16 Apr 2004, Juerd wrote:
Defining ` to be a bareword quoting operator would be only one step away
from what I suggested initially:
1. %hash`key
2. %array`5
3. :key`value
4. say `hello;
This would make it like now, but allowing only one bareword, and
only if it is simple (identifier-ish). Oh, and much easier to read and
type :)
I like the idea of making a bareword quoting operator!
I never liked unbalanced quotations in lisp, and I don't think I will like
them in perl either.
Written language sets a strong precedent that quotations should be
balanced. (Apostrophes are not balanced, but they elide instead of
quote.) I haven't decided how I feel about a bareword quoting operator,
but I am strongly against quoting things with unbalanced quotation marks.
Besides:
say `hello;
say 'hello';
I count one keystroke difference there, and ' is easier to type than `,
so give it some credit for that. You'll spend many, many more keystrokes
explaining to people what the first one means, and why unexpected things
happen if they type
say `hello`;
Just so you don't read too much into that, I will agree in advance that
%hash`key is more apostrophitic in nature. I disagree with that change
for other reasons, but making ` an unbalanced quoting operator is
one step too far.
(But only 1 and 2 really matter to me. 1 more than 2.)
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
That's not a great way to teach a langage, and for a reference manual, I
think separation into three paragraphs will make things much clearer.
You didn't answer his question, which is less complicated?
Basically, if ` is made a generic bareword quoter, is its plural
form. That makes it easier to explain.
Well, except that it isn't really!
Three different subscripting syntaxes, each with different quoting rules.
I don't find that prospect attractive.
~ John Williams
Re: backticks
In a message dated Wed, 14 Apr 2004, David Storrs writes:
Actually, what I'd like to know is when it was decided that %hash{key}
meant %hash{key()}?? Was it in one of the Apocalypses?
Perhaps it wasn't spelled out, but the implication was certainly there.
Barewords are gone. Braces create a closure. A closure consisting only
of pairs returns a hash reference. A closure immediately following a hash
or hashref dereferences the hash. By inference, {key} is a closure
consisting of Ckey, which can't be a bareword since barewords are gone.
Hence it must be a sub call to key().
Trey
--
Trey Harris
Vice President
SAGE -- The System Administrators Guild (www.sage.org)
Opinions above are not necessarily those of SAGE.
Re: backticks
Chris skribis 2004-04-14 17:07 (-0700): Perhaps this is naive, but couldn't something like this be achieved in a manner similar to how I just implemented it in Ruby? Surely Perl will have similar capabilities to handle unknown methods. As explained in [EMAIL PROTECTED], it's not a question of whether it is possible. I know it is possible. Either by changing the grammar or perhaps by adding an operator/macro. And as explained in multiple messages already, implementing this using the . has too large drawbacks. Juerd
Re: backticks
David Storrs skribis 2004-04-14 22:39 (-0700):
Very top row, one space right of the F12 key. Extremely awkward.
(This is a US keyboard on a Dell Inspiron 5100 laptop.)
That is inconvenient.
1) ` looks like it should be a bracketing operator
I think you means circumfix/balanced operator.
2) In some fonts, ` is hard to see.
3) In some fonts, ` is hard to disambiguate from ' if you can see it.
In some fonts, the difference between () and {} is hard to see.
In some fonts, the difference between 1, l and I is hard to see.
In some fonts, the difference between 0 and O is hard to see.
In some fonts, the , is hard to see.
In some fonts, and '' look exactly the same.
Don't use those fonts when programming, period. Use a fixed width font.
No fixed width font that I have ever seen makes ` hard to see.
4) This argument has not been made strongly enough (...)
I'm not here to do anything weakly, strongly or forcefully.
5) I use `` in short utility scripts all the time, and would hate to
lose it. To anyone who says that that is dangerous and should be
discouraged--my machine, my code, my problem. (And I work for
myself, so I am the only one who will be maintaining it.)
As said in several messages in this thread before, `` does not have to
go to support %hash`key. %hash`key has already been succesfully
implemented in perl 5.8.3 and does not harm `` there at all.
Actually, what I'd like to know is when it was decided that %hash{key}
meant %hash{key()}?? Was it in one of the Apocalypses? I missed that
and would like to go back and read the reason for it, since I suspect
that, given a single-term expression in a hash subscript, it is far
more likely to be a literal than a function call. It seems that that
is really the source of the entire 'problem' that this thread
addresses.
No, it only was an extra motivation.
Juerd
Re: backticks
Aaron Sherman skribis 2004-04-14 16:40 (-0400):
From a source tree I work with (which I cannot divulge code from, but I
think statistics like this are fine):
$ find . -name \*.pl | wc -l
330
$ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
123
How many of those backticks are in documentation or string literals? In
my @INC I found a lot of attempts to get balanced single quotes in ASCII
as like `foo'.
And how often are simple hash subscripts used?
Also, how insecure and/or inefficient is this code? In #perlhelp, on
PerlMonks and in many other places, backticks are discouraged.
operators, and I see qx{} as just as good if not better, but to remove
it on the basis of the lack of use is faulty.
Removing and replacing the meanings of glyphs on the basis of use is
one of the most important changes in Perl 6.
After all, - becomes . and - gets a new meaning.
| becomes +| (or ~|, ?|) and | gets a new meaning.
Etcetera.
Lack of use as a reason for changing something is not faulty, it is
exactly what should be done.
BUT `` do not have to go because I have ` in mind for something else.
The two things can co-exist, as Matthijs pointed out with his Perl 5
patch. I think it has to go because `pwd`, `hostname`, `wget -O - $url`
should not be easier than the purer Perl equivalents and because ``'s
interpolation does more harm than good.
I would have preferred that Perl 6 used the bash/zsh-style:
$(...)
It's just one keyword and a set of quotes more: $( readpipe pwd )
Juerd
Re: backticks
Aaron Sherman skribis 2004-04-15 14:29 (-0400): On Wed, 2004-04-14 at 16:56, Juerd wrote: How many of those backticks Note, those weren't backticks, those were programs. There were 123 PROGRAMS that used backticks or equivalent syntax. I said backticks, and I meant backticks. I'm not sure why there is confusion over this. Perhaps this can disambiguate: how many of those backticks in those 123 programs. And how often are simple hash subscripts used? Very often. Many times as often as qx and friends? Security is not an issue for this code. It should be. code review? You made and assertion: backticks aren't used much. That assertion is faulty. I didn't formulate my statement carefully enough. I should have said: as much as hash subscription. Executing external code is commonplace, and probably done more often than method invocation in the wild! I want to doubt that. Or better: help change that. It's just one keyword and a set of quotes more: $( readpipe pwd ) And thus, it is not like the bash/zsh style syntax in the least. Why should Perl have to limit itself to shell-like syntax? It doesn't do that with if-constructs, foreach-loops, procedures, etcetera, etcetera, etcetera. Unless there is substantially new information in this thread, I think you have presented your case for yet another new subscripting syntax. I think I have presented two cases. The removal of `` and the introduction of %hash`key. Either can be implemented without breaking the other, though I obviously think both letting `` go and introducing the infix ` is better. Juerd
Re: backticks
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hashfoo retains the features of P5 $hash{foo} but does nothing to counter the
damage of removal of barewords
* %hash`foo occupies an important nitch, trading features (slice, autovivication)
to optmize for the common case, undoing the pain of the loss of barewords,
serving as even a superior alternative
* %hash`foo and %hash ~ `ls` can coexist without breaking anything as this is currently
illegal, unused syntax
* %hash`foo can be added by the user, but users are seldom aware of even a small
fraction
of the things on CPAN and there is a sitgma against writing non-standard code
* %hash`s is an example of a small thing that would be easy to implement in core
but would be used constantly (if JavaScript is any indication, every few lines),
giving a lot of bang for the buck
* Rather than eliciting public comment on %hash`foo (and indeed %hashfoo)
the proposal is being rejected out of hand (incidentally, the mantra of the Java
community Process seems to be you don't need X, you've got Y, and it took
.Net before they woke up and realized that maybe they should consider their
community in the community process - after ignoring a universal call for
generics for over 5 years it's little wonder .Net ate their cake)
-scott
On 0, [EMAIL PROTECTED] Juerd [EMAIL PROTECTED] wrote:
Aaron Sherman skribis 2004-04-15 14:29 (-0400):
On Wed, 2004-04-14 at 16:56, Juerd wrote:
How many of those backticks
Note, those weren't backticks, those were programs. There were 123
PROGRAMS that used backticks or equivalent syntax.
I said backticks, and I meant backticks. I'm not sure why there is
confusion over this.
Perhaps this can disambiguate: how many of those backticks in those 123
programs.
And how often are simple hash subscripts used?
Very often.
Many times as often as qx and friends?
Security is not an issue for this code.
It should be.
code review? You made and assertion: backticks aren't used much. That
assertion is faulty.
I didn't formulate my statement carefully enough. I should have said:
as much as hash subscription.
Executing external code is commonplace, and probably done more often
than method invocation in the wild!
I want to doubt that. Or better: help change that.
It's just one keyword and a set of quotes more: $( readpipe pwd )
And thus, it is not like the bash/zsh style syntax in the least.
Why should Perl have to limit itself to shell-like syntax? It doesn't do
that with if-constructs, foreach-loops, procedures, etcetera, etcetera,
etcetera.
Unless there is substantially new information in this thread, I think
you have presented your case for yet another new subscripting syntax.
I think I have presented two cases. The removal of `` and the
introduction of %hash`key. Either can be implemented without breaking
the other, though I obviously think both letting `` go and introducing
the infix ` is better.
Juerd
Re: backticks
On Thu, 2004-04-15 at 12:27, Scott Walters wrote: Without commenting on the rest of the proposal, please allow me to clear up one point: * Rather than eliciting public comment on %hash`foo (and indeed %hashfoo) the proposal is being rejected out of hand This whole thread *is* public comment. Some people like it, some people don't. Some people think it's useful. Some people think it's ugly. Some people think it simplifies things. Some people think it complicates things. Larry hasn't weighed in. Larry might not weigh in. Larry might like it. Larry might not. Larry might think it solves a real problem and come up with a nicer unification that almost everyone can live with. Hey, it's happened plenty of times before. (incidentally, the mantra of the Java community Process Now that's just rude. You are welcome to think that a certain proposal you like is the best thing ever and should certainly go in Perl 6 for whatever reason -- but claiming that the proposal has been rejected out of hand on a public mailing list where people are discussing the proposal and some people like it and some people don't is rather silly. -- c
Re: backticks
On Thu, Apr 15, 2004 at 12:27:12PM -0700, Scott Walters wrote:
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hashfoo retains the features of P5 $hash{foo} but does nothing to
counter the damage of removal of barewords
Actually, %hashfoo will be like p5's $hash{foo}, and more generally
%hashfoo bar is @hash{qw(foo bar)}, if I'm not terribly mistaken.
It's plain %hash{foo} that's affected.
So to summarize, the following would be equivalent:
%hash{foo}
%hashfoo
%hash`foo
* %hash`foo occupies an important nitch, trading features (slice,
autovivication) to optmize for the common case, undoing the pain of the
loss of barewords, serving as even a superior alternative
Autovivication is still possible, though the exact details would need to
be worked out. (Either always autovivify as hash, or make it dependent on
whether the key matches /^-?\d+\z/ )
But indeed, this is my best argument too: hashes are one of perl's top
core features, and indexing with constant words or simple scalar variables
are the most common ways of using them. It's used so much that by the
huffman principle it deserves very short and convenient notation.
* %hash`foo can be added by the user, but users are seldom aware of even a
small fraction of the things on CPAN and there is a sitgma against writing
non-standard code
I fear that very much too. I'd probably not use the syntax either in public
code (like CPAN modules) if it required a non-core module, since it would be
silly to require an external module just for syntax sugar.
Instead, I'd just be annoyed at it being non-core.
* %hash`foo and %hash ~ `ls` can coexist without breaking anything as this
is currently illegal, unused syntax
* %hash`s is an example of a small thing that would be easy to implement in
core but would be used constantly, giving a lot of bang for the buck
* Rather than eliciting public comment on %hash`foo the proposal is being
rejected out of hand
Exactly. Juerd may have accidently aggrevated the situation by implying in
his original post that %hash`key requires the removal of ``. It's clear now
that the two issues are separated and should be discussed separately.
In case it's not obvious, I'm very much in favor of %hash`foo. (I'm not
entirely sure yet how I feel about removing ``... maybe just leave it until
a better application for those ticks can be found)
--
Matthijs van Duin -- May the Forth be with you!
Re: backticks
It's you. * My objection to the Java community process applies in _some_ _small_ part to the Perl community process. I present it as a negative ideal with the implication that it should be avoided. * My objection to it being rejected out of hand applies not to the Perl community process nor to the people that think i's ugly. I don't argue subjectives. I say people are eager because they've ignored repeated clarifications, continueing to cite groundless technical reasons. That I can aruge =) I interpret this as haste, and it is this haste I object to. * Hence my goal to summarize and prod gently at the eagerness of some. So, my apologies to who anyone who feels unfairly or excessively criticized, except chromatic. There is no forgiveness for someone who seeks out irked people with the single goal of further irking them. Since chromatic is so eager to be offended on behalf of other people I hope you really enjoy being offended. Na na na! One of these days I'm going to resolve to hunt you down to irritate you as you do to me. -scott On 0, chromatic [EMAIL PROTECTED] wrote: On Thu, 2004-04-15 at 12:27, Scott Walters wrote: Without commenting on the rest of the proposal, please allow me to clear up one point: * Rather than eliciting public comment on %hash`foo (and indeed %hashfoo) the proposal is being rejected out of hand This whole thread *is* public comment. Some people like it, some people don't. Some people think it's useful. Some people think it's ugly. Some people think it simplifies things. Some people think it complicates things. Larry hasn't weighed in. Larry might not weigh in. Larry might like it. Larry might not. Larry might think it solves a real problem and come up with a nicer unification that almost everyone can live with. Hey, it's happened plenty of times before. (incidentally, the mantra of the Java community Process Now that's just rude. You are welcome to think that a certain proposal you like is the best thing ever and should certainly go in Perl 6 for whatever reason -- but claiming that the proposal has been rejected out of hand on a public mailing list where people are discussing the proposal and some people like it and some people don't is rather silly. -- c
RE: backticks
-Original Message-
From: Scott Walters [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April, 2004 03:27 PM
To: [EMAIL PROTECTED] Juerd
Cc: [EMAIL PROTECTED]
Subject: Re: backticks
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hashfoo retains the features of P5 $hash{foo} but does
nothing to counter the damage of removal of barewords
Actually, it solves the bare words problem -- the is a quoting
syntax, so %hashfoo is akin to
%hash{'foo'}.
As I understand Juerd, the objection is the number of finger movements
required. For me, on a US-intl keymap with a decent keyboard, the guillemets
are alt+[ and alt+] respectively, which is a pretty low cost. The high cost
is the behavior of ' and in the same keyboard mode, which act as composing
characters. For this reason, I'm assuming that some clever windows hacker
will provide a US-perl6 keyboard definition soon after p6 is available, if
not sooner. (I'd do it myself, frankly, if I had the documentation for that
stuff. :-(
* %hash`foo occupies an important nitch, trading features (slice,
autovivication) to optmize for the common case, undoing the pain of the
loss of barewords,
serving as even a superior alternative
It *would* occupy a niche, were it incorporated. Subjunctivity is still
appropriate.
* %hash`foo and %hash ~ `ls` can coexist without breaking anything as this
is currently
illegal, unused syntax
Correct as I understand it, and certainly true in p5, per Matthijs.
* %hash`foo can be added by the user, but users are seldom aware of even a
small fraction of
the things on CPAN and there is a sitgma against writing non-standard code
Probably true. I'm frequently amazed with the things that are dredged up
from CPAN. And I certainly don't download things from CPAN to change my
syntax, so I can see where others wouldn't, either. OTOH, Juerd could do so,
and could code all his code with it, and could virally infect everyone
else by sending out scads of useful scripts, all of which required Cuse
HashTicks;.
* %hash`s is an example of a small thing that would be easy to implement
in core
but would be used constantly (if JavaScript is any indication, every few
lines),
giving a lot of bang for the buck
I disagree with this. I, for one, would never use it. (I don't object to its
inclusion, since my preferred alternative would remain available:
%hash{$foo} or %hash{'foo'}. But I don't like it visually, and I'm too used
to ` as a quoting character to feel comfortable with this usage.)
Also, this reminds me of the old namespace syntax: $package'var. I'm glad
that's gone, too.
* Rather than eliciting public comment on %hash`foo (and indeed
%hashfoo)
the proposal is being rejected out of hand (incidentally, the mantra of
the Java
community Process seems to be you don't need X, you've got Y,
and it took .Net before they woke up and realized that maybe they should
consider their community in the community process - after ignoring a
universal call for
generics for over 5 years it's little wonder .Net ate their cake)
Actually, it seems to me that there has been public comment. Some names that
I recognize have come out on both sides of the issue, indicating that within
the current established p6l posters there is disagreement on the issue.
Juerd Matthijs have pointed out that the capability could be added with
minimal impact on people (like myself) who don't want to use the feature.
Simon has pointed out that (say it with me, everybody: 1 .. 2 .. 3 .. ) It
doesn't have to go in CORE!
So @Larry (of whom chromatic, a detractor, is one) or $Larry will make a
determination of digital direction, directly, and the dilemma will be
decided. (Sorry. :-)
Your feelings about Sun's inability to run an open community
notwithstanding, the p6l list appears to be working fine. People have said
that many of my suggestions were stupid, too, but rejection is not the same
as refusal to listen.
=Austin
-scott
On 0, [EMAIL PROTECTED] Juerd [EMAIL PROTECTED] wrote:
Aaron Sherman skribis 2004-04-15 14:29 (-0400):
On Wed, 2004-04-14 at 16:56, Juerd wrote:
How many of those backticks
Note, those weren't backticks, those were programs. There were 123
PROGRAMS that used backticks or equivalent syntax.
I said backticks, and I meant backticks. I'm not sure why there is
confusion over this.
Perhaps this can disambiguate: how many of those backticks in those 123
programs.
And how often are simple hash subscripts used?
Very often.
Many times as often as qx and friends?
Security is not an issue for this code.
It should be.
code review? You made and assertion: backticks aren't used much. That
assertion is faulty.
I didn't formulate my statement carefully enough. I should have said:
as much as hash subscription.
Executing external code is commonplace, and probably done more often
than method invocation in the wild!
I want
Re: backticks
On Thu, Apr 15, 2004 at 01:26:47PM -0700, Scott Walters wrote: : So, my apologies to who anyone who feels unfairly or excessively criticized, : except chromatic. There is no forgiveness for someone who seeks out irked people : with the single goal of further irking them. Since chromatic is so eager to : be offended on behalf of other people I hope you really enjoy being offended. : Na na na! One of these days I'm going to resolve to hunt you down to irritate you : as you do to me. Well, I, for one, think chromatic was right on the money. Larry
Re: backticks
Scott * %hash`s is an example of a small thing that would be easy to implement
Scott in core but would be used constantly (if JavaScript is any indication,
Scott every few lines), giving a lot of bang for the buck
Not sure that JavaScript is relevant here, since the equivalent
syntax there, ., is the same as the method call syntax. But see my
proposal below.
Austin I don't like it visually, and I'm too used to ` as a quoting character
Austin to feel comfortable with this usage.) Also, this reminds me of the
Austin old namespace syntax: $package'var. I'm glad that's gone, too.
I agree on all counts.
Scott Rather than eliciting public comment on %hash`foo (and indeed
Scott %hashfoo) the proposal is being rejected out of hand
? Who has rejected it out of hand? And what is this entire thread if not
eliciting public comment?
If I might offer a modest counter-proposal - how about a fallback method
(the equivalent of Perl5's AUTOLOAD or Ruby's method_missing, however
that winds up being spelled in Perl6) that would return the value of the
key equal to the requested method name? Actually, it should return it
as an lvalue to allow the shortcut to be used in assignments. This
wouldn't need to be in the Hash base class; it could be in a subclass
called RhinoHash or some such. Then %hash{'foo'} == %hash«foo» could
also be spelled %hash.foo, as long as 'foo' weren't the name of a hash
method - just as in JavaScript.
It wouldn't work for non-literals, though, unless $obj.$var is going to
be legal for invoke the method whose name is in $var on receiver $obj, which
I don't think it is. But given the need to avoid conflicts with
defined methods, having it work for non-literals would be more problematic
anyway.
-Mark
Re: backticks
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
On the grounds that personally I hate the backtick :-)
--
That he said that that that that is is is debatable, is debatable.
Re: backticks
On 2004-04-15 at 16:49:28, Mark J. Reed wrote:
Not sure that JavaScript is relevant here, since the equivalent
syntax there, ., is the same as the method call syntax. But see my
proposal below.
Before the nit-pickers jump in, I was oversimplifying above. The
method call syntax in JavaScript is really just the operator '(' args*
')', appended to an expression whose value is a reference to a Function
object. JavaScript object.meth(foo) functions roughly like a cross
between Perl5 $object-{'meth'}-($foo) and $object-meth($foo): like
the former, it looks up the value of key 'meth', expects it to be a code
reference, and then executes it; like the latter, it passes the receiver
along with the specified args.
-Mark
Re: backticks
Mark J. Reed skribis 2004-04-15 16:49 (-0400): If I might offer a modest counter-proposal - how about a fallback method (the equivalent of Perl5's AUTOLOAD or Ruby's method_missing, however that winds up being spelled in Perl6) that would return the value of the key equal to the requested method name? No, please not that. When there is a bareword that is both a key and a method, one of the two has to get precedence. Neither option is acceptable and both render using the . for the thing that does not get precedence useless. Option one: methods get precedence Code breaks when methods are added. Option two: keys get precedence Would have to delay everything until runtime. No, if we want a simple and lean operator for this, it must not be one that in the same context also has another function. Juerd
Re: backticks
Dave Mitchell skribis 2004-04-15 21:56 (+0100):
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
Yes, there is one. It is a problem that the Perl4-ish package separator
causes in Perl 5 already. One that bites many coders:
Eat at $joe's
means in Perl 5:
Eat at $joe::s
would mean in Perl 6 if we used the ' for hash subscripts:
Eat at $joe{'s'}
Apostrophes are needed in text. Many languages use them to mark the
absence of some letters. I don't know of any such use of the backtick,
except by people new to computers who use them as if they are
apostrophes :)
I dislike the attempt at getting balanced quotes in ASCII that involves
` and ', but it shouldn't be a problem as that in normal use always
follows whitespace or at least interpunction.
On the grounds that personally I hate the backtick :-)
...
Juerd
Re: backticks
On Thu, 2004-04-15 at 13:37, Larry Wall wrote: Well, I, for one, think chromatic was right on the money. No matter how right my thoughts might have been, my tone *was* rude and that's not right. Apologies to Scott. -- c
Re: backticks
On Thu, Apr 15, 2004 at 11:45:27AM +0200, Juerd wrote:
David Storrs skribis 2004-04-14 22:39 (-0700):
Very top row, one space right of the F12 key. Extremely awkward.
(This is a US keyboard on a Dell Inspiron 5100 laptop.)
That is inconvenient.
Yup.
1) ` looks like it should be a bracketing operator
I think you means circumfix/balanced operator.
If you prefer those terms, sure.
2) In some fonts, ` is hard to see.
3) In some fonts, ` is hard to disambiguate from ' if you can see it.
In some fonts, the difference between () and {} is hard to see.
In some fonts, the difference between 1, l and I is hard to see.
In some fonts, the difference between 0 and O is hard to see.
In some fonts, the , is hard to see.
In some fonts, and '' look exactly the same.
All true.
Don't use those fonts when programming, period. Use a fixed width font.
No fixed width font that I have ever seen makes ` hard to see.
I am currently using a fixed width font to read this message. ` is
hard to see.
4) This argument has not been made strongly enough (...)
I'm not here to do anything weakly, strongly or forcefully.
s/strongly/convincingly/
5) I use `` in short utility scripts all the time, and would hate to
lose it. To anyone who says that that is dangerous and should be
discouraged--my machine, my code, my problem. (And I work for
myself, so I am the only one who will be maintaining it.)
As said in several messages in this thread before, `` does not have to
go to support %hash`key. %hash`key has already been succesfully
implemented in perl 5.8.3 and does not harm `` there at all.
You point is granted. However, mine still stands.
--Dks
RE: backticks
-Original Message-
From: Juerd [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April, 2004 05:09 PM
To: Dave Mitchell
Cc: [EMAIL PROTECTED]
Subject: Re: backticks
Dave Mitchell skribis 2004-04-15 21:56 (+0100):
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
Yes, there is one. It is a problem that the Perl4-ish package separator
causes in Perl 5 already. One that bites many coders:
Eat at $joe's
means in Perl 5:
Eat at $joe::s
would mean in Perl 6 if we used the ' for hash subscripts:
Eat at $joe{'s'}
Apostrophes are needed in text. Many languages use them to mark the
absence of some letters. I don't know of any such use of the backtick,
except by people new to computers who use them as if they are
apostrophes :)
I dislike the attempt at getting balanced quotes in ASCII that involves
` and ', but it shouldn't be a problem as that in normal use always
follows whitespace or at least interpunction.
If we're going to entertain alternatives, why not use % as the hash
subscriptor?
To borrow from another thread:
%foo%monday%food = 10;
%foo%monday%travel = 100;
%foo%tuesday%food = 10;
%foo%tuesday%travel = 150;
This has the advantage of ensuring that the hash-marker [1] appears in every
hash reference, and doubles up on the path weight of a single character,
for really good Huffman.
I'm not so much of a user of the modulus operation that I'm unwilling to
exchange it for, e.g. Cmod or C+%.
I don't know about other conflicting uses of %, especially involving special
no-comma-required rules, but I'll bet that if there was one such, a
whitespace rule would disambiguate it.
(E.g., %functions{'print'} %handles{'stderr'}, ...)
I doubt if this would work quite as well in p5, though, since the
presumption of % isn't so high.
=Austin
[1] The hash marker, for allegorical reasons, really should be either '#'
(Unix) or '-' (American Football). I wonder if it's too late to reclaim '#'.
Perhaps % could indicate comments... :-) :-) :-)
Re: backticks
Austin Hastings skribis 2004-04-15 18:09 (-0400): If we're going to entertain alternatives, why not use % as the hash subscriptor? To borrow from another thread: %foo%monday%food = 10; %foo%monday%travel = 100; %foo%tuesday%food = 10; %foo%tuesday%travel = 150; There is as far as I know no technical reason to not do this. But I do dislike fat operators without whitespace. I dislike that as much as I would dislike using whitespace around a subscripting operator. This has the advantage of ensuring that the hash-marker [1] appears in every hash reference, and doubles up on the path weight of a single character, for really good Huffman. %foo is a hash. When I see %foo%bar, it feels like that should be a hash too. Besides that, $foo%bar looks funny and @[EMAIL PROTECTED] does so even more. Not to mention @[EMAIL PROTECTED] I like ` because it's a small but recognisable glyph. (And because of its location on most keyboards.) Juerd
RE: backticks
-Original Message- From: Matthijs van Duin [mailto:[EMAIL PROTECTED] On Fri, Apr 16, 2004 at 12:14:08AM +0200, Juerd wrote: %foo is a hash. When I see %foo%bar, it feels like that should be a hash too. Besides that, $foo%bar looks funny and @[EMAIL PROTECTED] does so even more. Not to mention @[EMAIL PROTECTED] I like ` because it's a small but recognisable glyph. (And because of its location on most keyboards.) And also because ` is unused in this context, while it's not unimaginable that someone may want the number of elements modulo something. (I dislike unnecessary whitespace-disambiguating rules) That would be C%hash +% 5, or maybe C%hash mod 5, for some value of '5'. The use of % as a modulo operator is purely a legacy from 'C', where it was a failure: in 'C', the only number you care about for modulus is some power of 2, and you get those using bitwise-and anyway. If there is no comma-optional case, then you might even say: $foo % bar $foo % $bar @foo @ 10 % bar (for some reason, I can't like @ as an array dereference. [] does it for me.) (Also, of course, I'm still holding out for @ to be the infix remote-procedure-call operator. Hooray for ACcent!) =Austin
Re: backticks
Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. Juerd
Re: backticks
On Thu, Apr 15, 2004 at 06:38:34PM -0400, Austin Hastings wrote: The use of % as a modulo operator is purely a legacy from 'C', where it was a failure: in 'C', the only number you care about for modulus is some power of 2, and you get those using bitwise-and anyway. I disagree with this completely. I've used % plenty of times in C for circular buffers that were not a powers of 2. % as modulus in C is NOT a failure. If there is no comma-optional case, then you might even say: $foo % bar $foo % $bar @foo @ 10 % bar (for some reason, I can't like @ as an array dereference. [] does it for me.) I'd favor Juerd's proposal over this madness any day :) -Scott -- Jonathan Scott Duff Division of Nearshore Research [EMAIL PROTECTED] Senior Systems Analyst II
RE: backticks
-Original Message- From: Juerd [mailto:[EMAIL PROTECTED] Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. In that case, why not define a Class::Hash-like class that does what you need using autoload? Using p6 you'd get %hash.key instead of p5's $hash-key which is a better single-key access, all things considered. =Austin
Re: backticks
Austin Hastings writes: -Original Message- From: Juerd [mailto:[EMAIL PROTECTED] Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. In that case, why not define a Class::Hash-like class that does what you need using autoload? Using p6 you'd get %hash.key instead of p5's $hash-key which is a better single-key access, all things considered. Most likely because either you couldn't use the Hash's methods, or your code would suddenly break should Hash decide to add a method with the same name as one of your keys. Luke
RE: backticks
-Original Message- From: Luke Palmer [mailto:[EMAIL PROTECTED] Austin Hastings writes: From: Juerd [mailto:[EMAIL PROTECTED] Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. In that case, why not define a Class::Hash-like class that does what you need using autoload? Using p6 you'd get %hash.key instead of p5's $hash-key which is a better single-key access, all things considered. Most likely because either you couldn't use the Hash's methods, or your code would suddenly break should Hash decide to add a method with the same name as one of your keys. I'm sure that if Juerd or someone were to write a PublicHash class, they would cleverly reverse the access so that some collision-unlikely path would get the methods. Or use object-indirect :-) =Austin
RE: backticks
-Original Message- From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED] On Thu, Apr 15, 2004 at 06:38:34PM -0400, Austin Hastings wrote: The use of % as a modulo operator is purely a legacy from 'C', where it was a failure: in 'C', the only number you care about for modulus is some power of 2, and you get those using bitwise-and anyway. I disagree with this completely. I've used % plenty of times in C for circular buffers that were not a powers of 2. % as modulus in C is NOT a failure. Of course you used for buffers that were not powers of 2. Had they been powers of 2, you would have used or ~. The fact that you didn't use a power of 2 is pretty questionable. The dread Unix wizards will no doubt have questions for you about this. :-) My point, though, is this: a *lot* of the stuff we take for granted, or did until Larry started shining a light on things like , |, ?:, etc., has crappy Huffman coding. Even something like semicolon as statement terminator isn't what it should be. Instead, it's a nod in the direction of COBOL, where everything was to be an english-like sentence, so ended with period. Sadly, there's exactly one statement terminator per statement, but there's a lot of characters that appear more frequently, like parens and braces. One solution is to eliminate the parens, as with the p6 changes for if and while. A better solution would be to either improve the finger-movement count for those characters, or reuse the purer characters for better purposes. Thus, period as a method delimiter is palatable since it replaces - (dash, shift, dot). The only thing really fighting against pure-Huffman is the preconceived ideas that eurocentric coders have about symbology: +, -, *, and to a lesser extent / mean things. Otherwise, / would be a good candidate for re-use: unshifted, prime real estate, has certain separator-like qualities. If you think about it, what we really ought to do is train ourselves to reverse the numbers row on our keyboards. If we're doing a good job about avoiding magic numbers, then $ % ( ) are going to be much more frequently used than 2 4 5 7 9 0, so why don't we fix them by swapping the shifted for unshifted characters? If there is no comma-optional case, then you might even say: $foo % bar $foo % $bar @foo @ 10 % bar (for some reason, I can't like @ as an array dereference. [] does it for me.) I'd favor Juerd's proposal over this madness any day :) Oh! The slings and arrows of public discussion. I bleed! I die! Aaa aaa aaa rgh. [Aside] Though this be madness, yet there is method in't. ;-) =Austin
Re: backticks
Juerd wrote:
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
We already have two hash dereference syntaxes. That's arguably one too
many as it is. Let's fix the deficiencies in the syntax we have, rather
than adding even more syntax with even more deficiencies.
Oh, you want a specific proposal? Pick one of four:
1. Allow %hashfoo to be typed as %hashfoo. There would be a
conflict with numeric less-than, but we can disambiguate with
whitespace if necessary. After all, we took the same solution with
curlies.
2. Allow barewords in curlies as a special case. We're already allowing
them on the left side of = (I think), which is even more ambiguous.
3. Define hash indexing with a pair to index on the key. This would
allow the syntax %hash{:foo}. (This could even be achieved by making
C~$pair eq $pair.key.)
4. Define a bareword-quoting prefix operator (i.e. one that turns the
next \w+ into a string) and use the normal hash indexer, {}. I have
no suggestion for this operator's name, although if you wanted to rip
out the current unary backticks, it could be a candidate:
%hash{`key}.
In the last three proposals, I would remove the indexer. I feel
that indexing with a slice of \w keys is not a common enough operation
to warrant the extra indexer, even with the parallel to the list
constructor. However, it's worth noting that #3 gives you a fairly
convenient construct to do just that (%hash{:foo :bar}), and #4 could
probably be defined to do the same.
(For the record, I have nothing against the list constructor. That
was a stroke of genius. I just don't like having a separate indexer
based on it.)
As for removing the term ``, I see no compelling argument to do so.
Perl has never been, and should never be, the sort of nanny language
that makes fundamental operations less accessible just because they're
security risks. Heck, we gave our users the 'x' operator, arguably the
easiest way in any language to fill up memory quickly.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: backticks
Austin Hastings writes: If you think about it, what we really ought to do is train ourselves to reverse the numbers row on our keyboards. If we're doing a good job about avoiding magic numbers, then $ % ( ) are going to be much more frequently used than 2 4 5 7 9 0, so why don't we fix them by swapping the shifted for unshifted characters? Hehe, one step ahead of you. It's quite simple to train vim to do such a thing, and I noticed myself using the numpad for numbers anyway, so I made all the number keys act like shift is being pressed. I can see that it's a step up in efficiency 9although I'm still getting used to it81 :-0 Luke
Re: backticks
On Wed, Apr 14, 2004 at 02:18:48PM +0200, 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.
%hash`key
$hashref`foo`bar`baz`quux
%hash`$key
$object.method`key
I absolutely love it. Since hashes are used so much, I think it deserves
this short syntax. Note btw that it's not even mutually exclusive with qx's
use of backticks. To illustrate that, see:
http://www.math.leidenuniv.nl/~xmath/perl/5.8.3-patches/tick-deref.patch
It's a quick patch I made that adds the `-operator to perl 5.8.3, so you
can try it how it feels.
With some imagination, this can also be used for arrays.
I like that too. (though not (yet) implemented in my patch)
--
Matthijs van Duin -- May the Forth be with you!
Re: backticks
On Wed, Apr 14, 2004 at 12:07:18PM -0700, chromatic wrote:
On Wed, 2004-04-14 at 05:18, Juerd wrote:
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
How do you request a hash slice with backticks?
I think you wouldn't. For that the more verbose syntax is required and I
think even desired. %foo`key is just a shorthand for the very common
%foo{key}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: backticks
chromatic skribis 2004-04-14 12:07 (-0700):
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
How do you request a hash slice with backticks?
You don't. There are %foofoo bar and %foo{'foo', 'bar'} already and
hash slices aren't used much at all.
The proposed ` is very much like the . that is used for calling methods.
Except for the possible leading minus, it can probably be parsed exactly
the same (i.e. allowing :: too, as Matthijs' implementation also
does).
It is also much like the way single elements work in Perl 5, except that
you can't use an expression. (i.e. where $hash{+shift} uses the shift
operator, %hash`shift would get value of the pair that has the key
'shift' and %hash`+shift would be a syntax error -- there is already
%hash{shift} for that and this too isn't used as often as literal string
keys.
Main purposes of ` are typability and readability. Anything that allows
more complex operations would require less readable syntax if used with
the backtick. Only simple literal strings (valid identifiers, but being
able to start with a digit or minus) and simple scalar variables (the
thing perlreftut calls atomic) like $foo can be used.
Juerd
Re: backticks
On Wed, 2004-04-14 at 12:24, Juerd wrote:
chromatic skribis 2004-04-14 12:07 (-0700):
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
How do you request a hash slice with backticks?
You don't. There are %foofoo bar and %foo{'foo', 'bar'} already and
hash slices aren't used much at all.
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
Simplicity is good, yes. Huffman coding is also good. But you have to
balance them with consistency of expression, usage, and semantics. I
don't think this proposal does the latter.
On the other hand, if you prod Luke Palmer, he can probably write a
macro to make this syntax work for you in under ten minutes and three
messages. In that case, it may not be a core feature, but you can have
it for very nearly free.
-- c
Re: backticks
On Wed, 14 Apr 2004, 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.
can then also be written as:
%hash`key
ugly.
$hashref`foo`bar`baz`quux
ugly ugly ugly
%hash`$key
oops, you contradicted yourself here. only be useable for \w+ keys
With some imagination, this can also be used for arrays. That would need
to allow the key to have /^-/ and it poses a problem with hybrids like
$0. Normally []/{} decides whether it's a hash or array dereference, but
for this easy-to-write thing a /^-?\d+$/ should be doable. After all, []
and {} are still available if you need to be explicit.
$0`15 # $0[15]
$0`alpha # $0{'alpha'}
You are repeating the errors of javascript. $0[15] != $0{15}
:key`value
use Some::Module :foo :bar :baz`quux :xyzzy;
I think I would prefer something more intuitive, like :baz=quux
Any [^\w\s] character could be used there unambiguously, and = has the
already existing parallel with command-line args, but ` is just an unused
character.
and ` is in an extremely easy to type place.
... on a us/english keyboard ...
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
one emphatic negative vote here.
Re: backticks
chromatic skribis 2004-04-14 12:32 (-0700):
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
Absolutely false.
This is an addition to the already existing {}, which should stay.
%foo{ something } will still be necessary if:
* the key is the result of an expression
* you want a slice
* the key is not a string
* the key is a string that isn't simple enough (i.e. contains \W in a
way that isn't supported)
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
There are already two. One that works with expressions and one that
works for one or many hash keys as long as they are literals.
%foo$bar doesn't quite do the same as %foo{$bar}.
Simplicity is good, yes. Huffman coding is also good. But you have to
balance them with consistency of expression, usage, and semantics.
I agree.
I don't think this proposal does the latter.
I disagree.
On the other hand, if you prod Luke Palmer, he can probably write a
macro to make this syntax work for you in under ten minutes and three
messages. In that case, it may not be a core feature, but you can have
it for very nearly free.
Or I could use something that modifies the grammar Perl uses. Almost any
syntax feature can be added outside the core. I'm not exploring the
possibility of this operator, but suggesting that it be in the core.
This operator is possible, improves readability, eases typing and does
not clash with something that already exists.
Yes, it does mean learning the meaning of one more character. I think
every programmer is able to cope with that. Even beginners.
Juerd
Re: backticks
John Williams skribis 2004-04-14 13:36 (-0600):
On Wed, 14 Apr 2004, 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.
%hash`$key
oops, you contradicted yourself here. only be useable for \w+ keys
Oops, part of my message wasn't read as it was intended. $key is a
simple atomic scalar and should be usable too.
Just like how $object.$method works, %hash`$key should too.
$0`15 # $0[15]
$0`alpha # $0{'alpha'}
You are repeating the errors of javascript. $0[15] != $0{15}
After all, [] and {} are still available if you need to be explicit.
Javascript's error (design) is that it has only [] and no {}.
I think I would prefer something more intuitive, like :baz=quux
That reads to me as assigning the result of quux() to a pair that has
the value 1. To avoid that it reads like an assignment, = could be
used:
:bar=quux
But ehm, then there's not much point anymore, as
bar = 'quux'
already does the same and is much easier to read.
Any [^\w\s] character could be used there unambiguously, and = has the
already existing parallel with command-line args, but ` is just an unused
character.
Command line arguments (assuming a specific kind of parsing) also
use -- instead of : and have
and ` is in an extremely easy to type place.
... on a us/english keyboard ...
On a US keyboard (qwerty/dvorak), it's in the upper left corner. Very
convenient indeed.
On German and Danish keyboards, it is the key left of backspace,
shifted. This sounds terrible, but not quite as terrible as Alt Gr plus
7 and 0 respectively.
German/Danish keyboard has:
/ ( ) = ? `-- Shift
7 8 9 0 sz '-- no modifier
{ [ ] } prc \-- Alt Gr
On Dutch keyboards (that aren't used much, but do exist), it is two keys
left of Enter. It also requires the awkward Alt Gr for { and }, but in
better positions:
- ( ) '-- Shift
7 8 9 0-- no modifier
pnd { }-- Alt Gr
H J K L plm `-- Shift
h j k l + '-- no modifier
With whatever keyboard Matthijs uses, the ` is right of the left Shift.
So that's already 6 keyboard layouts in which ` is much easier than {}.
It appears French keyboards have { as Alt Gr + 4 and } all the way over
on the right side, as Alt Gr + =. It has ` as Alt Gr + 7. But this
layout looks terrible for any typing, natural AND programming languages.
http://www.datacal.com/dce/catalog/french-layout.htm
If on your keyboard ` is in a worse place than {}, I'd like to know
where it is.
Juerd
Re: backticks
When I announced that I fixed a version of Perl6::Variables to do ,
crickets chirped. I dislike having to place a lot of matching quotes,
brackets, parenthesis, and braces in my code. You must stop and
visually inspect code to make sure it balances out and even then is a
common source of bug causing typos.
I've been working in Pike's predecessor, LPC, lately. Arrays and hashes
are both subscripted with []
foo[bar][10][baz]
Variables are autoconverted to the correct type. This has two drawbacks.
Visually inspecting the dreference sequence, you can't tell whether this
is an hash of arrays of hashes or a hash of arrays of arrays. If { }
were used to deference hashes, you'd be able to tell.
Second, autovivication is impossible for the same reason. We can't tell
from parsing this lone expression whether baz should be converted to numbers
or strings automatically.
Enough science, time for anecdotes!
If you can't remember what a data structure looks like, it doesn't matter if
the code spells out the sequences of hash-array-hash each time - you're
going to spell it out wrong. People new to Perl and new to data structures
have this problem all the time - they can't keep straight what the data structure
*is*.
I adjusted to the lack of autovivication very quickly and easily. I'd sacrifice
autovivication *much* sooner than I'd sacrifice a concise subscript syntax.
Data structures are really only ever initialized in a few places in code
except in pathologically badly written code. This adjustment was akin to the
use warnings's handling of undef reguarding Use of unitialized value.
Hardcoding things around is normally considered bad, and in LPC at least once
in the past month, I've switched an array to being a hash. I was able to do
so without rewritting all of the code that accesses the data structure -
it automatically began accept strings as well as numbers for keys in the
subscript. Hence, using { } vs [ ] might be providing too much redundancy.
And since when have we forced people to be explicit in Perl?
In LPC and apparently Pike, it is all or nothing. Perl can have it's cake and
eat it too. If you want autovivication and information about your datastructures
hardcoded around, use {}, [], and . If you want concise code, use `. I'd
actually go one further and coopt the . operator and emulate JavaScript more
closely, but I admit the visual distinction between method calls and subscripts
might warrent the noise.
Re: the re-adjustment, after 5 years of heavy Perl programming, LPC's relatively
simple syntax is extremely soothing. The only thing I'm really missing is
list flattening, implicit or explicit, frequently doing things like
bar(xyz[foo][0], xyz[foo][1], xyz[foo][2]).
Let me summarize. The gripes about you can't do that with `! miss the point.
Two ways to subscript is not too many. The simplicity available from it is far
from the terse line noise associated with Perl but is something worthy of
languages billed as clean and readable (Pike, not JavaScript). There are
distinct advantages besides concise to this syntax that make it desireable.
So, I strongly support ` or something equivilent.
-scott
On 0, Juerd [EMAIL PROTECTED] wrote:
chromatic skribis 2004-04-14 12:32 (-0700):
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
Absolutely false.
This is an addition to the already existing {}, which should stay.
%foo{ something } will still be necessary if:
* the key is the result of an expression
* you want a slice
* the key is not a string
* the key is a string that isn't simple enough (i.e. contains \W in a
way that isn't supported)
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
There are already two. One that works with expressions and one that
works for one or many hash keys as long as they are literals.
%foo$bar doesn't quite do the same as %foo{$bar}.
Simplicity is good, yes. Huffman coding is also good. But you have to
balance them with consistency of expression, usage, and semantics.
I agree.
I don't think this proposal does the latter.
I disagree.
On the other hand, if you prod Luke Palmer, he can probably write a
macro to make this syntax work for you in under ten minutes and three
messages. In that case, it may not be a core feature, but you can have
it for very nearly free.
Or I could use something that modifies the grammar Perl uses. Almost any
syntax feature can be added outside the core. I'm not exploring the
possibility of this operator, but suggesting that it be in the core.
This operator is possible, improves readability, eases typing and does
not clash with something that already exists.
Yes, it does mean learning the meaning of one
Re: backticks
Juerd wrote:
chromatic skribis 2004-04-14 12:32 (-0700):
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
Absolutely false.
This is an addition to the already existing {}, which should stay.
%foo{ something } will still be necessary if:
* the key is the result of an expression
* you want a slice
* the key is not a string
* the key is a string that isn't simple enough (i.e. contains \W in a
way that isn't supported)
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
There are already two. One that works with expressions and one that
works for one or many hash keys as long as they are literals.
%foo$bar doesn't quite do the same as %foo{$bar}.
That's one method, really - being like {' '}, and really just
carrying on the very familiar idea of different kinds of quotes. Like '
and .
The ` idea is completely different.
Also, ditching `` quotes strikes me as a fairly dreadful idea. I for one
use them almost perpetually. Yes, I could use qx// instead, but I could
also use qq// instead of .
Ultimately, ` looks like an opening quote character, and so people will
expect it to behave like one. I think that violates the principle of
least surprise.
Re: backticks
Scott Walters skribis 2004-04-14 13:12 (-0700):
Second, autovivication is impossible for the same reason. We can't tell
from parsing this lone expression whether baz should be converted to numbers
or strings automatically.
I want ` for hashes in the first place. Having it for arrays too would
be nice, but it isn't as important to me. Having seen some international
keyboard layouts, I think others may find not having to type [] very
useful.
Autovivification of elements is not a problem for pure hashes and
arrays. Autovivification of references (as in my $ref; $ref`aoeu) and
elements of hybrid arrayhashes (like $0) is also not a problem if you
use the ^-?\d+$ rule to decide. Again: if you need to be explicit, you
still can.
So I'm not sure where it is a problem. Even if deciding based on the
value isn't good and for autovivification you default to hashes, the `
would still be a welcome addition.
If you can't remember what a data structure looks like, it doesn't matter if
the code spells out the sequences of hash-array-hash each time - you're
going to spell it out wrong. People new to Perl and new to data structures
have this problem all the time - they can't keep straight what the data structure
*is*.
That, and not many hashes have \d+ keys. When they do, you can just use
{} to make sure things are interpreted the way you want them to be.
actually go one further and coopt the . operator and emulate JavaScript more
closely, but I admit the visual distinction between method calls and subscripts
might warrent the noise.
It's not just the visual distinction, but also to let the parser know.
If I understand correctly, hashes and arrays will have many methods of their
own. I don't want %hash.keys to be interpreted as
%hash{'keys'} and I do want to be able to use the easier syntax when my
hash does in fact have a key 'keys'.
Juerd
Re: backticks
On Wed, 2004-04-14 at 08:18, Juerd wrote:
Perl 5 has the qx// operator which does readpipe. I believe the function
for it was added later. (It doesn't handle a LIST as system does,
unfortunately.) qx// is also known as ``. Two backticks.
readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses
can be found. Most are in Debian's modules.
Why should readpipe get to cheat on the huffman thing?
From a source tree I work with (which I cannot divulge code from, but I
think statistics like this are fine):
$ find . -name \*.pl | wc -l
330
$ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
123
`` gets used an awful lot, just usually not in modules where the process
control issues surrounding even system() tend to yield a module unusable
for the general case, even though it might be fine in a more specific
one.
I could take or leave `` because I don't like unbalanced quote
operators, and I see qx{} as just as good if not better, but to remove
it on the basis of the lack of use is faulty.
I would have preferred that Perl 6 used the bash/zsh-style:
$(...)
But we have other designs on that.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: backticks
Matthew Walton skribis 2004-04-14 21:23 (+0100):
%foo$bar doesn't quite do the same as %foo{$bar}.
That's one method, really - being like {' '}, and really just
carrying on the very familiar idea of different kinds of quotes. Like '
and .
The thing works as if there is an implicit {} around it: is
an alias for qw.
doesn't interpolate. Its insides are string literals separated by
whitespace.
«foo» is 13 key presses, foo is 9 key presses, {'foo'} is also
9, `foo is only 4.
(using vim's ^K and counting keys, not characters. That means shift and
ctrl DO count)
The ` idea is completely different.
Fortunately so.
Also, ditching `` quotes strikes me as a fairly dreadful idea.
Because you're used to them. You're also used to many other things that
change when you go from Perl 5 to Perl 6.
If you dislike when symbols get to mean different things, reading about
Perl 6 must be a terrible experience for you.
Yes, I could use qx// instead, but I could also use qq// instead of
.
If it were up to me, qx would also be removed from the language and only
readpipe would be left.
Ultimately, ` looks like an opening quote character, and so people will
expect it to behave like one. I think that violates the principle of
least surprise.
Least surprise is important for constructs that aren't used
continuously. Whatever is used throughout people's source code,
*defines* what people expect and is therefore after seeing it for the
first time no longer a surprise.
Some people say {} looks like a code block, and that so people will
expect it to behave like one. However, Perl 6 also uses it for hash
reference constructing, hash subscripting, alternative delimiters, rule
blocks, and perhaps even other things.
Perl 5 and PHP coders will expect . to be concatenating, - to be
for calling methods. What people expect because they are used to other
programming languages does not matter at all. The language should be
a consistent universe within itself. If THAT it is not, you are
violating the principle of least surprise.
Believe me, any non-Perl-6 coder will be surprised when seeing Perl 6 in
action. And that is a good thing.
Juerd
Re: backticks
Juerd == Juerd [EMAIL PROTECTED] writes: Juerd readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses Juerd can be found. Most are in Debian's modules. That's because they aren't particularly interesting in modules, but in 10 line scripts, they show up quite frequently. This undermines the rest of your request. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: backticks
On Wed, Apr 14, 2004 at 01:56:35PM -0700, Randal L. Schwartz wrote: That's because they aren't particularly interesting in modules, but in 10 line scripts, they show up quite frequently. This undermines the rest of your request. No, actually, it doesn't. Juerd doesn't seem to like ``, but that point is entirely orthogonal to the introduction of the ` dereferencing operator. The two uses don't conflict. (which is why I was able to make a patch that adds the `-operator to perl 5.8.3) -- Matthijs van Duin -- May the Forth be with you!
Re: backticks
Randal L. Schwartz skribis 2004-04-14 13:56 (-0700): Juerd == Juerd [EMAIL PROTECTED] writes: Juerd readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses Juerd can be found. Most are in Debian's modules. That's because they aren't particularly interesting in modules, but in 10 line scripts, they show up quite frequently. This undermines the rest of your request. How unfortunate that you didn't notice that I made two separate requests, that both have to do with backticks. Request one: Remove `` and/or qx, because its interpolation is dangerous and solutions like it should be discouraged. Request two: Add %hash`key %hash`key can exist without `` gone. `` can be removed without ` meaning something else. It would, however, for understandability, be nicer if both requests were granted. Please, re-read my post and comment on the second request as insightfully as you did on the first. Juerd
