Re: backticks
In a message dated Wed, 14 Apr 2004, David Storrs writes:
Actually, what I'd like to know is when it was decided that %hash{key}
meant %hash{key()}?? Was it in one of the Apocalypses?
Perhaps it wasn't spelled out, but the implication was certainly there.
Barewords are gone. Braces create a closure. A closure consisting only
of pairs returns a hash reference. A closure immediately following a hash
or hashref dereferences the hash. By inference, {key} is a closure
consisting of Ckey, which can't be a bareword since barewords are gone.
Hence it must be a sub call to key().
Trey
--
Trey Harris
Vice President
SAGE -- The System Administrators Guild (www.sage.org)
Opinions above are not necessarily those of SAGE.
Re: backticks
Chris skribis 2004-04-14 17:07 (-0700): Perhaps this is naive, but couldn't something like this be achieved in a manner similar to how I just implemented it in Ruby? Surely Perl will have similar capabilities to handle unknown methods. As explained in [EMAIL PROTECTED], it's not a question of whether it is possible. I know it is possible. Either by changing the grammar or perhaps by adding an operator/macro. And as explained in multiple messages already, implementing this using the . has too large drawbacks. Juerd
Re: backticks
David Storrs skribis 2004-04-14 22:39 (-0700):
Very top row, one space right of the F12 key. Extremely awkward.
(This is a US keyboard on a Dell Inspiron 5100 laptop.)
That is inconvenient.
1) ` looks like it should be a bracketing operator
I think you means circumfix/balanced operator.
2) In some fonts, ` is hard to see.
3) In some fonts, ` is hard to disambiguate from ' if you can see it.
In some fonts, the difference between () and {} is hard to see.
In some fonts, the difference between 1, l and I is hard to see.
In some fonts, the difference between 0 and O is hard to see.
In some fonts, the , is hard to see.
In some fonts, and '' look exactly the same.
Don't use those fonts when programming, period. Use a fixed width font.
No fixed width font that I have ever seen makes ` hard to see.
4) This argument has not been made strongly enough (...)
I'm not here to do anything weakly, strongly or forcefully.
5) I use `` in short utility scripts all the time, and would hate to
lose it. To anyone who says that that is dangerous and should be
discouraged--my machine, my code, my problem. (And I work for
myself, so I am the only one who will be maintaining it.)
As said in several messages in this thread before, `` does not have to
go to support %hash`key. %hash`key has already been succesfully
implemented in perl 5.8.3 and does not harm `` there at all.
Actually, what I'd like to know is when it was decided that %hash{key}
meant %hash{key()}?? Was it in one of the Apocalypses? I missed that
and would like to go back and read the reason for it, since I suspect
that, given a single-term expression in a hash subscript, it is far
more likely to be a literal than a function call. It seems that that
is really the source of the entire 'problem' that this thread
addresses.
No, it only was an extra motivation.
Juerd
Re: backticks
Aaron Sherman skribis 2004-04-14 16:40 (-0400):
From a source tree I work with (which I cannot divulge code from, but I
think statistics like this are fine):
$ find . -name \*.pl | wc -l
330
$ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
123
How many of those backticks are in documentation or string literals? In
my @INC I found a lot of attempts to get balanced single quotes in ASCII
as like `foo'.
And how often are simple hash subscripts used?
Also, how insecure and/or inefficient is this code? In #perlhelp, on
PerlMonks and in many other places, backticks are discouraged.
operators, and I see qx{} as just as good if not better, but to remove
it on the basis of the lack of use is faulty.
Removing and replacing the meanings of glyphs on the basis of use is
one of the most important changes in Perl 6.
After all, - becomes . and - gets a new meaning.
| becomes +| (or ~|, ?|) and | gets a new meaning.
Etcetera.
Lack of use as a reason for changing something is not faulty, it is
exactly what should be done.
BUT `` do not have to go because I have ` in mind for something else.
The two things can co-exist, as Matthijs pointed out with his Perl 5
patch. I think it has to go because `pwd`, `hostname`, `wget -O - $url`
should not be easier than the purer Perl equivalents and because ``'s
interpolation does more harm than good.
I would have preferred that Perl 6 used the bash/zsh-style:
$(...)
It's just one keyword and a set of quotes more: $( readpipe pwd )
Juerd
Re: Compatibility with perl 5
On Wed, 2004-04-14 at 21:23, Gregor N. Purdy wrote: Lets try that again, since I think you parsed my email in a way I didn't intend (and its at least 50% my fault) Hey! *I* have to step up for 50% of the blame now? Where's my lawyer! ;-) In my opinion, starting a script with #!/usr/bin/perl6 should force the interpreter to treat it like Perl 6, and if it does anything else that's just ugly. I disagree, but it's a point of aesthetics that I'm willing to concede as ugly to some, perhaps many, perhaps most. I don't see any need to have a program start out as a potentially Perl 5 program and then determine that it should really be thought of as Perl 6 and switch personalities. That is, I don't see a need for this: #!/usr/bin/perl use 6; I think you meant perl5 there... I will assume you did. Ok, yes I see your point. Taking from what I said earlier: #!/usr/bin/perl5 should probably be sugar for: #!/usr/bin/perl use 5; Which means that #!/usr/bin/perl5 use 6; translates to: #!/usr/bin/perl use 5; use 6; Your (p6l) call as to if that should be an error or not. At the very least, I bow to the wisdom of it being a warning (perhaps optional). #!/usr/bin/perl6 ... # Perl 6 stuff here use 5; # or, whatever # Perl 5 stuff here no 5; # or, whatever Oh please, please, please no! At the very least, force that to be lexically scoped as Larry suggested, but I beg of you to not even go that far. Allowing parser re-definition on the fly is one thing, but providing a handy tool that can be thrown inline anywhere by people who don't yet feel comfy with Perl 6, that does it all for you, is asking for a level of pain which I'd have to consult a scorned woman on, cause I know it's gonna be at least a touch worse than hell trying to maintain that code :-/ The problem is not the syntax, or even really the grammar, but the semantics... Parrot lets you smooth out the semantics to a subroutine / class / method / data access level, but to allow such free-form mixing is gonna be ugly. My personal feeling is that use 5; ... anything else ... use 6; should be an error, and if you want to write your own support for My5 and My6 which don't give an error, CP6?PAN6?'s doors will be wide open. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Compatibility with perl 5
Gregor N. Purdy wrote: Personally, I view Perl 6 as such a completely new language (although still Perlish in spirit, it is very different in other respects), that I would be perfectly happy to be required to start all my Perl 6 programs with #!/usr/bin/perl6 instead of #!/usr/bin/perl, just the same as I'd start a Python program with #!/usr/bin/python. I second that. It should work, but maybe doesn't have to be required. Here's an idea how few different disambiguating methods (i.e. perl binary name, pragmas, command line switches and class-like keywords) could all work together in a fairly clear and consistent manner. It requires a little change of Cuse VERSION meaning in Perl 6 but only in a case where it no longer makes sense anyway. Perl 6 language is not backwards compatible with Perl 5, so Cuse 5 in Perl 6 should not just mean Perl v5.0.0 or higher required like it does now, but rather v5.0.0 or higher, but lower than v6.0.0. Cuse 5 and Cuse 6 should disambiguate between Perl 5 and 6 in a program run by perl 6 interpreter. Cpackage just implies Cuse 5 Cclass et al implies Cuse 6 There is already a command line switch for one-liners -M6 which works as it should, without any changes to perl 5: $ perl -M6 -e 'print ok' Perl v6.0.0 required--this is only v5.6.1, stopped (did you mean v6.0.0?). BEGIN failed--compilation aborted. (There might be a new switch -6 introduced, which could mean -M6 for: perl -6e '...' or maybe even -6 could mean -M6 -e so this would work: perl -6 '...' making the -6 a Perl 6 equivalent to -e which itself would always introduce Perl 5 code, allowing all of the existing one-liners to keep working. In any way, simple perl -e should default to Perl 5.) When the perl binary name ends with a version number, the -MVERSION might be implied, so perl6 or p6 (I'd love perl6 to have p6 as a standard link) would mean perl -M6 much like egrep is the same as grep -E. (It is not enough to match a digit 6 at the end, since perl-5.6 should mean perl -M5.6 and not perl -M6 but /(\d+(?:\.\d+)*)$/ (perl5-style regex) should be ok.) The most important thing would be that all of this different ways of switching between Perl 5 and 6 could consistently work as use VERSION (maybe giving a warning in the implicit package and class cases to catch errors in Perl 6, but maybe not) so this pathological case: #!/usr/bin/p6 -M5 class main; # A use 5; # B would be exactly equivalent to: #!/usr/bin/perl use 6; # from the binary name use 5; # from the -M5 use 6; # from class class main; # A use 5; # B Now, it might be debatable whether the above code should be allowed or not. Maybe not. Maybe only one 5/6 disambiguation should be allowed, or all of them should be consistent in the entire file, or at least after the first non-Cuse VERSION statement. In any case I think it all could be just a syntactic sugar for a simple Cuse VERSION. Such a disambiguated Perl 6 code would not be run by perl5 by accident, since use 6 or -M6 will give a correct error, there should be no binary called perl6 and the -6 switch would not work. The Cuse 5 or -M5 can already be used in Perl 5 programs. The only change in current use VERSION meaning would be to make versions below 6.0.0 mean VERSION or higher, but below 6; enter Perl 5 compatibilty mode (which makes sense anyway, since it is no longer backwards compatible). This change is not needed in Perl 5. Of course it would all be optional. In case of no use VERSION or -MVERSION with simple perl binary and no class or package, perl would do whatever is planned to do right now. I believe it is consistent with all of the current plans and doesn't need any change to Perl 5. Any comments? -- ZSDC
Re: Compatibility with perl 5
Gregor N. Purdy [EMAIL PROTECTED] writes: ... that I would be perfectly happy to be required to start all my Perl 6 programs with #!/usr/bin/perl6 instead of #!/usr/bin/perl, Ten years ago I was perfectly happy to start all my perl programs with /usr/bin/perl5. Today, I would be quite unhappy if I *still* needed to do it that way. -- Johan
Re: Compatibility with perl 5
On Thu, 2004-04-15 at 13:23, Johan Vromans wrote: Gregor N. Purdy [EMAIL PROTECTED] writes: ... that I would be perfectly happy to be required to start all my Perl 6 programs with #!/usr/bin/perl6 instead of #!/usr/bin/perl, Ten years ago I was perfectly happy to start all my perl programs with /usr/bin/perl5. Today, I would be quite unhappy if I *still* needed to do it that way. Of course, and you should not have to. That's why, in absence of any other tricks, perl would try to figure out what you meant to do, but you CAN be explicit. I would not be happy about the long-term re-naming of the perl binary, because that entrenches perl6 as the name of a program (ask the old gcc 2.0 guys why that's a bad idea...), but if that's just one of several options (like my current /usr/bin/perl5.8.3), then it seems like a good thing. I'll probably continue to write: #!/usr/bin/perl use 6; and add: use 5; to my existing Perl 5 programs that I don't have time to convert. That doesn't mean it's the only way to do it. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: backticks
Aaron Sherman skribis 2004-04-15 14:29 (-0400): On Wed, 2004-04-14 at 16:56, Juerd wrote: How many of those backticks Note, those weren't backticks, those were programs. There were 123 PROGRAMS that used backticks or equivalent syntax. I said backticks, and I meant backticks. I'm not sure why there is confusion over this. Perhaps this can disambiguate: how many of those backticks in those 123 programs. And how often are simple hash subscripts used? Very often. Many times as often as qx and friends? Security is not an issue for this code. It should be. code review? You made and assertion: backticks aren't used much. That assertion is faulty. I didn't formulate my statement carefully enough. I should have said: as much as hash subscription. Executing external code is commonplace, and probably done more often than method invocation in the wild! I want to doubt that. Or better: help change that. It's just one keyword and a set of quotes more: $( readpipe pwd ) And thus, it is not like the bash/zsh style syntax in the least. Why should Perl have to limit itself to shell-like syntax? It doesn't do that with if-constructs, foreach-loops, procedures, etcetera, etcetera, etcetera. Unless there is substantially new information in this thread, I think you have presented your case for yet another new subscripting syntax. I think I have presented two cases. The removal of `` and the introduction of %hash`key. Either can be implemented without breaking the other, though I obviously think both letting `` go and introducing the infix ` is better. Juerd
Re: backticks
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hashfoo retains the features of P5 $hash{foo} but does nothing to counter the
damage of removal of barewords
* %hash`foo occupies an important nitch, trading features (slice, autovivication)
to optmize for the common case, undoing the pain of the loss of barewords,
serving as even a superior alternative
* %hash`foo and %hash ~ `ls` can coexist without breaking anything as this is currently
illegal, unused syntax
* %hash`foo can be added by the user, but users are seldom aware of even a small
fraction
of the things on CPAN and there is a sitgma against writing non-standard code
* %hash`s is an example of a small thing that would be easy to implement in core
but would be used constantly (if JavaScript is any indication, every few lines),
giving a lot of bang for the buck
* Rather than eliciting public comment on %hash`foo (and indeed %hashfoo)
the proposal is being rejected out of hand (incidentally, the mantra of the Java
community Process seems to be you don't need X, you've got Y, and it took
.Net before they woke up and realized that maybe they should consider their
community in the community process - after ignoring a universal call for
generics for over 5 years it's little wonder .Net ate their cake)
-scott
On 0, [EMAIL PROTECTED] Juerd [EMAIL PROTECTED] wrote:
Aaron Sherman skribis 2004-04-15 14:29 (-0400):
On Wed, 2004-04-14 at 16:56, Juerd wrote:
How many of those backticks
Note, those weren't backticks, those were programs. There were 123
PROGRAMS that used backticks or equivalent syntax.
I said backticks, and I meant backticks. I'm not sure why there is
confusion over this.
Perhaps this can disambiguate: how many of those backticks in those 123
programs.
And how often are simple hash subscripts used?
Very often.
Many times as often as qx and friends?
Security is not an issue for this code.
It should be.
code review? You made and assertion: backticks aren't used much. That
assertion is faulty.
I didn't formulate my statement carefully enough. I should have said:
as much as hash subscription.
Executing external code is commonplace, and probably done more often
than method invocation in the wild!
I want to doubt that. Or better: help change that.
It's just one keyword and a set of quotes more: $( readpipe pwd )
And thus, it is not like the bash/zsh style syntax in the least.
Why should Perl have to limit itself to shell-like syntax? It doesn't do
that with if-constructs, foreach-loops, procedures, etcetera, etcetera,
etcetera.
Unless there is substantially new information in this thread, I think
you have presented your case for yet another new subscripting syntax.
I think I have presented two cases. The removal of `` and the
introduction of %hash`key. Either can be implemented without breaking
the other, though I obviously think both letting `` go and introducing
the infix ` is better.
Juerd
Re: backticks
On Thu, 2004-04-15 at 12:27, Scott Walters wrote: Without commenting on the rest of the proposal, please allow me to clear up one point: * Rather than eliciting public comment on %hash`foo (and indeed %hashfoo) the proposal is being rejected out of hand This whole thread *is* public comment. Some people like it, some people don't. Some people think it's useful. Some people think it's ugly. Some people think it simplifies things. Some people think it complicates things. Larry hasn't weighed in. Larry might not weigh in. Larry might like it. Larry might not. Larry might think it solves a real problem and come up with a nicer unification that almost everyone can live with. Hey, it's happened plenty of times before. (incidentally, the mantra of the Java community Process Now that's just rude. You are welcome to think that a certain proposal you like is the best thing ever and should certainly go in Perl 6 for whatever reason -- but claiming that the proposal has been rejected out of hand on a public mailing list where people are discussing the proposal and some people like it and some people don't is rather silly. -- c
Re: backticks
On Thu, Apr 15, 2004 at 12:27:12PM -0700, Scott Walters wrote:
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hashfoo retains the features of P5 $hash{foo} but does nothing to
counter the damage of removal of barewords
Actually, %hashfoo will be like p5's $hash{foo}, and more generally
%hashfoo bar is @hash{qw(foo bar)}, if I'm not terribly mistaken.
It's plain %hash{foo} that's affected.
So to summarize, the following would be equivalent:
%hash{foo}
%hashfoo
%hash`foo
* %hash`foo occupies an important nitch, trading features (slice,
autovivication) to optmize for the common case, undoing the pain of the
loss of barewords, serving as even a superior alternative
Autovivication is still possible, though the exact details would need to
be worked out. (Either always autovivify as hash, or make it dependent on
whether the key matches /^-?\d+\z/ )
But indeed, this is my best argument too: hashes are one of perl's top
core features, and indexing with constant words or simple scalar variables
are the most common ways of using them. It's used so much that by the
huffman principle it deserves very short and convenient notation.
* %hash`foo can be added by the user, but users are seldom aware of even a
small fraction of the things on CPAN and there is a sitgma against writing
non-standard code
I fear that very much too. I'd probably not use the syntax either in public
code (like CPAN modules) if it required a non-core module, since it would be
silly to require an external module just for syntax sugar.
Instead, I'd just be annoyed at it being non-core.
* %hash`foo and %hash ~ `ls` can coexist without breaking anything as this
is currently illegal, unused syntax
* %hash`s is an example of a small thing that would be easy to implement in
core but would be used constantly, giving a lot of bang for the buck
* Rather than eliciting public comment on %hash`foo the proposal is being
rejected out of hand
Exactly. Juerd may have accidently aggrevated the situation by implying in
his original post that %hash`key requires the removal of ``. It's clear now
that the two issues are separated and should be discussed separately.
In case it's not obvious, I'm very much in favor of %hash`foo. (I'm not
entirely sure yet how I feel about removing ``... maybe just leave it until
a better application for those ticks can be found)
--
Matthijs van Duin -- May the Forth be with you!
Re: backticks
It's you. * My objection to the Java community process applies in _some_ _small_ part to the Perl community process. I present it as a negative ideal with the implication that it should be avoided. * My objection to it being rejected out of hand applies not to the Perl community process nor to the people that think i's ugly. I don't argue subjectives. I say people are eager because they've ignored repeated clarifications, continueing to cite groundless technical reasons. That I can aruge =) I interpret this as haste, and it is this haste I object to. * Hence my goal to summarize and prod gently at the eagerness of some. So, my apologies to who anyone who feels unfairly or excessively criticized, except chromatic. There is no forgiveness for someone who seeks out irked people with the single goal of further irking them. Since chromatic is so eager to be offended on behalf of other people I hope you really enjoy being offended. Na na na! One of these days I'm going to resolve to hunt you down to irritate you as you do to me. -scott On 0, chromatic [EMAIL PROTECTED] wrote: On Thu, 2004-04-15 at 12:27, Scott Walters wrote: Without commenting on the rest of the proposal, please allow me to clear up one point: * Rather than eliciting public comment on %hash`foo (and indeed %hashfoo) the proposal is being rejected out of hand This whole thread *is* public comment. Some people like it, some people don't. Some people think it's useful. Some people think it's ugly. Some people think it simplifies things. Some people think it complicates things. Larry hasn't weighed in. Larry might not weigh in. Larry might like it. Larry might not. Larry might think it solves a real problem and come up with a nicer unification that almost everyone can live with. Hey, it's happened plenty of times before. (incidentally, the mantra of the Java community Process Now that's just rude. You are welcome to think that a certain proposal you like is the best thing ever and should certainly go in Perl 6 for whatever reason -- but claiming that the proposal has been rejected out of hand on a public mailing list where people are discussing the proposal and some people like it and some people don't is rather silly. -- c
RE: backticks
-Original Message-
From: Scott Walters [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April, 2004 03:27 PM
To: [EMAIL PROTECTED] Juerd
Cc: [EMAIL PROTECTED]
Subject: Re: backticks
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hashfoo retains the features of P5 $hash{foo} but does
nothing to counter the damage of removal of barewords
Actually, it solves the bare words problem -- the is a quoting
syntax, so %hashfoo is akin to
%hash{'foo'}.
As I understand Juerd, the objection is the number of finger movements
required. For me, on a US-intl keymap with a decent keyboard, the guillemets
are alt+[ and alt+] respectively, which is a pretty low cost. The high cost
is the behavior of ' and in the same keyboard mode, which act as composing
characters. For this reason, I'm assuming that some clever windows hacker
will provide a US-perl6 keyboard definition soon after p6 is available, if
not sooner. (I'd do it myself, frankly, if I had the documentation for that
stuff. :-(
* %hash`foo occupies an important nitch, trading features (slice,
autovivication) to optmize for the common case, undoing the pain of the
loss of barewords,
serving as even a superior alternative
It *would* occupy a niche, were it incorporated. Subjunctivity is still
appropriate.
* %hash`foo and %hash ~ `ls` can coexist without breaking anything as this
is currently
illegal, unused syntax
Correct as I understand it, and certainly true in p5, per Matthijs.
* %hash`foo can be added by the user, but users are seldom aware of even a
small fraction of
the things on CPAN and there is a sitgma against writing non-standard code
Probably true. I'm frequently amazed with the things that are dredged up
from CPAN. And I certainly don't download things from CPAN to change my
syntax, so I can see where others wouldn't, either. OTOH, Juerd could do so,
and could code all his code with it, and could virally infect everyone
else by sending out scads of useful scripts, all of which required Cuse
HashTicks;.
* %hash`s is an example of a small thing that would be easy to implement
in core
but would be used constantly (if JavaScript is any indication, every few
lines),
giving a lot of bang for the buck
I disagree with this. I, for one, would never use it. (I don't object to its
inclusion, since my preferred alternative would remain available:
%hash{$foo} or %hash{'foo'}. But I don't like it visually, and I'm too used
to ` as a quoting character to feel comfortable with this usage.)
Also, this reminds me of the old namespace syntax: $package'var. I'm glad
that's gone, too.
* Rather than eliciting public comment on %hash`foo (and indeed
%hashfoo)
the proposal is being rejected out of hand (incidentally, the mantra of
the Java
community Process seems to be you don't need X, you've got Y,
and it took .Net before they woke up and realized that maybe they should
consider their community in the community process - after ignoring a
universal call for
generics for over 5 years it's little wonder .Net ate their cake)
Actually, it seems to me that there has been public comment. Some names that
I recognize have come out on both sides of the issue, indicating that within
the current established p6l posters there is disagreement on the issue.
Juerd Matthijs have pointed out that the capability could be added with
minimal impact on people (like myself) who don't want to use the feature.
Simon has pointed out that (say it with me, everybody: 1 .. 2 .. 3 .. ) It
doesn't have to go in CORE!
So @Larry (of whom chromatic, a detractor, is one) or $Larry will make a
determination of digital direction, directly, and the dilemma will be
decided. (Sorry. :-)
Your feelings about Sun's inability to run an open community
notwithstanding, the p6l list appears to be working fine. People have said
that many of my suggestions were stupid, too, but rejection is not the same
as refusal to listen.
=Austin
-scott
On 0, [EMAIL PROTECTED] Juerd [EMAIL PROTECTED] wrote:
Aaron Sherman skribis 2004-04-15 14:29 (-0400):
On Wed, 2004-04-14 at 16:56, Juerd wrote:
How many of those backticks
Note, those weren't backticks, those were programs. There were 123
PROGRAMS that used backticks or equivalent syntax.
I said backticks, and I meant backticks. I'm not sure why there is
confusion over this.
Perhaps this can disambiguate: how many of those backticks in those 123
programs.
And how often are simple hash subscripts used?
Very often.
Many times as often as qx and friends?
Security is not an issue for this code.
It should be.
code review? You made and assertion: backticks aren't used much. That
assertion is faulty.
I didn't formulate my statement carefully enough. I should have said:
as much as hash subscription.
Executing external code is commonplace, and probably done more often
than method invocation in the wild!
I want to
Re: backticks
On Thu, Apr 15, 2004 at 01:26:47PM -0700, Scott Walters wrote: : So, my apologies to who anyone who feels unfairly or excessively criticized, : except chromatic. There is no forgiveness for someone who seeks out irked people : with the single goal of further irking them. Since chromatic is so eager to : be offended on behalf of other people I hope you really enjoy being offended. : Na na na! One of these days I'm going to resolve to hunt you down to irritate you : as you do to me. Well, I, for one, think chromatic was right on the money. Larry
Re: backticks
Scott * %hash`s is an example of a small thing that would be easy to implement
Scott in core but would be used constantly (if JavaScript is any indication,
Scott every few lines), giving a lot of bang for the buck
Not sure that JavaScript is relevant here, since the equivalent
syntax there, ., is the same as the method call syntax. But see my
proposal below.
Austin I don't like it visually, and I'm too used to ` as a quoting character
Austin to feel comfortable with this usage.) Also, this reminds me of the
Austin old namespace syntax: $package'var. I'm glad that's gone, too.
I agree on all counts.
Scott Rather than eliciting public comment on %hash`foo (and indeed
Scott %hashfoo) the proposal is being rejected out of hand
? Who has rejected it out of hand? And what is this entire thread if not
eliciting public comment?
If I might offer a modest counter-proposal - how about a fallback method
(the equivalent of Perl5's AUTOLOAD or Ruby's method_missing, however
that winds up being spelled in Perl6) that would return the value of the
key equal to the requested method name? Actually, it should return it
as an lvalue to allow the shortcut to be used in assignments. This
wouldn't need to be in the Hash base class; it could be in a subclass
called RhinoHash or some such. Then %hash{'foo'} == %hash«foo» could
also be spelled %hash.foo, as long as 'foo' weren't the name of a hash
method - just as in JavaScript.
It wouldn't work for non-literals, though, unless $obj.$var is going to
be legal for invoke the method whose name is in $var on receiver $obj, which
I don't think it is. But given the need to avoid conflicts with
defined methods, having it work for non-literals would be more problematic
anyway.
-Mark
Re: backticks
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
On the grounds that personally I hate the backtick :-)
--
That he said that that that that is is is debatable, is debatable.
Re: backticks
On 2004-04-15 at 16:49:28, Mark J. Reed wrote:
Not sure that JavaScript is relevant here, since the equivalent
syntax there, ., is the same as the method call syntax. But see my
proposal below.
Before the nit-pickers jump in, I was oversimplifying above. The
method call syntax in JavaScript is really just the operator '(' args*
')', appended to an expression whose value is a reference to a Function
object. JavaScript object.meth(foo) functions roughly like a cross
between Perl5 $object-{'meth'}-($foo) and $object-meth($foo): like
the former, it looks up the value of key 'meth', expects it to be a code
reference, and then executes it; like the latter, it passes the receiver
along with the specified args.
-Mark
Re: backticks
Mark J. Reed skribis 2004-04-15 16:49 (-0400): If I might offer a modest counter-proposal - how about a fallback method (the equivalent of Perl5's AUTOLOAD or Ruby's method_missing, however that winds up being spelled in Perl6) that would return the value of the key equal to the requested method name? No, please not that. When there is a bareword that is both a key and a method, one of the two has to get precedence. Neither option is acceptable and both render using the . for the thing that does not get precedence useless. Option one: methods get precedence Code breaks when methods are added. Option two: keys get precedence Would have to delay everything until runtime. No, if we want a simple and lean operator for this, it must not be one that in the same context also has another function. Juerd
Synopsis 3 not on dev.perl.org?
I found Luke Palmer's Synopsis 3 on perl.com at http://www.perl.com/pub/a/2004/03/18/synopsis3.html but didn't see it out at http://dev.perl.org/perl6/synopsis/. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: backticks
Dave Mitchell skribis 2004-04-15 21:56 (+0100):
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
Yes, there is one. It is a problem that the Perl4-ish package separator
causes in Perl 5 already. One that bites many coders:
Eat at $joe's
means in Perl 5:
Eat at $joe::s
would mean in Perl 6 if we used the ' for hash subscripts:
Eat at $joe{'s'}
Apostrophes are needed in text. Many languages use them to mark the
absence of some letters. I don't know of any such use of the backtick,
except by people new to computers who use them as if they are
apostrophes :)
I dislike the attempt at getting balanced quotes in ASCII that involves
` and ', but it shouldn't be a problem as that in normal use always
follows whitespace or at least interpunction.
On the grounds that personally I hate the backtick :-)
...
Juerd
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:
%foomonday 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/
Re: backticks
On Thu, 2004-04-15 at 13:37, Larry Wall wrote: Well, I, for one, think chromatic was right on the money. No matter how right my thoughts might have been, my tone *was* rude and that's not right. Apologies to Scott. -- c
Re: backticks
On Thu, Apr 15, 2004 at 11:45:27AM +0200, Juerd wrote:
David Storrs skribis 2004-04-14 22:39 (-0700):
Very top row, one space right of the F12 key. Extremely awkward.
(This is a US keyboard on a Dell Inspiron 5100 laptop.)
That is inconvenient.
Yup.
1) ` looks like it should be a bracketing operator
I think you means circumfix/balanced operator.
If you prefer those terms, sure.
2) In some fonts, ` is hard to see.
3) In some fonts, ` is hard to disambiguate from ' if you can see it.
In some fonts, the difference between () and {} is hard to see.
In some fonts, the difference between 1, l and I is hard to see.
In some fonts, the difference between 0 and O is hard to see.
In some fonts, the , is hard to see.
In some fonts, and '' look exactly the same.
All true.
Don't use those fonts when programming, period. Use a fixed width font.
No fixed width font that I have ever seen makes ` hard to see.
I am currently using a fixed width font to read this message. ` is
hard to see.
4) This argument has not been made strongly enough (...)
I'm not here to do anything weakly, strongly or forcefully.
s/strongly/convincingly/
5) I use `` in short utility scripts all the time, and would hate to
lose it. To anyone who says that that is dangerous and should be
discouraged--my machine, my code, my problem. (And I work for
myself, so I am the only one who will be maintaining it.)
As said in several messages in this thread before, `` does not have to
go to support %hash`key. %hash`key has already been succesfully
implemented in perl 5.8.3 and does not harm `` there at all.
You point is granted. However, mine still stands.
--Dks
RE: backticks
-Original Message-
From: Juerd [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April, 2004 05:09 PM
To: Dave Mitchell
Cc: [EMAIL PROTECTED]
Subject: Re: backticks
Dave Mitchell skribis 2004-04-15 21:56 (+0100):
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
Yes, there is one. It is a problem that the Perl4-ish package separator
causes in Perl 5 already. One that bites many coders:
Eat at $joe's
means in Perl 5:
Eat at $joe::s
would mean in Perl 6 if we used the ' for hash subscripts:
Eat at $joe{'s'}
Apostrophes are needed in text. Many languages use them to mark the
absence of some letters. I don't know of any such use of the backtick,
except by people new to computers who use them as if they are
apostrophes :)
I dislike the attempt at getting balanced quotes in ASCII that involves
` and ', but it shouldn't be a problem as that in normal use always
follows whitespace or at least interpunction.
If we're going to entertain alternatives, why not use % as the hash
subscriptor?
To borrow from another thread:
%foo%monday%food = 10;
%foo%monday%travel = 100;
%foo%tuesday%food = 10;
%foo%tuesday%travel = 150;
This has the advantage of ensuring that the hash-marker [1] appears in every
hash reference, and doubles up on the path weight of a single character,
for really good Huffman.
I'm not so much of a user of the modulus operation that I'm unwilling to
exchange it for, e.g. Cmod or C+%.
I don't know about other conflicting uses of %, especially involving special
no-comma-required rules, but I'll bet that if there was one such, a
whitespace rule would disambiguate it.
(E.g., %functions{'print'} %handles{'stderr'}, ...)
I doubt if this would work quite as well in p5, though, since the
presumption of % isn't so high.
=Austin
[1] The hash marker, for allegorical reasons, really should be either '#'
(Unix) or '-' (American Football). I wonder if it's too late to reclaim '#'.
Perhaps % could indicate comments... :-) :-) :-)
Re: backticks
Austin Hastings skribis 2004-04-15 18:09 (-0400): If we're going to entertain alternatives, why not use % as the hash subscriptor? To borrow from another thread: %foo%monday%food = 10; %foo%monday%travel = 100; %foo%tuesday%food = 10; %foo%tuesday%travel = 150; There is as far as I know no technical reason to not do this. But I do dislike fat operators without whitespace. I dislike that as much as I would dislike using whitespace around a subscripting operator. This has the advantage of ensuring that the hash-marker [1] appears in every hash reference, and doubles up on the path weight of a single character, for really good Huffman. %foo is a hash. When I see %foo%bar, it feels like that should be a hash too. Besides that, $foo%bar looks funny and @[EMAIL PROTECTED] does so even more. Not to mention @[EMAIL PROTECTED] I like ` because it's a small but recognisable glyph. (And because of its location on most keyboards.) Juerd
RE: Array/Hash Slices, multidimensional
-Original Message-
From: Abhijit A. Mahabal [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April, 2004 05:13 PM
To: [EMAIL PROTECTED]
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:
%foomonday 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
RE: backticks
-Original Message- From: Matthijs van Duin [mailto:[EMAIL PROTECTED] On Fri, Apr 16, 2004 at 12:14:08AM +0200, Juerd wrote: %foo is a hash. When I see %foo%bar, it feels like that should be a hash too. Besides that, $foo%bar looks funny and @[EMAIL PROTECTED] does so even more. Not to mention @[EMAIL PROTECTED] I like ` because it's a small but recognisable glyph. (And because of its location on most keyboards.) And also because ` is unused in this context, while it's not unimaginable that someone may want the number of elements modulo something. (I dislike unnecessary whitespace-disambiguating rules) That would be C%hash +% 5, or maybe C%hash mod 5, for some value of '5'. The use of % as a modulo operator is purely a legacy from 'C', where it was a failure: in 'C', the only number you care about for modulus is some power of 2, and you get those using bitwise-and anyway. If there is no comma-optional case, then you might even say: $foo % bar $foo % $bar @foo @ 10 % bar (for some reason, I can't like @ as an array dereference. [] does it for me.) (Also, of course, I'm still holding out for @ to be the infix remote-procedure-call operator. Hooray for ACcent!) =Austin
Re: backticks
Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. Juerd
Re: backticks
On Thu, Apr 15, 2004 at 06:38:34PM -0400, Austin Hastings wrote: The use of % as a modulo operator is purely a legacy from 'C', where it was a failure: in 'C', the only number you care about for modulus is some power of 2, and you get those using bitwise-and anyway. I disagree with this completely. I've used % plenty of times in C for circular buffers that were not a powers of 2. % as modulus in C is NOT a failure. If there is no comma-optional case, then you might even say: $foo % bar $foo % $bar @foo @ 10 % bar (for some reason, I can't like @ as an array dereference. [] does it for me.) I'd favor Juerd's proposal over this madness any day :) -Scott -- Jonathan Scott Duff Division of Nearshore Research [EMAIL PROTECTED] Senior Systems Analyst II
RE: backticks
-Original Message- From: Juerd [mailto:[EMAIL PROTECTED] Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. In that case, why not define a Class::Hash-like class that does what you need using autoload? Using p6 you'd get %hash.key instead of p5's $hash-key which is a better single-key access, all things considered. =Austin
Re: Array/Hash Slices, multidimensional
Austin Hastings writes:
-Original Message-
From: Abhijit A. Mahabal [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April, 2004 05:13 PM
To: [EMAIL PROTECTED]
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:
%foomonday 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.
Hmm.. that's all well and good, but...
sub deref (%hash, @keylist) is rw {
if @keylist == 1 {
[EMAIL PROTECTED]
}
else {
deref [EMAIL PROTECTED], @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:
[EMAIL PROTECTED]@expense_categories} =
@error_prone_list_of_unremarked_numbers;
Though I'd love to be reassured or contradicted... hint, hint.
Luke
Re: backticks
Austin Hastings writes: -Original Message- From: Juerd [mailto:[EMAIL PROTECTED] Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. In that case, why not define a Class::Hash-like class that does what you need using autoload? Using p6 you'd get %hash.key instead of p5's $hash-key which is a better single-key access, all things considered. Most likely because either you couldn't use the Hash's methods, or your code would suddenly break should Hash decide to add a method with the same name as one of your keys. Luke
RE: backticks
-Original Message- From: Luke Palmer [mailto:[EMAIL PROTECTED] Austin Hastings writes: From: Juerd [mailto:[EMAIL PROTECTED] Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. In that case, why not define a Class::Hash-like class that does what you need using autoload? Using p6 you'd get %hash.key instead of p5's $hash-key which is a better single-key access, all things considered. Most likely because either you couldn't use the Hash's methods, or your code would suddenly break should Hash decide to add a method with the same name as one of your keys. I'm sure that if Juerd or someone were to write a PublicHash class, they would cleverly reverse the access so that some collision-unlikely path would get the methods. Or use object-indirect :-) =Austin
RE: backticks
-Original Message- From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED] On Thu, Apr 15, 2004 at 06:38:34PM -0400, Austin Hastings wrote: The use of % as a modulo operator is purely a legacy from 'C', where it was a failure: in 'C', the only number you care about for modulus is some power of 2, and you get those using bitwise-and anyway. I disagree with this completely. I've used % plenty of times in C for circular buffers that were not a powers of 2. % as modulus in C is NOT a failure. Of course you used for buffers that were not powers of 2. Had they been powers of 2, you would have used or ~. The fact that you didn't use a power of 2 is pretty questionable. The dread Unix wizards will no doubt have questions for you about this. :-) My point, though, is this: a *lot* of the stuff we take for granted, or did until Larry started shining a light on things like , |, ?:, etc., has crappy Huffman coding. Even something like semicolon as statement terminator isn't what it should be. Instead, it's a nod in the direction of COBOL, where everything was to be an english-like sentence, so ended with period. Sadly, there's exactly one statement terminator per statement, but there's a lot of characters that appear more frequently, like parens and braces. One solution is to eliminate the parens, as with the p6 changes for if and while. A better solution would be to either improve the finger-movement count for those characters, or reuse the purer characters for better purposes. Thus, period as a method delimiter is palatable since it replaces - (dash, shift, dot). The only thing really fighting against pure-Huffman is the preconceived ideas that eurocentric coders have about symbology: +, -, *, and to a lesser extent / mean things. Otherwise, / would be a good candidate for re-use: unshifted, prime real estate, has certain separator-like qualities. If you think about it, what we really ought to do is train ourselves to reverse the numbers row on our keyboards. If we're doing a good job about avoiding magic numbers, then $ % ( ) are going to be much more frequently used than 2 4 5 7 9 0, so why don't we fix them by swapping the shifted for unshifted characters? If there is no comma-optional case, then you might even say: $foo % bar $foo % $bar @foo @ 10 % bar (for some reason, I can't like @ as an array dereference. [] does it for me.) I'd favor Juerd's proposal over this madness any day :) Oh! The slings and arrows of public discussion. I bleed! I die! Aaa aaa aaa rgh. [Aside] Though this be madness, yet there is method in't. ;-) =Austin
Re: backticks
Juerd wrote:
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
We already have two hash dereference syntaxes. That's arguably one too
many as it is. Let's fix the deficiencies in the syntax we have, rather
than adding even more syntax with even more deficiencies.
Oh, you want a specific proposal? Pick one of four:
1. Allow %hashfoo to be typed as %hashfoo. There would be a
conflict with numeric less-than, but we can disambiguate with
whitespace if necessary. After all, we took the same solution with
curlies.
2. Allow barewords in curlies as a special case. We're already allowing
them on the left side of = (I think), which is even more ambiguous.
3. Define hash indexing with a pair to index on the key. This would
allow the syntax %hash{:foo}. (This could even be achieved by making
C~$pair eq $pair.key.)
4. Define a bareword-quoting prefix operator (i.e. one that turns the
next \w+ into a string) and use the normal hash indexer, {}. I have
no suggestion for this operator's name, although if you wanted to rip
out the current unary backticks, it could be a candidate:
%hash{`key}.
In the last three proposals, I would remove the indexer. I feel
that indexing with a slice of \w keys is not a common enough operation
to warrant the extra indexer, even with the parallel to the list
constructor. However, it's worth noting that #3 gives you a fairly
convenient construct to do just that (%hash{:foo :bar}), and #4 could
probably be defined to do the same.
(For the record, I have nothing against the list constructor. That
was a stroke of genius. I just don't like having a separate indexer
based on it.)
As for removing the term ``, I see no compelling argument to do so.
Perl has never been, and should never be, the sort of nanny language
that makes fundamental operations less accessible just because they're
security risks. Heck, we gave our users the 'x' operator, arguably the
easiest way in any language to fill up memory quickly.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: backticks
Austin Hastings writes: If you think about it, what we really ought to do is train ourselves to reverse the numbers row on our keyboards. If we're doing a good job about avoiding magic numbers, then $ % ( ) are going to be much more frequently used than 2 4 5 7 9 0, so why don't we fix them by swapping the shifted for unshifted characters? Hehe, one step ahead of you. It's quite simple to train vim to do such a thing, and I noticed myself using the numpad for numbers anyway, so I made all the number keys act like shift is being pressed. I can see that it's a step up in efficiency 9although I'm still getting used to it81 :-0 Luke
