backticks
Juerd
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?
I think even qx// is too short for something that is almost never used
and is actively discouraged because interpolating values in shell
command lines is dangerous.
There is something that is used much more often than readpipe, and it
was recently made harder to type. Hash subscripts. %hash{'key'} works,
%hash<<key>> does too, but they're both a lot of typing. I never liked
typing the {} anyway, and now there is even more to type. Don't get me
started on 姣, which doesn't even get rendered with my current terminal
settings, and is 8 key presses in total.
In Javascript, arrays are objects, objects are arrays. The . operator is
the same one as [], except you can use an expression in [].
parent.frames[1].document.forms['login'].elements['password'].value
equal:
parent.frames.1.document.forms.login.elements.password.value
I like that a lot, because it saves a lot of typing and in simple cases
actually makes reading the code easier. Template Toolkit also lets you
use hashes like this.
[% hash.key %]
However, there is an obvious clash when some bareword is both an
existing key and an existing method. I'd have to look up or try to see
what in TT [% hash.keys.5 %] does if hash.exists('keys') and it is an
array reference.
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'}
can then also be written as:
%hash`key
$hashref`foo`bar`baz`quux
%hash`$key
$object.method`key
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'}
With even more imagination, but I still think it would be a good idea,
this can also be hijacked by the :foo pair constructor, to quote a
single simple bareword.
key => 'value'
:key('value')
:key`value
use Some::Module :foo :bar :baz`quux :xyzzy;
In case it was not already obvious, I'd like to stress that I'm not
proposing to use ` as something that is balanced. It's unary.
Apocalypse 2 says about the unbalanced ' in Perl 5:
And although we're adding a properties feature into Perl 6 that is
much like Ada's attribute feature, we won't make the mistake of
reintroducing a syntax that drives highlighting editors nuts. We'll
try to make different mistakes this time.
I disagree. It's not as if many editors will handle "$foo{"bar"}"
correctly out of the box. I can't even imagine a way to make that look
nice. So let's just have this autoquoting, method-ish `, please. Hashes
are used a lot in Perl and ` is in an extremely easy to type place.
It's a shame to give away that beatiful key to readpipe if you can use
it for hashes instead.
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
Juerd
Matthijs Van Duin
>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
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!
Chromatic
> 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?
-- c
Jonathan Scott Duff
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
du...@pobox.com
Juerd
> > 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 %foo<<foo 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
Juerd
> 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}
No, for the very common %foo{'key'}, since recently also known as
%foo<<key>>.
%foo{key} is %foo{ key() } in Perl 6's current design.
Juerd
Chromatic
> 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 %foo<<foo 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
John Williams
> 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
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.
Juerd
> 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
Juerd
> 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.
>
> 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
Scott Walters
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
Matthew Walton
> 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.
Aaron Sherman
> 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 <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Juerd
> 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
Juerd
> >%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
Randal L. Schwartz
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
<mer...@stonehenge.com> <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!
Matthijs Van Duin
>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)
Juerd
> >>>>> "Juerd" == Juerd <ju...@convolution.nl> 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
Simon Cozens
> $ find . -name \*.pl | wc -l
> 330
> $ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
> 123
>
> `` gets used an awful lot
But that's in Perl 5, which is a glue language.
--
"Though a program be but three lines long,
someday it will have to be maintained."
-- The Tao of Programming
Jarkko Hietaniemi
> hash slices aren't used much at all.
People *always* overgeneralize.
Matthijs Van Duin
>> %hash`$key
>
>oops, you contradicted yourself here. "only be useable for \w+ keys"
I guess you disliked his idea so much you didn't bother to read what exactly
he said, right?
"As with methods, a simple [...] scalar should be usable too"
This is of course natural.. many places in perl accept either a bareword or
simple scalar, at least in p5.
>You are repeating the errors of javascript. $0[15] != $0{15}
No, he spotted the issue in advance and suggested a solution already.
Scott Walters
You'd do well to not remove the conclusion of my post when the conclusion
is that the I strongly support you. Otherwise, your reply, read out of
context, sounds like you're fending off an attacker ;)
People would do well to seperate the merits of the idea from the merits of the
suggested implementation. I'd like to see people say "I like the idea but
the implementation isn't workable" or alternatively "The ` operator isn't
that important but I'm not sure the idea merits the change". I hate one
negitive with the other implied.
If I understand correctly, Perl looks for either a term or operator
at any given moment. %hash and `rf -rm *` are both terms, hence
%hash `rf -rm *`
makes no sense. Aside from playing hell with editors quoting, something
proposed to be solved by making the real grammar of Perl available in
a modular way for inclusion in editors, is there any reason that they
couldn't coexist?
%hash ~ `rf -rm *`
%hash`rf`rm
Failing that, back to whitespace dependencies?
%hash{'aliens!!'}
for keys %hash {
.ate_my_buick
}
-scott
On 0, Juerd <ju...@convolution.nl> wrote:
>
Scott Walters
for hash subscripting ease. If it requires fewer keystrokes or neuron fires to
write Perl 4 code, then Perl 6 might be succeding on the programming in the
small but failing at programming in the large.
${'bar'} = 'baz!'
%foo`bar = 'baz!'
%foo<<bar>> = 'baz!'
On a related note, has anyone seen my semicolon key? It was last spotted in
central park around 5am...
-scott
Luke Palmer
> Juerd,
>
> You'd do well to not remove the conclusion of my post when the conclusion
> is that the I strongly support you. Otherwise, your reply, read out of
> context, sounds like you're fending off an attacker ;)
>
> People would do well to seperate the merits of the idea from the merits of the
> suggested implementation. I'd like to see people say "I like the idea but
> the implementation isn't workable" or alternatively "The ` operator isn't
> that important but I'm not sure the idea merits the change". I hate one
> negitive with the other implied.
>
> If I understand correctly, Perl looks for either a term or operator
> at any given moment. %hash and `rf -rm *` are both terms, hence
>
> %hash `rf -rm *`
>
> makes no sense. Aside from playing hell with editors quoting, something
> proposed to be solved by making the real grammar of Perl available in
> a modular way for inclusion in editors, is there any reason that they
> couldn't coexist?
No there's not. We wouldn't even have to fall back to whitespace. The
distinction is the same as that between / for division and / for
starting a pattern. Interestingly, neither ' nor " has any meaning in
operator position, either.
That said, I have mixed feelings about the idea. I am thoroughly
convinced that ` can leave it's current job. Removing qx// would be
going a leap too far.
I think %hash`key is about as pretty as a perl 5 regular expression.
Plus, we already have two hash dereferencing syntaxen. It might be nice
just to let ` go, since we constantly find new things that would like to
be represented by operators, while we are out of operators. After all,
we're using two latin-1 operators in the core.
I agree that balancing brackets are annoying where they don't need to
be, but I think you're focusing on the wrong area. Keep in mind that
you're proposing a syntax for single atoms, so C<word> is replaced only
by C<{word}> or C<«word»>, not C<{word ...}> or something. Those are
the brackets that are easy to see. The hard ones are the ones that
start in column 8 and end in column 65.
I'm arguing for now that ` be removed as a synonym for qx//, and not
added as anything else until we find a good use for it.
And for your viewing enjoyment:
macro infix:` ($hash, $key)
is parsed(/ $?key := (\$? \w+) /)
is tighter(&infix:.)
{
if $key ~~ /\$/ {
"($hash.text()).{$key}";
}
else {
"($hash.text()).«$key»";
}
}
Luke
Chris
manner similar to how I just implemented it in Ruby? Surely Perl will have
similar capabilities to handle unknown methods.
class Hash
def method_missing(method_name)
str = method.id2name
if str =~ /^\w+$/ then self[str] else super(method_name) end
end
end
h = {"foo" => "bar"}
h.foo # "bar"
h.baz # nil
h.length # 1
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004
Joe Gottman
----- Original Message -----
From: "Simon Cozens" <si...@simon-cozens.org>
To: <perl6-l...@perl.org>
Sent: Wednesday, April 14, 2004 5:04 PM
Subject: Re: backticks
> a...@ajs.com (Aaron Sherman) writes:
> > $ find . -name \*.pl | wc -l
> > 330
> > $ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; |
wc -l
> > 123
> >
> > `` gets used an awful lot
>
> But that's in Perl 5, which is a glue language.
>
And Perl 6 isn't? I use backticks quite a bit in Perl, and I don't see
that changing if I upgrade to Perl 6.
Joe Gottman
Jonathan Scott Duff
> > a...@ajs.com (Aaron Sherman) writes:
> > > $ find . -name \*.pl | wc -l
> > > 330
> > > $ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; |
> wc -l
> > > 123
> > >
> > > `` gets used an awful lot
> >
> > But that's in Perl 5, which is a glue language.
> >
>
> And Perl 6 isn't? I use backticks quite a bit in Perl, and I don't see
> that changing if I upgrade to Perl 6.
Me too, but I write my backticks like qx() :)
Dave Whipp
news:20040415023...@pobox.com...
I was just thinking that it would be nice if qx was a :prefix operator with
a bit of clever parsing, so you could write in lisp style:
(qx rm -rf /usr/bin/perl*);
And then, in the spirit of perl6's elimination of parentheses where
possible:
qx rm -rf usr/bin/* ;
(i.e. it goes to the end of the current expression-scope). Perhaps a
"qx<<"HERE";" form could be useful, too.
If we could implement such a prefix:qx operator (as a macro?), then the qx
form would be only one char (the space) more than the backtick form.
Dave.
David Storrs
>
> If on your keyboard ` is in a worse place than {}, I'd like to know
> where it is.
>
> Juerd
Very top row, one space right of the F12 key. Extremely awkward.
(This is a US keyboard on a Dell Inspiron 5100 laptop.)
Please put me down as strongly against this idea because:
1) ` looks like it should be a bracketing operator
2) In some fonts, ` is hard to see.
3) In some fonts, ` is hard to disambiguate from ' if you can see it.
4) This argument has not been made strongly enough to make me want to
give up one of the few remaining single character operators
(remaining, anyway, if @Larry decides that ` should get an
independent existence as a unary operator).
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.)
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.
--Dks
Trey Harris
> 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 C<key>, 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.
Juerd
> 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 <2004041419...@c4.convolution.nl>, 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
Juerd
> 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
Aaron Sherman
> a...@ajs.com (Aaron Sherman) writes:
> > `` gets used an awful lot
>
> But that's in Perl 5, which is a glue language.
I'm not sure I fully agree with that. Perl 5 *can* be a glue language,
and so can Perl 6. They are not terribly distinct in that way.
There may be OTHER purposes that Perl 6 is more suited to (quite a few I
hope, or this is all just silly), but for existing glue-like tasks, I
think Perl 6 will continue to serve the same valuable role.
The point was made that Perl 5 doesn't use backticks much, so they
should be huffmanned out. I posted a counter to the assumption. Nuff
said.
Juerd
> >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
Juerd
> On Wed, 2004-04-14 at 16:56, Juerd wrote:
> > How many of those backticks
> 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
Scott Walters
irrevocably set):
* %hash<<foo>> 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 %hash<<foo>>)
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
Matthijs Van Duin
>Let me summerize my undestanding of this (if my bozo bit isn't already
>irrevocably set):
>
>* %hash<<foo>> retains the features of P5 $hash{foo} but does nothing to
>counter the damage of removal of barewords
Actually, %hash<<foo>> will be like p5's $hash{"foo"}, and more generally
%hash<<foo 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"}
%hash<<foo>>
%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)
Chromatic
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 %hash<<foo>>)
> 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
Scott Walters
* 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
Larry Wall
: 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
Austin Hastings
> -----Original Message-----
> From: Scott Walters [mailto:sc...@illogics.org]
> Sent: Thursday, 15 April, 2004 03:27 PM
> To: ju...@c4.convolution.nl Juerd
> Cc: perl6-l...@perl.org
> Subject: Re: backticks
>
>
> Let me summerize my undestanding of this (if my bozo bit isn't already
> irrevocably set):
>
> * %hash<<foo>> 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 %hash<foo> 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 C<use
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
%hash<<foo>>)
> 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
Dave Mitchell
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.
Mark J. Reed
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> %hash<<foo>>) 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
Mark J. Reed
> 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
Juerd
> 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
Abhijit A. Mahabal
ask if the following will be supported in some form:
If I have some structure like %foo{"monday"}, %foo{"tuesday"} etc,
I can set their values enmass using:
%foo<<monday tuesday wednesday>> = <<a b c>>;
What if I had
%foo{"monday"}{"food_expenditure"} = 10;
%foo{"tuesday"}{"fuel_expenditure"} = 100;
%foo{"monday"}{"food_expenditure"} = 15;
%foo{"tuesday"}{"fuel_expenditure"} = 150;
Can I say %foo... = <<10 100 15 150>>;
for some definition of ...?
I don't claim that we'd need that frequently.
We probably do need the array version of the same problem frequently,
though:
@matrix... = <<1 0 0 1>>;
At least we'd need it more frequently if we had it. A2 says that something
like this will be supported, come A9.
--Abhijit
Abhijit A. Mahabal http://www.cs.indiana.edu/~amahabal/
Juerd
> 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
David Storrs
> 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
Chromatic
> 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
Austin Hastings
> -----Original Message-----
> From: Juerd [mailto:ju...@convolution.nl]
> Sent: Thursday, 15 April, 2004 05:09 PM
> To: Dave Mitchell
> Cc: perl6-l...@perl.org
> Subject: Re: backticks
>
>
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. C<mod> 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... :-) :-) :-)
Juerd
> 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 @foo@10 does so even more.
Not to mention @foo@10%bar. I like ` because it's a small but
recognisable glyph. (And because of its location on most keyboards.)
Juerd
Thomas A. Boyer
>That said, I have mixed feelings about the idea. I am thoroughly
>convinced that ` can leave it's current job. Removing qx// would be
>going a leap too far.
>
But I really hate the idea of removing `...` and leaving qx/.../. That
would leave qx// in the unenviable position of being the only
"quote-like operator" that doesn't have a corresponding quote-like
syntax. After all, the only real point of having qx[], qx(), qx{}, qx//,
et. al. is so you can get the effect of `...` without having to quote
your backticks.
Well, maybe that's not the only point. Some people really prefer
bracketing punctuation marks that are reflections of each other.
I am not particularly fond of the idea of abolishing the established
role of `...`. Nor do I like the %hash`keyval syntax; it gives me the
"Eat at $joe's" willies. But *please* either keep *both* of qx// and
`...`, or eliminate *both* of them. Either one without the other doesn't
make much sense to me.
In defense of `...`, I suspect it is used most heavily in one-liners at
a command prompt -- where saving keystrokes is most important, and where
its uses aren't cataloged anywhere (so my suspicions can't be easily
verified or falsified).
However, I really do like the idea of having a special syntax for
%hash{'keyval'}. As I've said, I don't like ` for the purpose. But OTOH,
I don't have any better suggestion for a syntax. Except to point out
that if you're frequently accessing a hash via constant strings, you're
probably using it like a record. And in Perl 6, that's better spelt as
$obj.keyval.
=thom
Smile, they said,
it could be worse.
So, I did...
And it was.
Austin Hastings
> -----Original Message-----
> From: Abhijit A. Mahabal [mailto:amah...@cs.indiana.edu]
> Sent: Thursday, 15 April, 2004 05:13 PM
> To: perl6-l...@perl.org
> Subject: Array/Hash Slices, multidimensional
>
>
> As the hash syntax is being worked out, I thought it'd be a good time to
> ask if the following will be supported in some form:
>
> If I have some structure like %foo{"monday"}, %foo{"tuesday"} etc,
> I can set their values enmass using:
> %foo<<monday tuesday wednesday>> = <<a b c>>;
>
>
> What if I had
> %foo{"monday"}{"food_expenditure"} = 10;
> %foo{"tuesday"}{"fuel_expenditure"} = 100;
> %foo{"monday"}{"food_expenditure"} = 15;
> %foo{"tuesday"}{"fuel_expenditure"} = 150;
>
> Can I say %foo... = <<10 100 15 150>>;
> for some definition of ...?
No, but thanks to Luke Palmer's "outer" opiterator, you can get it in a
loop.
See http://www.perl.com/lpt/a/2004/03/p6pdigest/20040328.html
Something like:
my @workdays = <monday tuesday wednesday thursday friday>;
my @expense_categories = <food fuel lodging travel airfare telephone
misc>;
my @error_prone_list_of_unremarked_numbers = (...);
for outer(@workdays, @expense_categories) -> $day, $cat
{
%foo{$day}{$cat} = shift @error_prone_list_of_unremarked_numbers;
}
Or whatever.
>
> I don't claim that we'd need that frequently.
>
> We probably do need the array version of the same problem frequently,
> though:
>
> @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 <<list of numbers>> approach will
work, but it will take all the numbers through a string phase first,
followed by needless conversion.)
> At least we'd need it more frequently if we had it. A2 says that something
> like this will be supported, come A9.
According to popular wisdom, each Apocalypse appears after the previous one
in something like F(n) months, where F(n) is the nth Fibonacci number.
Currently we're waiting for A6, which is secretly the 7th one, since A7
slipped early. Guess how long it will be until A9?
=Austin
Matthijs Van Duin
>%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 @foo@10 does so even more.
>Not to mention @foo@10%bar. 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)
Austin Hastings
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
Juerd
> $foo % bar
" % " is 4 keys: space, shift, 5, space. Too much, IMHO.
Typability and readability are both VERY important.
Juerd
Juerd
> But I really hate the idea of removing `...` and leaving qx/.../. That
> would leave qx// in the unenviable position of being the only
> "quote-like operator" that doesn't have a corresponding quote-like
> syntax.
s, rx, tr
> After all, the only real point of having qx[], qx(), qx{}, qx//, et.
> al. is so you can get the effect of `...` without having to quote your
> backticks.
I see it the other way around: '' is a way of getting q// without the q,
"" is a way of getting qq// without the qq, etcetera.
> However, I really do like the idea of having a special syntax for
> %hash{'keyval'}. As I've said, I don't like ` for the purpose. But OTOH,
> I don't have any better suggestion for a syntax. Except to point out
> that if you're frequently accessing a hash via constant strings, you're
> probably using it like a record. And in Perl 6, that's better spelt as
> $obj.keyval.
Sometimes an object is overkill. I'd say: most of the time.
Juerd
Jonathan Scott Duff
> 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
du...@lighthouse.tamucc.edu Senior Systems Analyst II
Scott Walters
I can only try to accept criticism as well as the rest of the list has.
Apology accepted of course, and an apology of my own to the list who had to
suffer me and chromatic who didn't take me too seriously ;)
-scott
On 0, chromatic <chro...@wgz.org> wrote:
>
Austin Hastings
> -----Original Message-----
> From: Juerd [mailto:ju...@convolution.nl]
>
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
Luke Palmer
Hmm.. that's all well and good, but...
sub deref (%hash, @keylist) is rw {
if @keylist == 1 {
%hash{@keylist[0]}
}
else {
deref %hash{@keylist[0]}, @keylist[1...]
}
}
(map { deref %foo, @^x } outer(@workdays, @expense_categories)) =
@error_prone_list_of_unremarked_numbers;
That doesn't work in Perl 5, but I'm allowed to speculate. :-)
Seriously, we haven't heard the word on the new slicing semantics. All
that may be as easy as:
%foo{@workdays}{@expense_categories} =
@error_prone_list_of_unremarked_numbers;
Though I'd love to be reassured or contradicted... hint, hint.
Luke
Luke Palmer
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
Austin Hastings
> -----Original Message-----
> From: Jonathan Scott Duff [mailto:du...@lighthouse.tamucc.edu]
>
> 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
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
rgh.
[Aside] Though this be madness, yet there is method in't. ;-)
=Austin
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:lu...@luqui.org]
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
Brent 'Dax' Royal-Gordon
> 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 %hash<<foo>> to be typed as %hash<foo>. 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 <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Luke Palmer
> 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
Luke Palmer
> "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
Brent 'Dax' Royal-Gordon
> Brent 'Dax' Royal-Gordon skribis 2004-04-15 16:56 (-0700):
>
>>1. Allow %hash<<foo>> to be typed as %hash<foo>. 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.
>
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 %hash<<foo>>
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<<foo>> 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>
<string>foo</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:
>
> $foo<bar><baz><quux>
>
> $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.
Sean O'Rourke
> 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
John Macdonald
> * Rather than eliciting public comment on %hash`foo (and indeed %hash<<foo>>)
> 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<<foo>>
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.)
--
Juerd
> 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:
$foo<bar><baz><quux>
$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
Juerd
> 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
Mark J. Reed
> 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
Mark J. Reed
> 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
Simon Cozens
> 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.)
Mark J. Reed
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
David Wheeler
> 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_class"><td>$thingies[$i]</td></tr>\n";
}
Pretty useful, actually.
Regards,
David
Austin Hastings
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
Austin Hastings
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
Aaron Sherman
> 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 <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Mark J. Reed
> 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 | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Brent 'Dax' Royal-Gordon
> 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?
Austin Hastings
> -----Original Message-----
> From: Mark J. Reed [mailto:mark...@turner.com]
> Sent: Friday, 16 April, 2004 11:43 AM
> To: perl6-l...@perl.org
> 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
Mark J. Reed
> 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
David Wheeler
> Even with the "xx Inf"? Why?
Oh, right, missed that. Sorry.
David
Aaron Sherman
> > @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 <<list of numbers>> 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.
Brent 'Dax' Royal-Gordon
> 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<<foo>>
>>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<<foo>> than %hash`foo.
>
> 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".
Juerd
> ju...@convolution.nl (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
Juerd
> 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<<foo>>
> 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<<foo>> 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<<WORDS>> 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
Juerd
> > for @thingies, qw(blue yellow) xx Inf -> $thingy, $class {
> > print qq[<tr class="$class"><td>$thingy</td></tr>\n";
> > }
> I think that $class would be C<undef> after the second record in
> @thingies, unfortunately.
Even with the "xx Inf"? Why?
Juerd
Juerd
> 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
Juerd
> 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_class"><td>$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="$class"><td>$thingy</td></tr>\n";
}
Juerd
Jonathan Scott Duff
> 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
du...@lighthouse.tamucc.edu Senior Systems Analyst II
Juerd
> 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
Matthijs Van Duin
>> 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!
Brent 'Dax' Royal-Gordon
> 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<<key>> 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
Aaron Sherman
> 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.
Juerd
> 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<<key>> 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
Jonathan Scott Duff
> 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<<key>> 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<<key>> 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<<foo>> will be
going away and it doesn't look like it will at all. To be fair each
of those descriptions should mention %hash<<foo>> 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
John Macdonald
> 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).
--