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()} ; %fooÂbar is equivalent to
%foo{'bar'}.
Luke
Re: backticks
Juerd wrote:
Brent 'Dax' Royal-Gordon skribis 2004-04-15 16:56 (-0700):
1. Allow %hash<> to be typed as %hash. 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
<> is 9 key presses and 7 characters
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 %hash<>
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 %hash<> 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:
%hash
foo
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:
$foo
$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 %hash<>) > 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 = %hash<> 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 %hash<> to be typed as %hash. 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
<> is 9 key presses and 7 characters
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:
$foo
$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 "$thingies[$i]\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 "$thingies[$i]\n";
> }
>
> Pretty useful, actually.
>
But any real Jolt-swilling, bit-banging 'C' coder would write:
for (i = 0; i < num_thingies; ++i) {
fprintf(ostr, "%s\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, K&R 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 k>0 (% = 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: Array/Hash Slices, multidimensional
On Thu, 2004-04-15 at 18:23, Austin Hastings wrote:
> > @matrix... = <<1 0 0 1>>;
> Keep in mind that you're using a quoting operator. For numbers, you can just
> use (0, 1, 2, 3)
> and probably be better understood. (The <> approach will
> work, but it will take all the numbers through a string phase first,
> followed by needless conversion.)
I agree with most of what you say, but here, you need to be clearer.
In the case of:
@matrix = <<1 2 3 4 5>>;
You need only add the type:
int @matrix = <<1 2 3 4 5>>;
There is no string phase, or at least should never be. The compiler can
pre-compute the list:
int @matrix = ('1','2','3','4','5');
And it then has another obvious pre-computation to perform:
int @matrix = (+'1', +'2', +'3', +'4', +'5');
And since everything is a constant, you end up with:
int @matrix = (1, 2, 3, 4, 5);
It's magic ;-)
The last step above is what I would expect a B::Deparse-like thing for
Perl 6 to produce.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
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 %hash<>
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 %hash<> 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 %hash<>
> 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 %hash<> 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 %foo<> 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[$thingy\n";
> >}
> I think that $class would be C 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 "$thingies[$i]\n";
> }
Probably.
Can't we in Perl 6 just use something like this?
for @thingies, qw(blue yellow) xx Inf -> $thingy, $class {
print qq[$thingy\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";print"d ! @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 %varname<> 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 %varname<> 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 %varname<> 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 %varname<> 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 %hash<> will be
going away and it doesn't look like it will at all. To be fair each
of those descriptions should mention %hash<> 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}
> %stuffï1ï
> %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
On Fri, Apr 16, 2004 at 03:12:58PM -0400, Aaron Sherman wrote: > 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. The guy who mostly writes one-shot short scripts to massage his own data wonders why you want to make his job harder in the name of protecting him against the possibility that his evil sub-concious alter ego is plotting to subvert him. Let me keep my rope dammit. I have no intention of hanging myself. --
RE: Array/Hash Slices, multidimensional
On Fri, 16 Apr 2004, Aaron Sherman wrote:
> > > @matrix... = <<1 0 0 1>>;
>
> In the case of:
>
> @matrix = <<1 2 3 4 5>>;
>
> You need only add the type:
>
> int @matrix = <<1 2 3 4 5>>;
> There is no string phase, or at least should never be.
> The compiler can
> pre-compute the list:
>
> int @matrix = ('1','2','3','4','5');
>
> And it then has another obvious pre-computation to perform:
>
> int @matrix = (+'1', +'2', +'3', +'4', +'5');
>
> And since everything is a constant, you end up with:
>
> int @matrix = (1, 2, 3, 4, 5);
>
This int business may make sense for a one dimensional array, but I meant
@matrix to be 2 dimensional, and hence you'd need something like
my @matrix is Array of Array of Int = <<1 2 3 4 5>>;
# that syntax won't work, obviously, but I do not know how to take slices,
and that was my original question...
It seems to me that trying to get the compiler to do all that for all
sorts of weird constructs is hard, more work than what we get out of it,
and all you'd probably get is something that works for a few special
cases.
In any case, I used <<1 2 3 4 5>> because it is less typing, and I use
stuff like qw{2 3 5 7 11} in P5 all the time.
--Abhijit
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 %varname<> 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 %varname<> 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 %hash<> 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 :foo<> and :foo`a would be :foo(<>) 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
Apocalypse 12
Perl.com has just made A12 available: http://www.perl.com/pub/a/2004/04/16/a12.html Warning -- 20 pages, the first of which is a table of contents. Enjoy, -- c
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 %varname<> 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
