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
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
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
And how about:
int length = 256 ;
and, if 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 in
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
"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
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,
No it didn't. :-) Those are cascading headers (read the "by" field),
Sun's internal mail system has 3-4 hops and 2 firewalls to go through.
Received:
from
Ken Fox wrote:
Perl is more like lisp with a good syntax -- in other
words about as far from C as you can get.
I agree 100%.
--
John Porter
Uri Guttman wrote:
the best fit is the TIL (threaded inline code) model we have
discussed.
Yes!
--
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
Nathan Wiger wrote:
"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
"David L. Nicol" wrote:
No, that would be
dog $spot;
No, it wouldn't:
$r = new CGI;# CGI-new
See?
You can have your general consensus, I'm not in his army.
Well, unfortunately I think you're doomed to fail then. You're forcing
constraints on yourself that Perl cannot
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
Ken Fox wrote:
Trolling?
No, I'm not, it's the direction that RFC 61 ends up if you let it
take you there.
fast perl6 becomes, as well as slicing, dicing and scratching your
back, a drop-in replacement for gcc.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
[perl6-language removed from the follow-up]
"David L. Nicol" wrote:
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.
Trolling? First, Perl is more like lisp with a good syntax -- in other
w
"David L. Nicol" wrote:
No, I'm not, it's the direction that RFC 61 ends up if you let it
take you there.
You seem to be confusing:
(1) linking C code with Perl
with
(2) compiling Perl to C code
There is a world of difference. Swig does (1) pretty well already.
If you want a first
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
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
David Corbin wrote:
A C JIT is an interesting idea.
I think that a project works best when it has a set of goals (I haven't
seen one yet really for Perl 6). Unless this is one of the goals, I can
easily see how this could become a serious distraction to what I
perceive as the likely
-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
21 matches
Mail list logo