[24934] in Perl-Users-Digest
Perl-Users Digest, Issue: 7184 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 27 21:06:46 2004
Date: Mon, 27 Sep 2004 18:05:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 27 Sep 2004 Volume: 10 Number: 7184
Today's topics:
Re: (was: decode the form information) <dontmesswithme@got.it>
Re: accessing perl's internal hashing algorithm ctcgag@hotmail.com
Re: best way to search perldocs (Malcolm Dew-Jones)
Re: best way to search perldocs <matternc@comcast.net>
Re: best way to search perldocs <tadmc@augustmail.com>
Re: Continous Looping of a List <cpryce@nospam.pryce.net>
gtk2 / glade problem. <news4@earthsong.null.free-online.co.uk>
Hash as an function argument <lepi_MAKNI_ME_@fly.srk.fer.hr>
Re: Hash as an function argument <noreply@gunnar.cc>
Re: Hash as an function argument <usa1@llenroc.ude.invalid>
Re: Hash as an function argument <tadmc@augustmail.com>
Re: Parsing Email (Malcolm Dew-Jones)
Re: Parsing Email <tadmc@augustmail.com>
Re: Precedence of exponentiation <abigail@abigail.nl>
Re: Precedence of exponentiation <abigail@abigail.nl>
Re: Precedence of exponentiation <nemo@weathersong.net>
Re: Precedence of exponentiation <abigail@abigail.nl>
Re: Precedence of exponentiation <nemo@weathersong.net>
unicode: equal strings give different results? <pilsl@goldfisch.at>
Re: unicode: equal strings give different results? <flavell@ph.gla.ac.uk>
Re: unicode: equal strings give different results? <shawn.corey@sympatico.ca>
Using "system" command - is it "bad practice" for perl? (John Davis)
Re: Using "system" command - is it "bad practice" for p <noreply@gunnar.cc>
Re: Using "system" command - is it "bad practice" for p <jurgenex@hotmail.com>
Re: Using "system" command - is it "bad practice" for p <abigail@abigail.nl>
Re: Using "system" command - is it "bad practice" for p <shawn.corey@sympatico.ca>
Re: Using C::Scan : How to ignore #includes ? <gifford@umich.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 27 Sep 2004 20:27:28 GMT
From: Larry <dontmesswithme@got.it>
Subject: Re: (was: decode the form information)
Message-Id: <dontmesswithme-CA6896.22241027092004@twister1.tin.it>
In article <2rqskvF1ckhvvU1@uni-berlin.de>,
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>
> As a general purpose function for parsing CGI form data? No.
>
> The very fact that you feel a need to ask shows that you don't know
> enough about CGI to write such a function. It's good that you want to
> learn, but asking open CGI questions in this group is the wrong way.
> Studying the CGI spec and the source of Perl modules for the purpose
> are two good ways.
>
> You really should stick with CGI.pm or any of the alternative modules
> available such as CGI::Lite or CGI::Minimal, at least for the time being.
>
ok ok...i will
------------------------------
Date: 27 Sep 2004 18:22:37 GMT
From: ctcgag@hotmail.com
Subject: Re: accessing perl's internal hashing algorithm
Message-Id: <20040927142237.256$tT@newsreader.com>
robert_parks@csgsystems.com (rob) wrote:
> Hi, I have a performance intensive script that needs to hash a lot of
> strings. I am guessing that perl's internal hashing algorithm is
> implemented at a low level, is optimized, etc. and I would like to
> access it though my perl scripts. Does anyone know how to do this?
I do this by using Perl hash variables :)
It is not clear to me exactly what you want to do. You want to use
Perl's hashing algorithm from within a Perl script, but without the
rest of the Hash-table machinery? I suppose you could copy the hashing
algorithm out of the Perl source and use it to create your own XS or
Inline::C code.
perlguts:
The hash algorithm is defined in the "PERL_HASH(hash, key, klen)"
macro:
hash = 0;
while (klen--)
hash = (hash * 33) + *key++;
hash = hash + (hash >> 5); /* after 5.6 */
But I don't see what this will get you. Calling this many times from
within Perl will probably spend more time on function-call overhead than on
hashing.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 27 Sep 2004 11:07:03 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: best way to search perldocs
Message-Id: <415856c7@news.victoria.tc.ca>
wana (ioneabu@yahoo.com) wrote:
: Question: How could I have found this command more easily in perldocs?
I use grep, find, or perl itself, to search through the pods.
On this computer, I found the perldocs as follows
C:> cd perl
C:\perl> dir /s/b *.pod
on linux, when all else fails, do a "find / -name \*pod"
On dos you can search multiple files using for.
for %i in (*.pod) do perl -ne "print if m/whatever/" %i
$0.02
------------------------------
Date: Mon, 27 Sep 2004 15:31:21 -0400
From: Chris Mattern <matternc@comcast.net>
Subject: Re: best way to search perldocs
Message-Id: <EaKdnUMawaAX98XcRVn-gw@comcast.com>
wana wrote:
> where I was sure that there was no way to do it. By the way, why
> doesn't system("cd $ARGV[0]") work?
Because system spawns a child process. You made a child process
which changed its working directory and then promptly terminated.
This did not, of course, change the working directory of the
*parent* process, your perl program.
>
> Thanks!
--
Christopher Mattern
"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"
------------------------------
Date: Mon, 27 Sep 2004 18:55:00 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: best way to search perldocs
Message-Id: <slrnclha2k.ct9.tadmc@magna.augustmail.com>
Malcolm Dew-Jones <yf110@vtn1.victoria.tc.ca> wrote:
> I found the perldocs as follows
[ snip ]
I let perldoc find them for me:
perldoc -l perl
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 27 Sep 2004 16:45:17 -0500
From: cp <cpryce@nospam.pryce.net>
Subject: Re: Continous Looping of a List
Message-Id: <270920041645172001%cpryce@nospam.pryce.net>
In article <cj2bca$sk$1@misc-cct.server.rpi.edu>, Paul Lalli
<mritty@gmail.com> wrote:
> The output of my function is identical to the output of your funciton,
> including returning the 2nd and last element when given the first. Can
> you explain to me what your function does that mine does not?
>
> Did you try to run my function, or are you just making an assumption it
> doesn't do what you want?
No. I responded with the clarrification based on another post. Sorry
about that. Your solution works as expected.
>
> > In article <KW_4d.173$va.125@trndny03>, Paul Lalli <mritty@gmail.com>
> > wrote:
> >
> >>My version of your function:
> >>
> >>sub array_nav {
> >> my ($val, @ids) = @_;
> >> my $pos;
> >> for ($pos=0; $pos<=$#ids; $pos++){
> >> last if $val == $ids[$pos];
> >> }
> >> return undef unless $pos < @ids; #error checking
> >
> >
> > Yes. I see what you are doing. however, I was hoping for error checking
> > to determine whether the selected id was part of the set Before
> > looping. May fault for not stating the problem more clearly.
> >
>
> The question here is "why?" Assuming you do have some sort of valid
> reason for this, checkout the Perl FAQ:
> perldoc -q contained
Correct. I was thinking of my recursive function ( the OP ). Having
started down the recursive path, I was thinking that I would need to
check that $val as part of @ids first, or I would have inifinite
recursion. Redoing the funciton without recursion, error checking as
you wrote it is certainly correct.
--
cp
------------------------------
Date: Mon, 27 Sep 2004 23:56:38 +0100
From: Andy Baxter <news4@earthsong.null.free-online.co.uk>
Subject: gtk2 / glade problem.
Message-Id: <pan.2004.09.27.22.56.36.810214@earthsong.null.free-online.co.uk>
I've just install the gtk2 and gtk2-glade distributions, for building a
simple gui for a perl script. glade2perl keeps failing with this :
$ glade2perl-2 fileman.glade
Can't locate Gtk2/Window.pm in @INC (@INC contains: ./
/home/dermot/Devel/Glade-Perl-Two /etc/perl /usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5
/usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl
/usr/local/lib/perl/5.8.3 /usr/local/share/perl/5.8.3
/usr/local/lib/perl/5.8.2 /usr/local/share/perl/5.8.2
/usr/local/lib/perl/5.8.1 /usr/local/share/perl/5.8.1
/usr/local/lib/perl/5.8.0 /usr/local/share/perl/5.8.0 .) at
/usr/local/share/perl/5.8.4/Glade/Two/Run.pm line 25. BEGIN
failed--compilation aborted at
/usr/local/share/perl/5.8.4/Glade/Two/Run.pm line 25. Compilation failed
in require at /usr/local/share/perl/5.8.4/Glade/Two/App.pm line 29. BEGIN
failed--compilation aborted at
/usr/local/share/perl/5.8.4/Glade/Two/App.pm line 29. Compilation failed
in require at /usr/local/share/perl/5.8.4/Glade/Two/Generate.pm line 32.
BEGIN failed--compilation aborted at
/usr/local/share/perl/5.8.4/Glade/Two/Generate.pm line 32. Compilation
failed in require at /usr/bin/glade2perl-2 line 14. BEGIN
failed--compilation aborted at /usr/bin/glade2perl-2 line 14.
The Gtk2 examples work OK, but I can't find any .pm files for
Window,Dialog etc. anywhere in the perl path.
Does anyone know how to get this working?
--
http://www.niftybits.ukfsn.org/
remove 'n-u-l-l' to email me. html mail or attachments will go in the spam
bin unless notified with [html] or [attachment] in the subject line.
------------------------------
Date: Mon, 27 Sep 2004 23:33:12 +0200
From: Lepi <lepi_MAKNI_ME_@fly.srk.fer.hr>
Subject: Hash as an function argument
Message-Id: <cja10i$ch1$1@bagan.srce.hr>
Hello
When I'm calling a subroutine with one or two aguments, I use
something like this:
my ($first,$second)=@_;
to access them.
What if I want to pass a hash to function like:
%something={$first=>1,$second=>2};
function(%something);
sub function
{
How to access %something, and not to make it global???
}
Maybe I'm going in a totally wrong direction..
Thanks
Lepi
------------------------------
Date: Tue, 28 Sep 2004 00:03:37 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hash as an function argument
Message-Id: <2rrh17F1cdagsU1@uni-berlin.de>
Lepi wrote:
> When I'm calling a subroutine with one or two aguments, I use
> something like this:
> my ($first,$second)=@_;
> to access them.
>
> What if I want to pass a hash to function like:
> %something={$first=>1,$second=>2};
Please be more careful with what you post to the group. That makes
absolutely no sense.
- Enable strictures and warnings, not least when experimenting with
Perl code.
- Copy, don't re-type, code that you post.
You should use parentheses, not braces, when assigning a hash in Perl.
> function(%something);
>
> sub function
> {
> How to access %something, and not to make it global???
> }
What have you tried? As long as you only pass one hash, you can do
just like that. Then you don't actually pass a hash, but rather a list
of keys and values, but that does not prevent you from doing:
sub function {
my %something = @_;
However, you'd better get into the habit to pass a hash reference instead:
function( \%something );
sub function {
my $hashref = shift;
print "$_ = $hashref->{$_}\n" for keys %$hashref;
}
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 27 Sep 2004 22:12:43 GMT
From: "A. Sinan Unur" <usa1@llenroc.ude.invalid>
Subject: Re: Hash as an function argument
Message-Id: <Xns9571B975016D3asu1cornelledu@132.236.56.8>
Lepi <lepi_MAKNI_ME_@fly.srk.fer.hr> wrote in
news:cja10i$ch1$1@bagan.srce.hr:
> Hello
>
> When I'm calling a subroutine with one or two aguments, I use
> something like this:
> my ($first,$second)=@_;
> to access them.
>
> What if I want to pass a hash to function like:
> %something={$first=>1,$second=>2};
You seem to be a more than a little confused here about variables versus
hash keys and hashes versus hash references. Have you read perlsub,
perlreftut etc?
use strict;
use warnings;
sub dump_hash {
my %hash = @_;
for (keys %hash) {
print "\$hash{$_} = $hash{$_}\n" ;
}
}
sub dump_hash_ref {
my $hash_ref = shift;
for (keys %$hash_ref) {
print "\$hash_ref->{$_} = ", $hash_ref->{$_}, "\n";
}
}
dump_hash(first => 'One', second => 'Two');
dump_hash_ref({ first => 'One', second => 'Two' });
__END__
------------------------------
Date: Mon, 27 Sep 2004 19:00:33 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Hash as an function argument
Message-Id: <slrnclhad1.ct9.tadmc@magna.augustmail.com>
Lepi <lepi_MAKNI_ME_@fly.srk.fer.hr> wrote:
> %something={$first=>1,$second=>2};
Your hash has a *single* pair in it.
The key is a stringified reference, its value is undef.
The values for $first and $second cannot be accessed at all.
That data structure is useless...
... and so is this followup (which is to be expected when you
post so carelessly).
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 27 Sep 2004 11:49:28 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Parsing Email
Message-Id: <415860b8@news.victoria.tc.ca>
Dan (dan_hoffard@hailmail.net) wrote:
: What is the best way to get the body of the following email message
: into a file?
use MIME::Parser
------------------------------
Date: Mon, 27 Sep 2004 19:04:20 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Parsing Email
Message-Id: <slrnclhak4.ct9.tadmc@magna.augustmail.com>
Dan <dan_hoffard@hailmail.net> wrote:
> for (file_read "$f_email_html") {
> print "$i";
for (file_read $f_email_html) {
print $i;
perldoc -q vars
What's wrong with always quoting "$vars"?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 27 Sep 2004 19:16:37 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Precedence of exponentiation
Message-Id: <slrnclgpok.hv.abigail@alexandra.abigail.nl>
David Frauzel (nemo@weathersong.net) wrote on MMMMXLV September MCMXCIII
in <URL:news:1096274871.IRQ7IrUc0D7p5ylxmw/4bw@teranews>:
__ Abigail <abigail@abigail.nl> wrote in
__ news:slrnclfhfa.hv.abigail@alexandra.abigail.nl:
__
__ > Short answer: because C has the same precedence table. I think it's
__ > commonly regretted in the Perl world that it is this way, but the
__ > advantages of changing the precedence table are dwarved by the pain
__ > it will cause.
__
__ Meh, well, that's almost what I thought. <rant> I think that's a fine
__ historical reason, but Perl is no longer "something C programmers move
__ to", it's what web designers use, or even new programmers use. Perl is a
__ language in its own right, I think it's unfair it be "hostage" to C.
__ </rant>
What is your point? Do you think it's fair to break an unknown, and
potentially large, number of programs just because you feel uncomfortable
with the current precendence table?
__ > That doesn't make *any* sense at all. A precedence table *never*
__ > causes a rearrangement of operators. If your suggestion would be rule,
__ > then
__ >
__ > "foo" . length "bar" (equals "foo3")
__ >
__ > would be equivalent to
__ >
__ > length ("foo" . "bar") (equals 6)
__ >
__ > as named unary operators have lower precedence than concatenation.
__
__ I'm talking about parse trees. (Not sure if we're on the same
__ wavelength.)
I know. So do I.
__ Run Deparse on that statement, and you actually see this:
__
__ 'foo' . length('bar')
Yes.
__ (Which also indicates how the preprocessor detected the useless use of
__ double-quotes.)
Useless? What do you mean by that? Or do you mean that the output
of replaced the "useless" double-quotes with the equally "useless"
single-quotes? Do note that if you write
foo . length bar
it won't compile under strictness, and that it will warn with warnings
turned on.
__ Precedence is working just like it should - but the *parser* is giving
__ you the extra convenience of treating unary ops differently based on
__ whether you're looking at the left or right side of them.
__
__ Try deparse on these:
__
__ length 'foo' x 3
__ length 'foo' || die
__
__ (Use -MO=Deparse,-p for a better visual.)
__
__ A lucid example is:
__
__ print 1, 2, print 'foo', 'bar'
__
__ The parse tree produced demonstrates differential treatment of the
__ precedence of the list operator from the left side and the right, because
__ that's how the English language itself works. (Which begets another
__ interesting conversation, but that's for a different NG.)
__
__ Show me some concrete docs if I've got this all wrong?
You are not wrong, but what is your point? How does that make
parsing
a ** -b
equally to parsing
-(a ** b)
?
__ > It's not a double standard. Rearranging of an expression has little to
__ > do with precedence.
__
__ Please describe to me how Perl builds its parse trees, then, without
__ using precedence in any part. Precedence plays intimately with parse
__ trees in all the references I have read, and parse trees imply arranging
__ tokens (hierarchically).
^^^^^^^^^^^^^^
Exactly.
It doesn't rearrange them. It doesn't mean "Hmmm, we have an unary operator
in front of a term, let's take it out and put it front of a larger expression".
__ Thanks for the suggestion about C, though. I do not mean *at all* to
__ sound snooty when I say "my parser will do it differently". I wouldn't be
__ basing my parser on Perl if I did not have a tremendous respect for it in
__ the first place. However, as a computer scientist, I am necessarily
__ suspect of all things computational, and am intent on building yet
__ another mousetrap. ;}
I can't recall any language which parses constructs like
TERM1 BIN_OP UNARY_OP TERM2
and
UNARY_OP (TERM1 BIN_OP TERM2)
identically.
Could you name a few? As a computer scientist, you must know a lot of
languages.
Abigail
--
A perl rose: perl -e '@}-`-,-`-%-'
------------------------------
Date: 27 Sep 2004 20:49:35 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Precedence of exponentiation
Message-Id: <slrnclgv6v.hv.abigail@alexandra.abigail.nl>
David Frauzel (nemo@weathersong.net) wrote on MMMMXLV September MCMXCIII
in <URL:news:1096281801.SdYPCNkkB1jaX7RqSEnb0g@teranews>:
`' Joe Smith <Joe.Smith@inwap.com> wrote in
`' news:v1R5d.267889$mD.34406@attbi_s02:
`'
`' > It would be absurd to expect the minus sign to move like that.
`' >
`' > The exponentation operator takes two arguments. It's high precedence
`' > means that the two arguments must be made available before doing
`' > anything else (such as addition or multiplication). -2**-4 is
`' > parsed as -(2**(-4)) which gathers up the right-hand side of the **
`' > before doing exponentiation.
`'
`' Exactly. So (in the parser) its right side seems to regard ** with
`' different precedence than does its left. Right? Er, correct...?
Neither right, nor wrong. Your statement doesn't make sense.
Abigail
--
$_ = "\nrekcaH lreP rehtona tsuJ"; my $chop; $chop = sub {print chop; $chop};
$chop -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> ()
-> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> ()
------------------------------
Date: Mon, 27 Sep 2004 22:20:01 GMT
From: David Frauzel <nemo@weathersong.net>
Subject: Re: Precedence of exponentiation
Message-Id: <1096323603.Tv7YuolE2hBjXc73UJyKYQ@teranews>
Abigail, I'm not here to beget a flame-war. I'll continue to reply, for
conversation, but I'll simply cease if things appear to be getting out of
hand. My topic isn't a troll, it's a valid question about how the Perl
parser works, and ramblings about alternatives.
Abigail <abigail@abigail.nl> wrote in
news:slrnclgpok.hv.abigail@alexandra.abigail.nl:
> What is your point? Do you think it's fair to break an unknown, and
> potentially large, number of programs just because you feel
> uncomfortable with the current precendence table?
It was a rant. Not to be taken seriously. Another poster up above agreed,
you do not. I don't really think Perl is going to change this behavior
any time real soon, but Perl6 certainly does change quite a few things.
Languages evolve. Natural languages, and computer languages. I understand
that you feel support for legacy code is more important than reform, I
simply feel differently. I don't think it would be the first time in
history (or even for Perl, I believe) it's happened, either.
> Useless? What do you mean by that? Or do you mean that the output
> of replaced the "useless" double-quotes with the equally "useless"
> single-quotes? Do note that if you write
Maybe I wasn't being entirely germane, but I think you're taking me
entirely too seriously. ;D
The example you gave used double-quotes around text that had no need for
double-quotes. The preprocessor apparently converted them to single-
quotes. It was interesting to observe that, because my own preprocessor
does the same thing (it just felt "right").
> You are not wrong, but what is your point? How does that make
> parsing
>
> a ** -b
>
> equally to parsing
>
> -(a ** b)
>
> ?
What I was driving at (I think the point is quite belabored, by now) is
that the precedence of unary minus seems to behave differently on the
left and right side of exponentiation. Let me try to illustrate. Again,
tell me if you think this is fully wrong, but it's basically the only way
I can think of for my own parser to simulate the same behavior. (I'm
quite tempted to just go digging through the Perl source code to find the
parser, and see for myself.)
-2 ** -4
Lexeme: Unary minus
Tree:
-
Lexeme: Const
Tree:
-
/
2
Lexeme: Exponentiation
Tree:
-
/
**
/
2
Lexeme: Unary minus
Tree:
-
/
**
/ \
2 -
Lexeme: Const
Tree:
-
/
**
/ \
2 -
/
4
This is a tree of what B::Concise spits out for that statement. It
clearly demonstrates that there is one unary minus above the
exponentiation, and another below the exponentiation. Arrangement of
nodes in a hierarchical tree is accomplished using precedence. Therefore,
unary minus had different precedence on each side of exponentiation. This
must be a special case, because certainly this is not the normal behavior
for operator precedence.
But I'll see if I can find the .c file for the Perl parser sometime this
week, so I can verify whether or not Perl's parser is doing what I think
it's doing.
> Exactly.
>
> It doesn't rearrange them. It doesn't mean "Hmmm, we have an unary
> operator in front of a term, let's take it out and put it front of a
> larger expression".
Before the parser, there is no arrangement. Are we going to argue
semantics? The parser did exactly that: "This unary operator's precedence
indicates it should be the root of the parse tree." / "This next unary
operator's precedence indicates it should be the right side of
exponentiation, not at the root."
> I can't recall any language which parses constructs like
>
> TERM1 BIN_OP UNARY_OP TERM2
>
> and
>
> UNARY_OP (TERM1 BIN_OP TERM2)
>
> identically.
You've lost me, there. If you're arguing whether different languages
parse differently, then yes, I have at least one language for you to
consider: SmallTalk. 2 + 3 * 4 = 20.
------------------------------
Date: 27 Sep 2004 23:36:51 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Precedence of exponentiation
Message-Id: <slrnclh90j.hv.abigail@alexandra.abigail.nl>
David Frauzel (nemo@weathersong.net) wrote on MMMMXLV September MCMXCIII
in <URL:news:1096323603.Tv7YuolE2hBjXc73UJyKYQ@teranews>:
:) Abigail, I'm not here to beget a flame-war. I'll continue to reply, for
:) conversation, but I'll simply cease if things appear to be getting out of
:) hand. My topic isn't a troll, it's a valid question about how the Perl
:) parser works, and ramblings about alternatives.
:)
:) Abigail <abigail@abigail.nl> wrote in
:) news:slrnclgpok.hv.abigail@alexandra.abigail.nl:
:)
:) > What is your point? Do you think it's fair to break an unknown, and
:) > potentially large, number of programs just because you feel
:) > uncomfortable with the current precendence table?
:)
:) It was a rant. Not to be taken seriously. Another poster up above agreed,
:) you do not.
What you wrote was:
I think that's a fine historical reason, but Perl is no longer
"something C programmers move to", it's what web designers use, or even
new programmers use. Perl is a language in its own right, I think it's
unfair it be "hostage" to C.
Which to me suggest that you think Perl should change on how it parses
things. I haven't seen any poster in this thread agreeing with that.
I agree that it would have been better if Perl parsed -a ** b as
(-a) ** b, but I strongly disagree Perl should change on how it parses
expressions.
:) I don't really think Perl is going to change this behavior
:) any time real soon, but Perl6 certainly does change quite a few things.
Perl6 is a different language, which won't happen any time soon. This
newsgroup discusses real things, not vaporware.
:) Languages evolve. Natural languages, and computer languages. I understand
:) that you feel support for legacy code is more important than reform, I
:) simply feel differently. I don't think it would be the first time in
:) history (or even for Perl, I believe) it's happened, either.
Oh, it has happened. Most of the time it was not intentional. People go
to great lengths to make sure any program that was written for a previous
version of Perl will still work with a new version. Incompatible changes
would need a very good justification. And I do believe that a dramatic
change the way you like to see hasn't happened before - at least not since
5.000.
:) > Useless? What do you mean by that? Or do you mean that the output
:) > of replaced the "useless" double-quotes with the equally "useless"
:) > single-quotes? Do note that if you write
:)
:) Maybe I wasn't being entirely germane, but I think you're taking me
:) entirely too seriously. ;D
:)
:) The example you gave used double-quotes around text that had no need for
:) double-quotes. The preprocessor apparently converted them to single-
:) quotes. It was interesting to observe that, because my own preprocessor
:) does the same thing (it just felt "right").
What preprocessor are you talking about? Perl doesn't have any. And don't
get confused by the fact that the deparser doesn't emit identical code.
It deparses 'q{foo}' as 'q[foo]'. Does that mean the '{}' is useless?
:) > You are not wrong, but what is your point? How does that make
:) > parsing
:) >
:) > a ** -b
:) >
:) > equally to parsing
:) >
:) > -(a ** b)
:) >
:) > ?
:)
:) What I was driving at (I think the point is quite belabored, by now) is
:) that the precedence of unary minus seems to behave differently on the
:) left and right side of exponentiation. Let me try to illustrate. Again,
:) tell me if you think this is fully wrong, but it's basically the only way
:) I can think of for my own parser to simulate the same behavior. (I'm
:) quite tempted to just go digging through the Perl source code to find the
:) parser, and see for myself.)
:)
:) -2 ** -4
:)
:) Lexeme: Unary minus
:) Tree:
:) -
:)
:) Lexeme: Const
:) Tree:
:) -
:) /
:) 2
:)
:) Lexeme: Exponentiation
:) Tree:
:) -
:) /
:) **
:) /
:) 2
:)
:) Lexeme: Unary minus
:) Tree:
:) -
:) /
:) **
:) / \
:) 2 -
:)
:) Lexeme: Const
:) Tree:
:) -
:) /
:) **
:) / \
:) 2 -
:) /
:) 4
:)
:) This is a tree of what B::Concise spits out for that statement. It
:) clearly demonstrates that there is one unary minus above the
:) exponentiation, and another below the exponentiation. Arrangement of
:) nodes in a hierarchical tree is accomplished using precedence. Therefore,
:) unary minus had different precedence on each side of exponentiation. This
:) must be a special case, because certainly this is not the normal behavior
:) for operator precedence.
Grammar:
Expression: Term | '-' Expression
Term: Digits | Term '**' Expression
Digits: Digit | Digit Digits
Digit: '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
And then
-2 ** -4
will parse as
-(2 ** (-4))
An exercise you'd give after the first lessons dealing with grammars.
You're the proclaimed computer scientist - you work out the details.
As you see, no special casing of the ** operator in combination with
unary minus.
:) But I'll see if I can find the .c file for the Perl parser sometime this
:) week, so I can verify whether or not Perl's parser is doing what I think
:) it's doing.
perly.y in the Perl source tree.
Please point out the special casing of unary minus in combination with **.
:) > Exactly.
:) >
:) > It doesn't rearrange them. It doesn't mean "Hmmm, we have an unary
:) > operator in front of a term, let's take it out and put it front of a
:) > larger expression".
:)
:) Before the parser, there is no arrangement. Are we going to argue
:) semantics? The parser did exactly that: "This unary operator's precedence
:) indicates it should be the root of the parse tree." / "This next unary
:) operator's precedence indicates it should be the right side of
:) exponentiation, not at the root."
:)
:) > I can't recall any language which parses constructs like
:) >
:) > TERM1 BIN_OP UNARY_OP TERM2
:) >
:) > and
:) >
:) > UNARY_OP (TERM1 BIN_OP TERM2)
:) >
:) > identically.
:)
:) You've lost me, there. If you're arguing whether different languages
:) parse differently, then yes, I have at least one language for you to
:) consider: SmallTalk. 2 + 3 * 4 = 20.
Let me quote you once again:
But that's not why I'm asking the question, actually. What bugs me is
this:
2**-4
... gives you 2**(-4), not -(2**4). Looking at 2**-4, it seems obvious
that this should be the case, but it apparently defies the above stated
precedence rule. A token parser should recognize that the unary minus has
lower precedence than **, and push ** below the unary minus, in exactly
the same way it would with -2**4.
which to me indicates you are argueing that 'a ** -b' should be identical
to '-(a ** b)' by extracting the unary minus from the middle of the
expression to the front.
So, once again I ask, do you know any language that does so? Your
Smalltalk example doesn't do this.
Abigail
--
perl -le 's[$,][join$,,(split$,,($!=85))[(q[0006143730380126152532042307].
q[41342211132019313505])=~m[..]g]]e and y[yIbp][HJkP] and print'
------------------------------
Date: Tue, 28 Sep 2004 00:37:44 GMT
From: David Frauzel <nemo@weathersong.net>
Subject: Re: Precedence of exponentiation
Message-Id: <1096331864.bsFB8DPdOui0wavKFg4d9Q@teranews>
Abigail <abigail@abigail.nl> wrote in
news:slrnclh90j.hv.abigail@alexandra.abigail.nl:
> Which to me suggest that you think Perl should change on how it parses
> things. I haven't seen any poster in this thread agreeing with that.
> I agree that it would have been better if Perl parsed -a ** b as
> (-a) ** b, but I strongly disagree Perl should change on how it parses
> expressions.
I wrapped it up in <rant> to suggest I wasn't being entirely serious. If
anything I've written gives the appearance of advocating Perl5 reform, it
was not my intention. The parser I'm writing isn't even written in Perl
(nor does it use yacc), and that's my primary reason for this topic.
> Perl6 is a different language, which won't happen any time soon. This
> newsgroup discusses real things, not vaporware.
Yikes, sore spot I guess. Won't bring it up again. :p
> Oh, it has happened. Most of the time it was not intentional. People
> go to great lengths to make sure any program that was written for a
> previous version of Perl will still work with a new version.
> Incompatible changes would need a very good justification. And I do
> believe that a dramatic change the way you like to see hasn't happened
> before - at least not since 5.000.
And I recall programming Perl before 5.000. :D
> What preprocessor are you talking about? Perl doesn't have any. And
> don't get confused by the fact that the deparser doesn't emit
> identical code. It deparses 'q{foo}' as 'q[foo]'. Does that mean the
> '{}' is useless?
Oops, I didn't mean to use the word preprocessor. (I'm cross-referencing
my own parser and perly.y / perly.c, and I'm making quite a few
multitasker typos.) I mean the optimization made throughout each compile
pass. (I know, not the same thing as a preprocessor.)
What I meant by "useless" is that "foo" (double-quotes around 'foo') is
not as efficient as 'foo' (single quotes). The compiler's optimization
sequence converts the double-quotes into single-quotes, because there's
nothing to interpolate. I know you know this, and I already said I was
being nit-picky. ;p
> Grammar:
>
> Expression: Term | '-' Expression
> Term: Digits | Term '**' Expression
> Digits: Digit | Digit Digits
> Digit: '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' |
> '9'
And:
"termbinop : term POWOP term",
No, I don't see any special rules. So, I don't think it's Perl's parser I
misunderstand, it's yacc. My idea of a parser with both precedence and
associativity is not the same as what yacc is doing. In the interest of
building a better parser, I'll do some reading on yacc sometime.
> which to me indicates you are argueing that 'a ** -b' should be
> identical to '-(a ** b)' by extracting the unary minus from the middle
> of the expression to the front.
>
> So, once again I ask, do you know any language that does so? Your
> Smalltalk example doesn't do this.
Mine does. It builds a parse tree by starting at the root, and comparing
precedence, until it finds an available node, or detects that a token
somewhere down from the root has less precedence than the current token
in the parser. It's loosely based on a tree sort. The core of the parser
is about 75 lines of Pascal (Delphi). It works identically to Perl with
everything except the exponentiation operator (bug). So I wrote the
lexer, too (a couple hundred lines).
------------------------------
Date: Mon, 27 Sep 2004 23:56:27 +0200
From: peter pilsl <pilsl@goldfisch.at>
Subject: unicode: equal strings give different results?
Message-Id: <41588d0f@e-post.inode.at>
perl 5.8.5
Does a string hold any extra information additional to its pure characters?
I managed to create two strings that are equal to the 'eq'-operator and
have equal ord-values of all characters, but gives different results if
feeded to the very same subroutine. It seems one of the two strings does
not know fully that its actually unicode. (length gives the correct
result. wrong lengths are usually a first hint that the string does not
feel as unicode)
I didnt manage to provide a really short example, the whole script is
46lines and includes CGI.
I read a text (one char per line) from a CGI-field (UTF8) and print out
the sorted text. The sorting is supposed to be according to german
locales, so I use the locale-pragma (which is ways faster than
unicode::collate)
The sorting order however of my output is wrong. I manually included a
possible input as reference to the script and here the output is
correct. If I enter the reference-string in my textfield the output is
still wrong, but the two strings are exactely the same according to 'eq'
and the hex-dump.
If I do a chr(ord($_)) on all chars the result is ok again.
So obviously I miss something very important about unicode here. Some
extra information is stored somewhere but I dont know about it.
the example is online under
http://www.customers.goldfisch.at/cgi-bin/unicodetest9.pl
If you enter (one line each, dont forget the last newline after p)
ä
b
ö
a
o
p
in the mask, you'll produce the same input than the referencestring, but
will see different results.
Where am I stuck?
thnx,
peter
---------------------------------------------------------
#!/usr/local/bin/perl -w
use strict;
# step1: prepare for german locales
use POSIX qw(locale_h);
use locale;
setlocale(LC_COLLATE, "de_AT");
# step2: prepare for unicode
binmode(STDOUT,":utf8");
binmode(STDIN,":utf8");
# step3: prepare for CGI
use CGI;
my $query = new CGI;
my $charset = 'UTF-8';
$CGI::XHTML= 0;
print
$query->header(-charset=>$charset),$query->start_html(-title=>'Unicodetest');
print "cgi-version = ",$CGI::VERSION,"<br><br>\n";
# set reference-string
my $sr=("\x{00e4}\n\x{0062}\n\x{00f6}\n\x{0061}\n\x{006f}\n\x{0070}\n");
# stepA : get unicode and print it
print "<h4>your input</h4>";
my $si=$query->param('unicode');
$si=~s/\r//g;
#my $sin='';foreach(0..length($si)-1)
{$sin.=chr(ord(substr($si,$_,1)))};$si=$sin;
print_and_sort($si);
# stepB : get reference and print it
print "<h4>reference</h4>";
print "(input and reference are considered equal)<br>" if $si eq $sr;
$sr=~s/\r//g;
print_and_sort($sr);
# stepC : print text-field and finish CGI
print '<br><br>enter your unicode-testtext here :
',$query->start_multipart_form,
$query->textarea(-name=>'unicode',-rows=>10,-columns=>100),
"\n<br>\n",
$query->submit(-name=>'submit',-value=>'proceed'),"\n",
$query->endform,"\n";
print $query->end_html;
# sub : get a string, print its ord, split it by its linebreaks and then
# sort the data and print it out
sub print_and_sort {
my $s=shift;
print "hexdump : ";
foreach my $i (0..length($s)-1) {
print sprintf ("%04x",ord(substr($s,$i,1)))." ";
}
print "<br>\n";
print "<br>sorted:<br>\n";
my @data=split(/\n/,$s);
foreach (sort(@data)) {
print $_;
print " (length=",length($_),")";
print " ";
foreach my $j (0..length($_)-1) {
print sprintf ("%04x",ord(substr($_,$j,1)))." ";
}
print "<br>\n";
}
}
--
http://www2.goldfisch.at/know_list
http://leblogsportif.sportnation.at
------------------------------
Date: Mon, 27 Sep 2004 23:33:41 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: unicode: equal strings give different results?
Message-Id: <Pine.LNX.4.61.0409272330371.6305@ppepc56.ph.gla.ac.uk>
On Mon, 27 Sep 2004, peter pilsl wrote:
> perl 5.8.5
haven't got that far yet...
> Does a string hold any extra information additional to its pure characters?
> I managed to create two strings that are equal to the 'eq'-operator and have
> equal ord-values of all characters, but gives different results if feeded to
> the very same subroutine.
This sounds like an FAQ to me.
> It seems one of the two strings does not know fully
> that its actually unicode.
At least in the versions of Perl that I've been familiar with, Perl
will not upgrade an iso-8859-1 string to Unicode unless it finds some
reason to do so. This can result in identical strings appearing to
not match. I don't have the references to hand, but I'm sure it's
either an FAQ or in the unicode tutorials.
Hope this helps a bit.
------------------------------
Date: Mon, 27 Sep 2004 20:11:05 -0400
From: Shawn Corey <shawn.corey@sympatico.ca>
Subject: Re: unicode: equal strings give different results?
Message-Id: <HZ16d.4794$MD5.385524@news20.bellglobal.com>
peter pilsl wrote:
>
> perl 5.8.5
>
> Does a string hold any extra information additional to its pure characters?
> I managed to create two strings that are equal to the 'eq'-operator and
> have equal ord-values of all characters, but gives different results if
> feeded to the very same subroutine. It seems one of the two strings does
> not know fully that its actually unicode. (length gives the correct
> result. wrong lengths are usually a first hint that the string does not
> feel as unicode)
>
I haven't read your code but you can start with:
perldoc perluniintro
perldoc perlunicode
perldoc encode
And yes, there are two types of strings in Perl 5.8+, one is_utf8(), the
other not.
--- Shawn
------------------------------
Date: 27 Sep 2004 16:49:48 -0700
From: tudmuf2b@onebox.com (John Davis)
Subject: Using "system" command - is it "bad practice" for perl?
Message-Id: <7167a8d.0409271549.346b0779@posting.google.com>
A couple of quick questions, it is considered "bad" perl programming
(from a style perspective) to ever use the system() command to call
UNIX level commands in a script, or should the "backtick"/exec method
be used at all times (if possible).
I was working on a piece of code today and realized that after the
running the system commands as follows:
system "co -l /src/test-script2.pl"; # to checkout for RCS
system "vi /src/test-script2.pl"; # edit and process it and return
back
*** IT NEVER COMES BACK from the vi command!
system "ci -u /src/test-script2.pl";
foreach @x {
blah blah blah...
}
It did not return "control" back to my script and I had to Control-C
out of this script, and got frustrated at the system command. Is this
supposed to happen? Because in a ksh script, after doing a "vi", I
should get back to where I need to be.
Thanks!
------------------------------
Date: Tue, 28 Sep 2004 01:57:41 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Using "system" command - is it "bad practice" for perl?
Message-Id: <2rrnn5F1d8butU1@uni-berlin.de>
John Davis wrote:
> A couple of quick questions, it is considered "bad" perl
> programming (from a style perspective) to ever use the system()
> command to call UNIX level commands in a script, or should the
> "backtick"/exec method be used at all times (if possible).
Short answer: No.
When reading your message, I can't help getting the feeling that you
haven't studied the docs for system()
perldoc -f system
respective backticks (or the qx// operator)
perldoc perlop
Please do so, and come back if that does not answer you questions.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 28 Sep 2004 00:02:04 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Using "system" command - is it "bad practice" for perl?
Message-Id: <0S16d.2750$2t5.464@trnddc07>
John Davis wrote:
> A couple of quick questions, it is considered "bad" perl programming
> (from a style perspective) to ever use the system() command to call
> UNIX level commands in a script, or should the "backtick"/exec method
> be used at all times (if possible).
Is it bad considered bad style to ever use a hammer or should I always use a
wrench.
Well, dude, those are different tools. It depends on what you want to do.
> I was working on a piece of code today and realized that after the
> running the system commands as follows:
>
> system "co -l /src/test-script2.pl"; # to checkout for RCS
> system "vi /src/test-script2.pl"; # edit and process it and return
> back
>
> *** IT NEVER COMES BACK from the vi command!
Did you vi process terminate?
jue
------------------------------
Date: 28 Sep 2004 00:00:48 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Using "system" command - is it "bad practice" for perl?
Message-Id: <slrnclhadg.hv.abigail@alexandra.abigail.nl>
John Davis (tudmuf2b@onebox.com) wrote on MMMMXLV September MCMXCIII in
<URL:news:7167a8d.0409271549.346b0779@posting.google.com>:
`' A couple of quick questions, it is considered "bad" perl programming
`' (from a style perspective) to ever use the system() command to call
`' UNIX level commands in a script, or should the "backtick"/exec method
`' be used at all times (if possible).
No. system and backticks have different purposes. If you use backticks,
perl executes the given command *and collects its output*, returning
the output as a single scalar, or a list of scalars, depending on the
context. system, on the other hand, doesn't collect the output - it will
return the exit status of the process. system() also has a 'safe' mode,
which will prevent perl from using a shell. You can't do that with
backticks.
`' I was working on a piece of code today and realized that after the
`' running the system commands as follows:
`'
`' system "co -l /src/test-script2.pl"; # to checkout for RCS
`' system "vi /src/test-script2.pl"; # edit and process it and return
`' back
`'
`' *** IT NEVER COMES BACK from the vi command!
Huh? How so? It should come back whenever 'vi' is done (that is, when you
quit your editor). Just like it waits for any other program to finish.
If you want to run a different process *in parallel*, fork() and exec().
`' system "ci -u /src/test-script2.pl";
`'
`' foreach @x {
`' blah blah blah...
`' }
`'
`' It did not return "control" back to my script and I had to Control-C
`' out of this script, and got frustrated at the system command. Is this
`' supposed to happen? Because in a ksh script, after doing a "vi", I
`' should get back to where I need to be.
In Perl, it works the same way.
Abigail
--
perl -wlpe '}$_=$.;{' file # Count the number of lines.
------------------------------
Date: Mon, 27 Sep 2004 20:15:04 -0400
From: Shawn Corey <shawn.corey@sympatico.ca>
Subject: Re: Using "system" command - is it "bad practice" for perl?
Message-Id: <q126d.4795$MD5.386812@news20.bellglobal.com>
John Davis wrote:
> A couple of quick questions, it is considered "bad" perl programming
> (from a style perspective) to ever use the system() command to call
> UNIX level commands in a script, or should the "backtick"/exec method
> be used at all times (if possible).
>
> I was working on a piece of code today and realized that after the
> running the system commands as follows:
>
> system "co -l /src/test-script2.pl"; # to checkout for RCS
> system "vi /src/test-script2.pl"; # edit and process it and return
> back
In UNIX, it's better to use:
my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
system "$editor /src/test-script2.pl";
VISUAL is the visual (screen) editor but many people set EDITOR as it.
EDITOR is the line editor. The emacs users will thank you.
--- Shawn
PS I use vim (VI Improved)
------------------------------
Date: Mon, 27 Sep 2004 14:01:49 -0400
From: Scott W Gifford <gifford@umich.edu>
Subject: Re: Using C::Scan : How to ignore #includes ?
Message-Id: <qszd607h9pu.fsf@asteroids.gpcc.itd.umich.edu>
Abhinav <matrix_calling@yahoo.dot.com> writes:
[...]
> I want to "skip" all the #defines, #includes, etc ..
> Hence,
>
> C:Scan should (for my case) ignore any preprocessor directives. (It
> would be as if I am removing these before running C::Scan on the file.
>
> This includes #ifdef as well as #include
An extremely simplistic solution is to use as your preprocessor:
grep -v '^#'
or perhaps a script containing that.
I'm not familiar with C::Scan at all, so that may be off base, but
from following this discussion it looks like it might be useful.
----ScottG.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 7184
***************************************
