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 C, 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
On Wed, Apr 14, 2004 at 10:06:23PM +0200, Juerd wrote:
>
> 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
Re: Compatibility with perl 5
Brent --
I think I missed your point. I'll refer to your two code chunks as
(a) and (b). Maybe you are getting at a finer point, though...
What you've said in (a) is pretty much what I hinted about Inline::Perl6
in my message. If you pass it to a Perl 6 interpreter, then it will
probably use that hint to shift into Perl 5 mode (which, fortunately,
is a perfectly respectable thing for a Perl 6 interpreter to do) kind
of as if what you had sent it was really:
#!/usr/bin/perl6
use syntax 'perl5';
...
Any Perl 5 code above your 'use 5' statement that isn't also legal
Perl 6 code, though, would cause the compiler to complain.
I don't see how what you've said in (b) is different from what I've
said, outside the "use 6" which I think shouldn't exist, since
it means nothing to Perl 5 (there is no Perl 5, version 6) and
means nothing to Perl 6 (which has as its lowest version number...
6). So, the code you wrote is Perl 6 with a redundant "use 6"
in it, otherwise in the same vein as what I wrote. If you pass it
to a Perl 5 interpreter, it will choke. If you pass it to a Perl 6
interpreter, life is peachy keen. If you pass it to a Python
interpreter, you get what you deserve :) You have used "use syntax"
which falls under the category of "# or whatever" in my message.
Regards,
-- Gregor
On Wed, 2004-04-14 at 18:51, Brent 'Dax' Royal-Gordon wrote:
> Gregor N. Purdy wrote:
>
> > #!/usr/bin/perl6
> >
> > ... # Perl 6 stuff here
> >
> > use 5; # or, whatever
> >
> > # Perl 5 stuff here
> >
> > no 5; # or, whatever
> >
> > # More Perl 6 stuff here
> >
> > use python; # you get the idea
>
> Why conflate the two at all? Perl 5 has two separate syntaxes for
> forcing a version and embedding code in a different language:
>
> use 5;# forces Perl < 6
> perl_five_code();
> use Inline::Perl6 q{ # Ah, the wonders of ponie...
> perl_six_code();
> };
> use Inline::Python q{
> python_code()
> };
>
> So why not do the same (albeit in a much slicker way) for Perl 6?
>
> use 6;# forces Perl 6+
> perl_six_code();
>
> {
> use syntax 'perl5'; # switches to Perl 5 syntax
> perl_five_code();
> }
>
> {
> use syntax 'python';
> python_code()
> }#With the indentation, I think this closes both the Perl and
> # the Python block...
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: backticks
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Wed, Apr 14, 2004 at 10:31:23PM -0400, Joe Gottman wrote: > >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():) 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.
Re: backticks
On Wed, Apr 14, 2004 at 10:31:23PM -0400, Joe Gottman wrote:
> > [EMAIL PROTECTED] (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():)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: backticks
- Original Message -
From: "Simon Cozens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 14, 2004 5:04 PM
Subject: Re: backticks
> [EMAIL PROTECTED] (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
Re: Compatibility with perl 5
Gregor N. Purdy wrote:
#!/usr/bin/perl6
... # Perl 6 stuff here
use 5; # or, whatever
# Perl 5 stuff here
no 5; # or, whatever
# More Perl 6 stuff here
use python; # you get the idea
Why conflate the two at all? Perl 5 has two separate syntaxes for
forcing a version and embedding code in a different language:
use 5;# forces Perl < 6
perl_five_code();
use Inline::Perl6 q{ # Ah, the wonders of ponie...
perl_six_code();
};
use Inline::Python q{
python_code()
};
So why not do the same (albeit in a much slicker way) for Perl 6?
use 6;# forces Perl 6+
perl_six_code();
{
use syntax 'perl5'; # switches to Perl 5 syntax
perl_five_code();
}
{
use syntax 'python';
python_code()
}#With the indentation, I think this closes both the Perl and
# the Python block...
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Compatibility with perl 5
Brent --
Clever points are relatively high here, but I find the idea of
doing the notionally simultaneous parse uncomfortable. I really
don't want my programs subject to a hidden double parse cost.
Regards,
-- Gregor
On Wed, 2004-04-14 at 15:30, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman wrote:
> > On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> >
> >>So, we are moving in a more verbose direction, which is a bummer for
> >>people who like to write one-liners and other tiny programs.
> >
> >
> > perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
> > s:g/\b\.\.\.\b/IP ADDR/;' *
> >
> > No biggie.
>
> Curlies aren't used for that anymore. I'd also suggest using an
> assertion for a much shorter C rule:
>
> perl6 -i.bak -ple 'rule octet {(\d<1,3>)<($1<256)>}
> s:g/\b\.\.\.\b/IP ADDR/' *
>
> TMTOWTDI, though, and I'm being rather nitpicky.
>
> Personally, I would implement Perl 5 vs. Perl 6 switching as:
>
> 1. If argv[0] includes either '5' or '6', use the appropriate version.
> 2. Parse the program as *both* Perl 5 and Perl 6.
> 3. Figure out which parses succeeded:
> a. If Perl 5 succeeded...
>i. If Perl 6 succeeded, emit an ambiguity warning. (I think this
> warning should be on by default, but that's open to
> negotiation.)
> ii. Execute the Perl 6 parse.
> b. Else if Perl 6 succeeded, execute the Perl 6 parse.
> c. Else...
>i. If exactly one of the parses died on an error that
> disambiguates between the Perls (e.g. a package statement, a
> 'use 6'), emit the other's error message.
> ii. Otherwise, emit an ambiguity warning and both error messages.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
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)
--
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. Similarly, starting a script with "#!/usr/bin/perl5"
should force the interpreter to treat it like Perl 5, and if it does
anything else that's just ugly, too. The only opportunity for
ambiguity is if the script starts with "#!/usr/bin/perl" or no shebang
line.
In that case, maximal backward compatibility dictates that the
interpreter expect Perl 5, although 20 years from now we may wish
Perl 6 was assumed (and maybe by Perl 7 we will assume Perl 6 unless
told otherwise... :)
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".
If it turns out that the /usr/bin/perl program is actually just a link
to the same executable as /usr/bin/perl6 but operating with a different
personality, I'm fine with that. Heck, I'd be fine with /usr/bin/python
being a symlink to the same executable, too, and I'd expect it to behave
like a Python interpreter.
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;
Since there is no version 6 of the Perl (5) language. Inline::Perl6
aside, there ain't no Perl 6 in the Perl 5 world, even though there are
a few Perl6:: isms.
Now, I do think it would be perfectly fine for a program to start off
as a Perl 6 program and have an embedded chunk that is interpreted as
Perl 5, since that is a feature of Perl 6.
#!/usr/bin/perl6
... # Perl 6 stuff here
use 5; # or, whatever
# Perl 5 stuff here
no 5; # or, whatever
# More Perl 6 stuff here
use python; # you get the idea
...
Regards,
-- Gregor
On Wed, 2004-04-14 at 12:59, Aaron Sherman wrote:
> On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> > So, we are moving in a more verbose direction, which is a bummer for
> > people who like to write one-liners and other tiny programs.
>
> perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
> s:g/\b\.\.\.\b/IP ADDR/;' *
>
> No biggie.
>
> > Assuming only Perl 6 is installed on your system, if your script
> > started with:
> >
> > #!/usr/bin/perl
> >
> > all the stuff about trying to figure out what version you are using
> > would have to apply I suppose. But, if you used this, are we saying
> > you still have to do something else to ensure its treated as Perl 6?
>
> Yes, because Perl 6 *is* Perl 5, when it wants to be.
>
> > #!/usr/bin/perl6
> >
> > And, if you did this, you might have to do something else to ensure
> > it is treated as Perl 5?
>
> Correct. If you *say* "perl6" and then want to *be* Perl 5, I'm not sure
> if a) you could not or b) you would have to throw in something like "use
> 5".
>
> > #!/usr/bin/perl5
> >
> > that seems wrong.
>
> Not sure why. That is just short-hand for:
>
> #!/usr/bin/perl
> use 5;
>
> I'm not sure, once again, what would happen if you said:
>
> use 5;
> use 6;
>
> Either it would give you an error (you really deserve it) or it would
> just switch back to Perl 6 mode... the problem arises when you ask,
> "what about anything that got parsed in between the two?" Yech.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
RE: backticks
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.
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
Re: backticks
Scott Walters writes:
> 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 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
Re: Compatibility with perl 5
Aaron Sherman wrote:
On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
So, we are moving in a more verbose direction, which is a bummer for
people who like to write one-liners and other tiny programs.
perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]} s:g/\b\.\.\.\b/IP ADDR/;' *
No biggie.
Curlies aren't used for that anymore. I'd also suggest using an
assertion for a much shorter C rule:
perl6 -i.bak -ple 'rule octet {(\d<1,3>)<($1<256)>}
s:g/\b\.\.\.\b/IP ADDR/' *
TMTOWTDI, though, and I'm being rather nitpicky.
Personally, I would implement Perl 5 vs. Perl 6 switching as:
1. If argv[0] includes either '5' or '6', use the appropriate version.
2. Parse the program as *both* Perl 5 and Perl 6.
3. Figure out which parses succeeded:
a. If Perl 5 succeeded...
i. If Perl 6 succeeded, emit an ambiguity warning. (I think this
warning should be on by default, but that's open to
negotiation.)
ii. Execute the Perl 6 parse.
b. Else if Perl 6 succeeded, execute the Perl 6 parse.
c. Else...
i. If exactly one of the parses died on an error that
disambiguates between the Perls (e.g. a package statement, a
'use 6'), emit the other's error message.
ii. Otherwise, emit an ambiguity warning and both error messages.
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: backticks
I propose we pretend that $$foo = 'bar' stills work and use that as a benchmark
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<> = 'baz!'
On a related note, has anyone seen my semicolon key? It was last spotted in
central park around 5am...
-scott
On 0, Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] (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.
>
> --
> "Though a program be but three lines long,
> someday it will have to be maintained."
> -- The Tao of Programming
Re: backticks
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?
%hash ~ `rf -rm *`
%hash`rf`rm
Failing that, back to whitespace dependencies?
%hash{'aliens!!'}
for keys %hash {
.ate_my_buick
}
-scott
On 0, Juerd <[EMAIL PROTECTED]> wrote:
>
> Randal L. Schwartz skribis 2004-04-14 13:56 (-0700):
> > > "Juerd" == Juerd <[EMAIL PROTECTED]> writes:
> > Juerd> readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses
> > Juerd> can be found. Most are in Debian's modules.
> > That's because they aren't particularly interesting in modules, but
> > in 10 line scripts, they show up quite frequently.
> > This undermines the rest of your request.
>
> How unfortunate that you didn't notice that I made two separate
> requests, that both have to do with backticks.
>
> Request one: Remove `` and/or qx, because its interpolation is dangerous
> and solutions like it should be discouraged.
>
> Request two: Add %hash`key
>
> %hash`key can exist without `` gone. `` can be removed without ` meaning
> something else. It would, however, for understandability, be nicer if
> both requests were granted.
>
> Please, re-read my post and comment on the second request as
> insightfully as you did on the first.
>
>
> Juerd
Re: backticks
> hash slices aren't used much at all. People *always* overgeneralize.
Re: backticks
On Wed, Apr 14, 2004 at 01:36:21PM -0600, John Williams wrote:
%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.
--
Matthijs van Duin -- May the Forth be with you!
Re: backticks
[EMAIL PROTECTED] (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.
--
"Though a program be but three lines long,
someday it will have to be maintained."
-- The Tao of Programming
Re: backticks
Randal L. Schwartz skribis 2004-04-14 13:56 (-0700): > > "Juerd" == Juerd <[EMAIL PROTECTED]> writes: > Juerd> readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses > Juerd> can be found. Most are in Debian's modules. > That's because they aren't particularly interesting in modules, but > in 10 line scripts, they show up quite frequently. > This undermines the rest of your request. How unfortunate that you didn't notice that I made two separate requests, that both have to do with backticks. Request one: Remove `` and/or qx, because its interpolation is dangerous and solutions like it should be discouraged. Request two: Add %hash`key %hash`key can exist without `` gone. `` can be removed without ` meaning something else. It would, however, for understandability, be nicer if both requests were granted. Please, re-read my post and comment on the second request as insightfully as you did on the first. Juerd
Re: backticks
On Wed, Apr 14, 2004 at 01:56:35PM -0700, Randal L. Schwartz wrote: That's because they aren't particularly interesting in modules, but in 10 line scripts, they show up quite frequently. This undermines the rest of your request. No, actually, it doesn't. Juerd doesn't seem to like ``, but that point is entirely orthogonal to the introduction of the ` dereferencing operator. The two uses don't conflict. (which is why I was able to make a patch that adds the `-operator to perl 5.8.3) -- Matthijs van Duin -- May the Forth be with you!
Re: backticks
> "Juerd" == Juerd <[EMAIL PROTECTED]> writes: Juerd> readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses Juerd> can be found. Most are in Debian's modules. That's because they aren't particularly interesting in modules, but in 10 line scripts, they show up quite frequently. This undermines the rest of your request. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: backticks
Matthew Walton skribis 2004-04-14 21:23 (+0100):
> >%foo<<$bar>> doesn't quite do the same as %foo{$bar}.
> That's one method, really - <<>> being like {' '}, and really just
> carrying on the very familiar idea of different kinds of quotes. Like '
> and ".
The <<>> thing works as if there is an implicit {} around it: <<>> is
an alias for qw.
<<>> doesn't interpolate. Its insides are string literals separated by
whitespace.
"«foo»" is 13 key presses, "<>" is 9 key presses, "{'foo'}" is also
9, "`foo" is only 4.
(using vim's ^K and counting keys, not characters. That means shift and
ctrl DO count)
> The ` idea is completely different.
Fortunately so.
> Also, ditching `` quotes strikes me as a fairly dreadful idea.
Because you're used to them. You're also used to many other things that
change when you go from Perl 5 to Perl 6.
If you dislike when symbols get to mean different things, reading about
Perl 6 must be a terrible experience for you.
> Yes, I could use qx// instead, but I could also use qq// instead of
> "".
If it were up to me, qx would also be removed from the language and only
readpipe would be left.
> Ultimately, ` looks like an opening quote character, and so people will
> expect it to behave like one. I think that violates the principle of
> least surprise.
Least surprise is important for constructs that aren't used
continuously. Whatever is used throughout people's source code,
*defines* what people expect and is therefore after seeing it for the
first time no longer a surprise.
Some people say {} looks like a code block, and that so people will
expect it to behave like one. However, Perl 6 also uses it for hash
reference constructing, hash subscripting, alternative delimiters, rule
blocks, and perhaps even other things.
Perl 5 and PHP coders will expect . to be concatenating, -> to be
for calling methods. What people expect because they are used to other
programming languages does not matter at all. The language should be
a consistent universe within itself. If THAT it is not, you are
violating the principle of least surprise.
Believe me, any non-Perl-6 coder will be surprised when seeing Perl 6 in
action. And that is a good thing.
Juerd
Re: backticks
On Wed, 2004-04-14 at 08:18, Juerd wrote:
> Perl 5 has the qx// operator which does readpipe. I believe the function
> for it was added later. (It doesn't handle a LIST as system does,
> unfortunately.) qx// is also known as ``. Two backticks.
>
> readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses
> can be found. Most are in Debian's modules.
>
> Why should readpipe get to cheat on the huffman thing?
>From a source tree I work with (which I cannot divulge code from, but I
think statistics like this are fine):
$ find . -name \*.pl | wc -l
330
$ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
123
`` gets used an awful lot, just usually not in modules where the process
control issues surrounding even system() tend to yield a module unusable
for the general case, even though it might be fine in a more specific
one.
I could take or leave `` because I don't like unbalanced quote
operators, and I see qx{} as just as good if not better, but to remove
it on the basis of the lack of use is faulty.
I would have preferred that Perl 6 used the bash/zsh-style:
$(...)
But we have other designs on that.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: backticks
Scott Walters skribis 2004-04-14 13:12 (-0700):
> Second, autovivication is impossible for the same reason. We can't tell
> from parsing this lone expression whether baz should be converted to numbers
> or strings automatically.
I want ` for hashes in the first place. Having it for arrays too would
be nice, but it isn't as important to me. Having seen some international
keyboard layouts, I think others may find not having to type [] very
useful.
Autovivification of elements is not a problem for pure hashes and
arrays. Autovivification of references (as in "my $ref; $ref`aoeu") and
elements of hybrid arrayhashes (like $0) is also not a problem if you
use the ^-?\d+$ rule to decide. Again: if you need to be explicit, you
still can.
So I'm not sure where it is a problem. Even if deciding based on the
value isn't good and for autovivification you default to hashes, the `
would still be a welcome addition.
> If you can't remember what a data structure looks like, it doesn't matter if
> the code spells out the sequences of hash-array-hash each time - you're
> going to spell it out wrong. People new to Perl and new to data structures
> have this problem all the time - they can't keep straight what the data structure
> *is*.
That, and not many hashes have \d+ keys. When they do, you can just use
{} to make sure things are interpreted the way you want them to be.
> actually go one further and coopt the . operator and emulate JavaScript more
> closely, but I admit the visual distinction between method calls and subscripts
> might warrent the noise.
It's not just the visual distinction, but also to let the parser know.
If I understand correctly, hashes and arrays will have many methods of their
own. I don't want %hash.keys to be interpreted as
%hash{'keys'} and I do want to be able to use the easier syntax when my
hash does in fact have a key 'keys'.
Juerd
Re: backticks
Juerd wrote:
chromatic skribis 2004-04-14 12:32 (-0700):
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
Absolutely false.
This is an addition to the already existing {}, which should stay.
%foo{ something } will still be necessary if:
* the key is the result of an expression
* you want a slice
* the key is not a string
* the key is a string that isn't simple enough (i.e. contains \W in a
way that isn't supported)
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
There are already two. One that works with expressions and one that
works for one or many hash keys as long as they are literals.
%foo<<$bar>> doesn't quite do the same as %foo{$bar}.
That's one method, really - <<>> being like {' '}, and really just
carrying on the very familiar idea of different kinds of quotes. Like '
and ".
The ` idea is completely different.
Also, ditching `` quotes strikes me as a fairly dreadful idea. I for one
use them almost perpetually. Yes, I could use qx// instead, but I could
also use qq// instead of "".
Ultimately, ` looks like an opening quote character, and so people will
expect it to behave like one. I think that violates the principle of
least surprise.
Re: backticks
When I announced that I fixed a version of Perl6::Variables to do <<>>,
crickets chirped. I dislike having to place a lot of matching quotes,
brackets, parenthesis, and braces in my code. You must stop and
visually inspect code to make sure it balances out and even then is a
common source of bug causing typos.
I've been working in Pike's predecessor, LPC, lately. Arrays and hashes
are both subscripted with []
foo["bar"][10][baz]
Variables are autoconverted to the correct type. This has two drawbacks.
Visually inspecting the dreference sequence, you can't tell whether this
is an hash of arrays of hashes or a hash of arrays of arrays. If { }
were used to deference hashes, you'd be able to tell.
Second, autovivication is impossible for the same reason. We can't tell
from parsing this lone expression whether baz should be converted to numbers
or strings automatically.
Enough science, time for anecdotes!
If you can't remember what a data structure looks like, it doesn't matter if
the code spells out the sequences of hash-array-hash each time - you're
going to spell it out wrong. People new to Perl and new to data structures
have this problem all the time - they can't keep straight what the data structure
*is*.
I adjusted to the lack of autovivication very quickly and easily. I'd sacrifice
autovivication *much* sooner than I'd sacrifice a concise subscript syntax.
Data structures are really only ever initialized in a few places in code
except in pathologically badly written code. This adjustment was akin to the
"use warnings"'s handling of undef reguarding "Use of unitialized value".
Hardcoding things around is normally considered bad, and in LPC at least once
in the past month, I've switched an array to being a hash. I was able to do
so without rewritting all of the code that accesses the data structure -
it automatically began accept strings as well as numbers for keys in the
subscript. Hence, using { } vs [ ] might be providing too much redundancy.
And since when have we forced people to be explicit in Perl?
In LPC and apparently Pike, it is all or nothing. Perl can have it's cake and
eat it too. If you want autovivication and information about your datastructures
hardcoded around, use {}, [], and <<>>. If you want concise code, use `. I'd
actually go one further and coopt the . operator and emulate JavaScript more
closely, but I admit the visual distinction between method calls and subscripts
might warrent the noise.
Re: the re-adjustment, after 5 years of heavy Perl programming, LPC's relatively
simple syntax is extremely soothing. The only thing I'm really missing is
list flattening, implicit or explicit, frequently doing things like
bar(xyz["foo"][0], xyz["foo"][1], xyz["foo"][2]).
Let me summarize. The gripes about "you can't do that with `!" miss the point.
Two ways to subscript is not too many. The simplicity available from it is far
from the terse line noise associated with Perl but is something worthy of
languages billed as clean and readable (Pike, not JavaScript). There are
distinct advantages besides concise to this syntax that make it desireable.
So, I strongly support ` or something equivilent.
-scott
On 0, Juerd <[EMAIL PROTECTED]> wrote:
>
> chromatic skribis 2004-04-14 12:32 (-0700):
> > That's exactly my objection to this idea. I think it goes too far to
> > make simple things simpler while making complex things impossible.
>
> Absolutely false.
>
> This is an addition to the already existing {}, which should stay.
> %foo{ something } will still be necessary if:
>
> * the key is the result of an expression
> * you want a slice
> * the key is not a string
> * the key is a string that isn't simple enough (i.e. contains \W in a
> way that isn't supported)
>
> > I really don't want to explain why there are two hash key access
> > mechanisms, one that only works for single keys that match a very
> > simplified regular expression and one that works for one or many hash
> > keys with no restrictions.
>
> There are already two. One that works with expressions and one that
> works for one or many hash keys as long as they are literals.
>
> %foo<<$bar>> doesn't quite do the same as %foo{$bar}.
>
> > Simplicity is good, yes. Huffman coding is also good. But you have to
> > balance them with consistency of expression, usage, and semantics.
>
> I agree.
>
> > I don't think this proposal does the latter.
>
> I disagree.
>
> > On the other hand, if you prod Luke Palmer, he can probably write a
> > macro to make this syntax work for you in under ten minutes and three
> > messages. In that case, it may not be a core feature, but you can have
> > it for very nearly free.
>
> Or I could use something that modifies the grammar Perl uses. Almost any
> syntax feature can be added outside the core. I'm not exploring the
> possibility of this operator, but suggesting that it be in the core.
>
> This operator is possible, improves readability, eases typing and does
> not clas
Re: backticks
John Williams skribis 2004-04-14 13:36 (-0600):
> On Wed, 14 Apr 2004, Juerd wrote:
> > I propose to use ` as a simple hash subscriptor, as an alternative to {}
> > and <<>>. It would only be useable for \w+ keys or perhaps -?\w+.
> > As with methods, a simple "atomic" (term exists only in perlreftut,
> > afaix, but I don't know another word to describe a simple scalar
> > variable) scalar should be usable too.
> > %hash`$key
>
> oops, you contradicted yourself here. "only be useable for \w+ keys"
Oops, part of my message wasn't read as it was intended. $key is a
simple "atomic" scalar and "should be usable too".
Just like how $object.$method works, %hash`$key should too.
> > $0`15 # $0[15]
> > $0`alpha # $0{'alpha'}
> You are repeating the errors of javascript. $0[15] != $0{15}
"After all, [] and {} are still available if you need to be explicit."
Javascript's "error" (design) is that it has only [] and no {}.
> I think I would prefer something more intuitive, like :baz=quux
That reads to me as assigning the result of quux() to a pair that has
the value 1. To avoid that it reads like an assignment, => could be
used:
:bar=>quux
But ehm, then there's not much point anymore, as
bar => 'quux'
already does the same and is much easier to read.
> Any [^\w\s] character could be used there unambiguously, and = has the
> already existing parallel with command-line args, but ` is just an unused
> character.
Command line arguments (assuming a specific kind of parsing) also
use -- instead of : and have
> > and ` is in an extremely easy to type place.
> ... on a us/english keyboard ...
On a US keyboard (qwerty/dvorak), it's in the upper left corner. Very
convenient indeed.
On German and Danish keyboards, it is the key left of backspace,
shifted. This sounds terrible, but not quite as terrible as Alt Gr plus
7 and 0 respectively.
German/Danish keyboard has:
/ ( ) = ? `<-- Shift
7 8 9 0 sz '<-- no modifier
{ [ ] } prc \<-- Alt Gr
On Dutch keyboards (that aren't used much, but do exist), it is two keys
left of Enter. It also requires the awkward Alt Gr for { and }, but in
better positions:
- ( ) '<-- Shift
7 8 9 0<-- no modifier
pnd { }<-- Alt Gr
H J K L plm `<-- Shift
h j k l + '<-- no modifier
With whatever keyboard Matthijs uses, the ` is right of the left Shift.
So that's already 6 keyboard layouts in which ` is much easier than {}.
It appears French keyboards have { as Alt Gr + 4 and } all the way over
on the right side, as Alt Gr + =. It has ` as Alt Gr + 7. But this
layout looks terrible for any typing, natural AND programming languages.
http://www.datacal.com/dce/catalog/french-layout.htm
If on your keyboard ` is in a worse place than {}, I'd like to know
where it is.
Juerd
Re: Compatibility with perl 5
On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> So, we are moving in a more verbose direction, which is a bummer for
> people who like to write one-liners and other tiny programs.
perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
s:g/\b\.\.\.\b/IP ADDR/;' *
No biggie.
> Assuming only Perl 6 is installed on your system, if your script
> started with:
>
> #!/usr/bin/perl
>
> all the stuff about trying to figure out what version you are using
> would have to apply I suppose. But, if you used this, are we saying
> you still have to do something else to ensure its treated as Perl 6?
Yes, because Perl 6 *is* Perl 5, when it wants to be.
> #!/usr/bin/perl6
>
> And, if you did this, you might have to do something else to ensure
> it is treated as Perl 5?
Correct. If you *say* "perl6" and then want to *be* Perl 5, I'm not sure
if a) you could not or b) you would have to throw in something like "use
5".
> #!/usr/bin/perl5
>
> that seems wrong.
Not sure why. That is just short-hand for:
#!/usr/bin/perl
use 5;
I'm not sure, once again, what would happen if you said:
use 5;
use 6;
Either it would give you an error (you really deserve it) or it would
just switch back to Perl 6 mode... the problem arises when you ask,
"what about anything that got parsed in between the two?" Yech.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: backticks
chromatic skribis 2004-04-14 12:32 (-0700):
> That's exactly my objection to this idea. I think it goes too far to
> make simple things simpler while making complex things impossible.
Absolutely false.
This is an addition to the already existing {}, which should stay.
%foo{ something } will still be necessary if:
* the key is the result of an expression
* you want a slice
* the key is not a string
* the key is a string that isn't simple enough (i.e. contains \W in a
way that isn't supported)
> I really don't want to explain why there are two hash key access
> mechanisms, one that only works for single keys that match a very
> simplified regular expression and one that works for one or many hash
> keys with no restrictions.
There are already two. One that works with expressions and one that
works for one or many hash keys as long as they are literals.
%foo<<$bar>> doesn't quite do the same as %foo{$bar}.
> Simplicity is good, yes. Huffman coding is also good. But you have to
> balance them with consistency of expression, usage, and semantics.
I agree.
> I don't think this proposal does the latter.
I disagree.
> On the other hand, if you prod Luke Palmer, he can probably write a
> macro to make this syntax work for you in under ten minutes and three
> messages. In that case, it may not be a core feature, but you can have
> it for very nearly free.
Or I could use something that modifies the grammar Perl uses. Almost any
syntax feature can be added outside the core. I'm not exploring the
possibility of this operator, but suggesting that it be in the core.
This operator is possible, improves readability, eases typing and does
not clash with something that already exists.
Yes, it does mean learning the meaning of one more character. I think
every programmer is able to cope with that. Even beginners.
Juerd
Re: backticks
On Wed, 14 Apr 2004, Juerd wrote:
> I propose to use ` as a simple hash subscriptor, as an alternative to {}
> and <<>>. It would only be useable for \w+ keys or perhaps -?\w+. As
> with methods, a simple "atomic" (term exists only in perlreftut, afaix,
> but I don't know another word to describe a simple scalar variable)
> scalar should be usable too.
>
> can then also be written as:
>
> %hash`key
ugly.
> $hashref`foo`bar`baz`quux
ugly ugly ugly
> %hash`$key
oops, you contradicted yourself here. "only be useable for \w+ keys"
> With some imagination, this can also be used for arrays. That would need
> to allow the key to have /^-/ and it poses a problem with hybrids like
> $0. Normally []/{} decides whether it's a hash or array dereference, but
> for this easy-to-write thing a /^-?\d+$/ should be doable. After all, []
> and {} are still available if you need to be explicit.
>
> $0`15 # $0[15]
> $0`alpha # $0{'alpha'}
You are repeating the errors of javascript. $0[15] != $0{15}
> :key`value
> use Some::Module :foo :bar :baz`quux :xyzzy;
I think I would prefer something more intuitive, like :baz=quux
Any [^\w\s] character could be used there unambiguously, and = has the
already existing parallel with command-line args, but ` is just an unused
character.
> and ` is in an extremely easy to type place.
... on a us/english keyboard ...
> I think %hash`key makes sense. But I'd like to find out if more people
> like this idea.
one emphatic negative vote here.
Re: backticks
On Wed, 2004-04-14 at 12:24, Juerd wrote:
> chromatic skribis 2004-04-14 12:07 (-0700):
> > > I think %hash`key makes sense. But I'd like to find out if more people
> > > like this idea.
> > How do you request a hash slice with backticks?
> You don't. There are %foo<> and %foo{'foo', 'bar'} already and
> hash slices aren't used much at all.
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
Simplicity is good, yes. Huffman coding is also good. But you have to
balance them with consistency of expression, usage, and semantics. I
don't think this proposal does the latter.
On the other hand, if you prod Luke Palmer, he can probably write a
macro to make this syntax work for you in under ten minutes and three
messages. In that case, it may not be a core feature, but you can have
it for very nearly free.
-- c
Re: backticks
Jonathan Scott Duff skribis 2004-04-14 14:21 (-0500):
> 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<>.
%foo{key} is %foo{ key() } in Perl 6's current design.
Juerd
Re: backticks
chromatic skribis 2004-04-14 12:07 (-0700):
> > I think %hash`key makes sense. But I'd like to find out if more people
> > like this idea.
> How do you request a hash slice with backticks?
You don't. There are %foo<> and %foo{'foo', 'bar'} already and
hash slices aren't used much at all.
The proposed ` is very much like the . that is used for calling methods.
Except for the possible leading minus, it can probably be parsed exactly
the same (i.e. allowing :: too, as Matthijs' implementation also
does).
It is also much like the way single elements work in Perl 5, except that
you can't use an expression. (i.e. where $hash{+shift} uses the shift
operator, %hash`shift would get value of the pair that has the key
'shift' and %hash`+shift would be a syntax error -- there is already
%hash{shift} for that and this too isn't used as often as literal string
keys.
Main purposes of ` are typability and readability. Anything that allows
more complex operations would require less readable syntax if used with
the backtick. Only simple literal strings (valid identifiers, but being
able to start with a digit or minus) and simple scalar variables (the
thing perlreftut calls "atomic") like $foo can be used.
Juerd
Re: backticks
On Wed, Apr 14, 2004 at 12:07:18PM -0700, chromatic wrote:
> On Wed, 2004-04-14 at 05:18, Juerd wrote:
>
> > I think %hash`key makes sense. But I'd like to find out if more people
> > like this idea.
>
> How do you request a hash slice with backticks?
I think you wouldn't. For that the more verbose syntax is required and I
think even desired. %foo`key is just a shorthand for the very common
%foo{key}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: backticks
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? -- c
Re: backticks
On Wed, Apr 14, 2004 at 02:18:48PM +0200, Juerd wrote:
I propose to use ` as a simple hash subscriptor, as an alternative to {}
and <<>>. It would only be useable for \w+ keys or perhaps -?\w+. As
with methods, a simple "atomic" (term exists only in perlreftut, afaix,
but I don't know another word to describe a simple scalar variable)
scalar should be usable too.
%hash`key
$hashref`foo`bar`baz`quux
%hash`$key
$object.method`key
I absolutely love it. Since hashes are used so much, I think it deserves
this short syntax. Note btw that it's not even mutually exclusive with qx's
use of backticks. To illustrate that, see:
http://www.math.leidenuniv.nl/~xmath/perl/5.8.3-patches/tick-deref.patch
It's a quick patch I made that adds the `-operator to perl 5.8.3, so you
can try it how it "feels".
With some imagination, this can also be used for arrays.
I like that too. (though not (yet) implemented in my patch)
--
Matthijs van Duin -- May the Forth be with you!
backticks
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?
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<> 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
Re: Compatibility with perl 5
So, we are moving in a more verbose direction, which is a bummer for people who like to write one-liners and other tiny programs. Assuming only Perl 6 is installed on your system, if your script started with: #!/usr/bin/perl all the stuff about trying to figure out what version you are using would have to apply I suppose. But, if you used this, are we saying you still have to do something else to ensure its treated as Perl 6? #!/usr/bin/perl6 And, if you did this, you might have to do something else to ensure it is treated as Perl 5? #!/usr/bin/perl5 that seems wrong. Regards, -- Gregor On Tue, 2004-04-13 at 08:12, Luke Palmer wrote: > David Cantrell writes: > > A few days ago I briefly discussed with Nicholas Clark (current perl 5.8 > > pumpking) about making perl5 code forward-compatible with perl6. A > > quick look through the mailing list archives didn't turn up anything > > obvious, and I don't recall any mechanism being presented in any of the > > Apocalypses, so ... > > Well, there is one, as far as I understand it. Your "use perl5;" is > spelled "package". That is, perl will assume Perl 6 unless it sees > "package SomethingOrOther;" (since Perl 6 calls them "module"s). So, to > force Perl 5 interpretation, use: > > package main; > > Luke -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
