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
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 progr
John Porter wrote:
>
> 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
huh?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"Myers, Dirk" wrote:
> $mode = 0755 ;
> $file = "Foobar" ;
>
> #include
> #include
>
> chmod($mode, $file) ;
>
> Which chmod gets called, perl or C? What are the rules for figuring this
> out?
>
> Dirk
Following the documentation at
http://www.pe
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
> > 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
> 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 into dec
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
> > 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
"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. Yo
Nathan Wiger wrote:
> Intermingling it freely:
>
>my Dog $spot;
>int x;
>my int $y;
>#include
>char * name;
>#do some regexp matching
>s/x/5/;/* match the C value of x defined above */
>
> Is really confusing, even for us humans. :-)
>
> -Nate
Is it confusing?
> 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
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 (mercur
"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 cann
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 co
"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
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 versi
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 w
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? D
"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
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
]
- -> Sent: 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 p
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 C-with-scal
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 like
"David L. Nicol" wrote:
>
> Dan Sugalski wrote:
>
> > I do want to have a set of C/XS/whatever sources as part of the test suite
> > as well--right now perl's test suite only tests the language, and I think
> > we should also test the HLL interface we present, as it's just as
> > important in so
Dan Sugalski wrote:
> I do want to have a set of C/XS/whatever sources as part of the test suite
> as well--right now perl's test suite only tests the language, and I think
> we should also test the HLL interface we present, as it's just as
> important in some ways.
I want to see Perl become a f
26 matches
Mail list logo
