Re: we already have barewords as variables if we want them Re: the C JIT
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 group. First off, I am not insinuating any such thing. I made a plain statement of perl-land fact. Truth be told, I did not know who, if anyone, let alone if you, were a member of "drop the decoration" camp. As I said, I was not involved in the thread up to this point. Secondly, if anyone should resent anything, it should be I who resents your responding to -- and quoting -- private email back onto the list. Inexcusable. -- John Porter
Re: we already have barewords as variables if we want them Re: the C JIT
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 programmers
> would rail against that.
Now we're covering the same ground I covered with Nathan Wiger.
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 group.
Languages with undecorated variable names do not allow their interpolation.
Even if we allow some undecorated variable names as usable, those names will
still be undecorated, and will not interpolate without special treatment.
There are alternatives to interpolation, for instace sprintf().
Interpolation, as such, requires the variable names to be %decorated% somehow.
Bareword, or Undecorated, variables, such as perl 5.6's legal (as I understand it)
sub undecorated() : lvalue {
return $undecorated_stash_package::some_obscure_name;
}
do not interpolate.
C interpolation will still require the syntactic clue of variable name
decoration to operate, even if a human brain does keep a short list of recently
used referent names and interpolates them as needed for better compliance with
projected remote schema based on experience.
That trick is beyond the scope of what I believe are suggestions for reasonable
incremental improvements to a programming language.
That is where I draw the line.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=<>' /usr/dict/words
Re: we already have barewords as variables if we want them Re: the C JIT
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]
perl -e'map{sleep print$w[rand@w]}@w=<>' /usr/dict/words
Re: the C JIT
"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.perl.com/pub/doc/manual/html/pod/perlsub.html#Overriding_Builtin_Functions
on the way one can overload a perl builtin, functions (and bareword variables)
defined in the current package in C would hide their homonyms. So in your
example, the C chmod would be called, after $mode and $file are coerced into
a mode_t and a char*.
The hashbang would need to take switches just like cc does to indicate where
to find required system libraries, which would be remembered if possible, similar
to the way the Inline.pm
http://www.xray.mpe.mpg.de/mailing-lists/modules/2000-08/msg00078.html
module does it.
To use the perl function even after it has been hidden,
it can be referred to by its absolute name CORE::chmod.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=<>;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: we already have barewords as variables if we want them Re: the C JIT
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
RE: the C JIT
> > 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 into decimal representation, > no reason to throw that away. Well, the question was more one of the interaction between C statements and Perl functions. int length = 256 ; Isn't legal Perl. It's legal C. If it gets processed as C, though, print "I wonder what this is : " . length ; becomes ambiguous -- do we get the C variable, or the Perl function? (I suspect that the only way for this to work out is to decide that perl builtins are no longer legal C names.) Likewise, if we do: $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
Re: the C JIT
"Myers, Dirk" wrote:
> I still find this whole idea confusing, though. Just out of curiosity,
> though, would:
>
> #include a way for users to bail out gracefully
>
> be a syntax error?
It is clear to us that that is a comment and not a preprocessor directive.
The #include preprocessor directive is more than match /^#include/ it is
more like (/^#include (".+")\s*\Z/ or /^#include (<.+>)\s*\Z/). And anything
that would be a syntax error in C, a poorly formed preprocessor directive, is
a simple Perl comment.
> 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 into decimal representation,
no reason to throw that away.
> Dirk
thanks for your support
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=<>;for(;;){sleep print[rand@w]}' /usr/dict/words
we already have barewords as variables if we want them Re: the C JIT
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 continue to be
a way to get a rise out of me. This may be a character flaw on my part.
Introspection is digression.
Regexes, unless set otherwise, interpolate
like double-quotes. Double-quotes explicitly recognizes $ to mean that
a variable starts here. A bareword inside doublequotes is not interpreted,
in Perl or C.
> Anyways, I'm done harping on this issue. I think a single, simple syntax
> is good. You and I will have to agree to disagree on this point.
I don't mind agreeing to disagree, but I won't do it until you can
correctly state my position, which you haven't done yet.
>From my point of view it appears that you are confusing me with one of the
people (whose names I would have to look up to list) who want to remove
leading $ and @ from variables. I am not in their camp. I agree with you
that those are not workable proposals.
I do not say variables are barewords, I say that barewords may, in addition
to being function calls, be variables. Which is a behavior we can, in fact,
finess out of later versions of perl five that allow subroutines to return l-values,
although doing so requires an explicit declare($$) method, which would take its
arguments as barewords and set up the accessing method and add it to the symbol table.
sub Declare($$){
my ($type, $name) = @_;
my $atman; # a universal virtual base class
$Declared::VarRef{$name} = \$atman;
$Declared::VarType{$name} = $type;
eval <;for(;;){sleep print[rand@w]}' /usr/dict/words
RE: the C JIT
> > 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 interpolate. Of course, this means that to use the value of a bareword variable in a regex, you'd have to do something like: int x = 3 ; ... # Do stuff with x, or not. my int $y = x ; s/$y/5/ ; Which seems like a roundabout way to do it. I still find this whole idea confusing, though. Just out of curiosity, though, would: #include a way for users to bail out gracefully be a syntax error? And how about: int length = 256 ; and, if that's legal, what does: print "I wonder what this is : " . length ; do? Dirk
Re: the C JIT
"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 and I will have to agree to disagree on this point. -Nate
Re: the C JIT
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 have no trouble with it at all. the scalar
of the perl typeglob named "spot" is a "Dog" type, bareword "x"
is a C int type, the scalar of the perl typeglob named "y" is a "int"
type (which may or may not be the same as the C int type, to be determined
one way or the other, as yet unknown), all the types in the standard C
include file sys/types.h have been defined in the current package,
the bareword "name" is a C pointer which is going to be expected to refer
to char, AKA raw, bytes, a line starting "#do " does not match any known
C preprocessor commands and is therefore a perl comment, and
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
To test if x is five or not, something like this would be in order:
if( x == 5){ ...// slack
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=<>;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: the C JIT
> 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 mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by kasey.umkc.
Received:
from udcsd.West.Sun.COM ([129.153.51.1]) by mercury.Sun.COM
> > Nathan Wiger wrote:
> >
> > Well, unfortunately I think you're doomed to fail then. You're forcing
> > constraints on yourself that Perl cannot fulfill, and which I can't see
> > Larry approving.
>
> Lots and lots of human languages, like, all of them, allow WORD WORD to mean
> vastly different things depending on what the words are.
[snip]
> This is completely transparent to human beings, who are very good at it.
[snip]
> I think we're ready for computers that can figure out what language the user is
> trying to talk to them in, in fact according to my Secret Heinlein Society Diagram
> Of The Future (copyright 1952) we're somewhat behind schedule.
Having done my UG thesis on artificial intelligence and natural language
parsing I can tell you one reason why it's taken so long: It's hard.
Serial programs and parallel neural networks are two separate entities.
The most successful language parsers are massively parallel processing
machines, but they still suck by human standards. PDP (parallel
distributed processing) was a great step forward, but there's a long way
to go until we have Star Trek computers asking us how our day is.
My argument is not "This is too hard", though. My argument is that Perl
has to have a somewhat coherent syntax for it to be usable. English and
Japanese are great languages, but they also take 15 - 20 years to
achieve fluency in. This type of investment of time in a programming
language is not realistic.
Anyways, embedding C in Perl is neat idea. But I think if you want to do
it successfully, you'll have to make it stand out.
CBLOCK {
/* Can embed C inside of CBLOCK blocks */
#include
int x;
char * name;
}
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
Re: the C JIT
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 (mercury.Sun.COM [192.9.25.1]) by
kasey.umkc.
(8.9.0/8.9.2) with ESMTP id BAA31743 for ... Wed, 6
Sep 2000 01:36:51 -0500 (CDT)
Received:
from udcsd.West.Sun.COM ([129.153.51.1]) by mercury.Sun.COM
(8.9.3+Sun/8.9.3) with ESMTP id OAA27600; Fri, 1 Sep 2000
14:52
Nathan Wiger wrote:
>
> "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 fulfill, and which I can't see
> Larry approving.
>
> I really don't want to argue about this trivial point anymore. my($.02)
> is that your ideas are great, but if you want any realistic chance of
> getting them into Perl 6, then you have to make the syntax look like
> Perl.
>
> -Nate
Lots and lots of human languages, like, all of them, allow WORD WORD to mean
vastly different things depending on what the words are.
I believe that "tagging" theory from natural language parsing would allow
barewords to mean all kinds of different things.
$r = new CGI;
and
account_t student;
are, even without semantic tags, different instances of WORD WORD. The first
is part of a larger expression, the second is a complete WORD WORD expression.
With the introduction of semantic tags, our language knows that C is
a defined type, so it doesn't go looking for an C method in the C
package.
I imagine that defined types would hide methods, although more complex ambiguity
resolution schemes could certainly be created. I do not see the collision of
WORD WORD as the problem you do.
As a human being, when I am told something that does not make sense in the idiom I
have been using, I will switch idioms before giving up on finding meaning for it.
This is completely transparent to human beings, who are very good at it. If you have
ever spent any amount of time among people who are comfortably polylingual, which sadly
is a rare treat for Americans, you will notice that they will switch between languages
in the course of a conversation. When I was an exchange student in a country where
two non-english languages were spoken, I had to keep reminding my friends to stick to
the language that I partially knew instead of lapsing into the language that I did not
understand at all.
So that's my linguistical argument for allowing multiple syntaxes into perl (2PI - 2),
humans don't have any trouble context switching when they know two languages, why not
make a computer language that can do that trick? Give it python it will recognize it
(if it has had that capability installed into it) and the same with C or Fortran or
anything, the same as a person who knows English, Spanish and Tagalog will not be
confused by a sentence of good Tagalog in the middle of a conversation which is mostly
« en español ».
I think we're ready for computers that can figure out what language the user is
trying to talk to them in, in fact according to my Secret Heinlein Society Diagram
Of The Future (copyright 1952) we're somewhat behind schedule.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=<>;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: the C JIT
"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 fulfill, and which I can't see Larry approving. I really don't want to argue about this trivial point anymore. my($.02) is that your ideas are great, but if you want any realistic chance of getting them into Perl 6, then you have to make the syntax look like Perl. -Nate
Re: the C JIT
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 well. I can't see
>
>dog spot;
>
> Ever getting into Perl realistically. For one thing, that already has
> strong meaning as:
>
>spot->dog;
>
> Because of the truly wonderful indirect object syntax.
No, that would be
dog $spot;
unless I am misunderstanding what
spot->dog; # is supposed to mean to you.
###
typedef struct{
char name[40];
char breed[50];
dog_info_t info;
}dog; # a dog is a type of ( 90 + sizeof(dog_info_t) )bytes
my dog $spot; # something like $spot = dog::new;
# $spot represents a *SV somewhere not
# directly tied to program flow
dog malt; # malt is sizeof(dog) bytes reserved in the
# "stack frame" of the current subroutine call,
Having the C types line up with the Perl packages is not automatic, or
we could have C types all scalarize to strings holding themselves, for
access into using "pack" and "unpack" as well as direct accesses using
hash syntax
strcpy(malt.name, "malt"); # this is a perl5 syntax error
# so perl6 could fall back to interpreting
# the expression as C before throwing
# a syntax error exception
%malt{name} = 'malt'; # clearly this is perl
barewords with and without scalar symbol -- the $ is a scalar symbol --
mean as different of things as %malt and $malt do in perl5
You can have your general consensus, I'm not in his army.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Kansas City Perl Mongers will meet Sept. 20th at 7:00 in
Westport Flea Market Bar & Grill http://tipjar.com/kcpm
Re: the C JIT
"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 spot; Ever getting into Perl realistically. For one thing, that already has strong meaning as: spot->dog; Because of the truly wonderful indirect object syntax. > We also gain a way of differentiating between a "Scalar" which refers > to a "type" which is something else and a lot of very late binding, and > a fixed-size object, an implementation detail that rfc 161 does not address. > > These fixed-size "external" objects would not subclass Scalar, and they > could be easily differentiated if they were barewords. From a API point > of view they are crippled scalars. These types of distinctions are very valid, but again I think you're focusing too much on trying to create a whole new syntax to accomodate them. A new keyword or type or attribute is all you need: my int $spot : optimized = 5; var int $spot = 5; my fastint $spot = 5; Your ideas are good, I just think your implementation suggestions are not Perl. -Nate
Re: the C JIT
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 result in faster execution? Do you > think that the "$" slows down Perl? Is it that dropping the "my" would > make "spot" global and thus faster? What are you getting at? No, I imagine that dropping both the my and the $ would make spot a fixed-size stacked lexical, as it does in C. A speed increase would result from the code clarifier being able to resolve references to spot within the current and enclosed blocks as a fixed offset from a known pointer rather than five or six of those. > Again: C doesn't get its speed from its syntax. Supporting C-esque syntax > doesn't make Perl faster. C syntax and Perl syntax are mostly compatible in what is not a syntax error in the other. A lot of code is in C. Including it -- like, #include "somecode.c" has immense potential for re-use value. Supporting C semantics -- fixed offsets from a stack pointer instead of table lookups -- may very well make perl faster. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Kansas City Perl Mongers will meet Sept. 20th at 7:00 in Westport Flea Market Bar & Grill http://tipjar.com/kcpm
Re: the C JIT
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 us here. Who says that 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. I like flexibility. We also gain a way of differentiating between a "Scalar" which refers to a "type" which is something else and a lot of very late binding, and a fixed-size object, an implementation detail that rfc 161 does not address. These fixed-size "external" objects would not subclass Scalar, and they could be easily differentiated if they were barewords. From a API point of view they are crippled scalars. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Kansas City Perl Mongers will meet Sept. 20th at 7:00 in Westport Flea Market Bar & Grill http://tipjar.com/kcpm
Re: the C JIT
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 you think that the "$" slows down Perl? Is it that dropping the "my" would make "spot" global and thus faster? What are you getting at? Again: C doesn't get its speed from its syntax. Supporting C-esque syntax doesn't make Perl faster. -sam
Re: the C JIT
"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 dog $spot; Already won't micromanage memory through implicit constructors? That's certainly the current idea behind: my int $x = 5;# $x = int->CREATE, $x->STORE(5) This would call an implicit constructor on the 'int' class. The 'int' subclass would optimize things so that $x would get all the computational virtues and all the bondage and discipline of strong typing. More details on this can be found here: http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00137.html http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00105.html http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00152.html -Nate
Re: the C JIT
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 you > might find a way leverage C's efficiency but you won't get it just by > accepting C syntax. > > -sam C gets specificity from its syntax. cc depends on that specificity. Perl does not require specificity, which is good. But when I want to rewrite my Perl program faster, in C, I have to rewrite the whole thing instead of just aggressivley specifying the bottlenex. 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; 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. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Kansas City Perl Mongers will meet Sept. 20th at 7:00 in Westport Flea Market Bar & Grill http://tipjar.com/kcpm
RE: the C JIT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A Perl frontend to GCC would make my life wonderful. Who would I talk to about that? I'm not about to pretend that I have any idea how to do that. - --Dave - -> -Original Message- - -> From: Sam Tregar [mailto:[EMAIL PROTECTED]] - -> 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 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-scalars. - -> - -> > strong typing - -> - -> C's typing is not particularily strong. Witness the common abuse of - -> "(void *)". Witness enums that are all compatible with integers. If we - -> want strong typing (I don't) there are better places to look. - -> - -> > 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 you - -> might find a way leverage C's efficiency but you won't get it just by - -> accepting C syntax. - -> - -> -sam - -> - -> -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOa6IhILSbfyTGCGzEQJtuACghhLs1A0KhX9K6vy/HoAENbS6WvwAnjMy su/kB0y5pB89GKHqwAhusO6j =W7oD -END PGP SIGNATURE-
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 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-scalars. > strong typing C's typing is not particularily strong. Witness the common abuse of "(void *)". Witness enums that are all compatible with integers. If we want strong typing (I don't) there are better places to look. > 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 you might find a way leverage C's efficiency but you won't get it just by accepting C syntax. -sam
Re: the C JIT
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 goals of Perl6. > -- > David Corbin what is and what is not a goal? The danger of getting semantic about what the conversation is about -- arguments over, is it a function, a subroutine, or a method and why, for instance -- is very real. Perl looks, and AFAIK has always looked, like "C plus lune noise" to many people. To adopt that as a listed goal -- yet another extended C -- may not be a new goal but rather a slightly different viewpoint for including several previously stated goals, including: strong typing polymorphism run-time efficiency The ability to parse various input syntaces _is_ on the perl6 agenda, since LW mentioned it in his initial announcement. The idea of a "C to Perl translator" has been kicked around as a funny joke in various forums, such as the FunWithPerl list for one. The "C to Perl Translator" is funny (with current perl) because of these reasons: 1: Efficiencywise, it is backwards. C is speedier and is to be preferred, when you have something that works in C 2: It seems like it would be trivial to accomplish 3: If you already have working C code, why would you want to translate it to Perl rather than just use it as is? One of the more recently stated goals is for perl6 to be fast, fast, fast. If we have a C language front end for it, we will be able to compare its approach with the mature compilers -- we may very well get something that can take you from source-code to running-process faster than `make && make run`. Since C is very well defined and is very similar to perl -- the matching brackets are mostly the same, for instance, and the idea of what can be a variable name is very similar if not identical -- developing C mode might be easier than developing Python mode as an alternate mode for the "different front ends" goal. ... -- David Nicol 816.235.1187 [EMAIL PROTECTED]
Re: the C JIT
"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 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 > one or two differences in operator precedence that exist is another > > (Old precedence semantics unless new-ism like a declared typed bareword > exists in the current or a surrounding block would be the easiest way to do > it I think) > > Typed barewords as an available good syntax would please those who find > perl overpunctuated. > > XS would become a more proper part of the language, the line would blur > as we could mix Perl and C freely with very little performance loss due > to late binding except in things that are not known at "compile time" > things which by definition cannot be clarified without run-time inputs. > > -- > David Nicol 816.235.1187 [EMAIL PROTECTED] 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 goals of Perl6. -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
