John Porter wrote:
undecorated variable names suffer from this showstopping weakness:
they can't be interpolated. Unless we change other aspects of perl's
syntax to support it, that is -- maybe s/${x}/5/. Now, maybe we can
live without variable interpolation; but I'd bet most perl
David L. Nicol wrote:
I am not suggesting dropping the magic signifiers from the beginning of
Perl scalars and containers. In fact, I resent these insinuations
(first Nathan's, now yours) that I am among those who suggest dropping the
decorations from perl scalars. I am not among that
"Myers, Dirk" wrote:
$mode = 0755 ;
$file = "Foobar" ;
#include sys/types.h
#include sys/stat.h
chmod($mode, $file) ;
Which chmod gets called, perl or C? What are the rules for figuring this
out?
Dirk
Following the documentation at
I don't know exactly how this message got marked "unread" again,
No, here it is, the server at Sun has decided to send it again,
which is all right, since I don't think I responded before going
home last friday.
Received:
from mercury.Sun.COM
"David L. Nicol" wrote:
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to be
barewords.
Anyways, I'm done harping on this issue. I think a single, simple syntax
is good. You
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to
be
barewords.
I think it's a sane decision -- IMHO barewords shouldn't be allowed to
Nathan Wiger wrote:
"David L. Nicol" wrote:
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to be
barewords.
Misstating my position, when I take one, is and will
f that's legal, what does:
print "I wonder what this is : " . length ;
do?
I imagine the first order of business for the C JIT team would be
some conversion operators. Numeric types stringify into decimal representation,
no reason to throw that away.
David L. Nicol wrote:
A bareword inside doublequotes is not interpreted, in Perl or C.
No; a "bareword" in quotes (any kind) is not a bareword.
--
John Porter
Nathan Wiger wrote:
"David L. Nicol" wrote:
my dog $spot;
to
dog spot;
If we only allow this where enough info is available to allocate dog-sized
pieces of memory directly, Perl can blaze through the code that deals with
dogs.
I don't see what barewords gain
Sam Tregar wrote:
On Thu, 31 Aug 2000, David L. Nicol wrote:
We're talking about making a faster Perl. C's syntax requires enough
clarity to compile to something quick. it is a very short hop from
my dog $spot;
to
dog spot;
What about the second version would
"David L. Nicol" wrote:
They gain us compliance with the whims of the people who like barewords
for variable names. You may or may not find that to be a good thing.
It's not just that I don't think dropping $'s is a good idea, but that
is the general consensus as well. I can't see
dog
some ways.
I want to see Perl become a full-blown C/C++ JIT. Since Perl is for
a large part a compatible subset of C I don't see this as unrealistic.
Delaying any post-token parsing of barewords until after looking at
what local declarations are in effect is part of it, dealing with the
On Thu, 31 Aug 2000, David L. Nicol wrote:
Perl looks, and AFAIK has always looked, like "C plus lune noise" to
many people.
I think Perl looks like "C plus moon noise" to former C programmers. I
imagine some people see it and think "Csh plus Awk noise". Perl is a lot
more than
: Thursday, August 31, 2000 9:31 AM
- - To: [EMAIL PROTECTED]
- - Subject: Re: the C JIT
- -
- -
- - On Thu, 31 Aug 2000, David L. Nicol wrote:
- -
- - Perl looks, and AFAIK has always looked, like "C plus lune
noise" to
- - many people.
- -
- - I think Perl looks like "C plus moon n
Sam Tregar wrote:
On Thu, 31 Aug 2000, David L. Nicol wrote:
run-time efficiency
C doesn't get run-time efficiency from its syntax, so we can't really
expect to get anything here. It gets it from its compilation
architecture. If you want to build a Perl frontend for GCC I think
"David L. Nicol" wrote:
my dog $spot;
to
dog spot;
If we only allow this where enough info is available to allocate dog-sized
pieces of memory directly, Perl can blaze through the code that deals with
dogs.
I don't see what barewords gain us here. Who says that
my
On Thu, 31 Aug 2000, David L. Nicol wrote:
We're talking about making a faster Perl. C's syntax requires enough
clarity to compile to something quick. it is a very short hop from
my dog $spot;
to
dog spot;
What about the second version would result in faster execution? Do
-blown C/C++ JIT. Since Perl is for
a large part a compatible subset of C I don't see this as unrealistic.
Delaying any post-token parsing of barewords until after looking at
what local declarations are in effect is part of it, dealing with the
one or two differences in operator precedence
19 matches
Mail list logo
