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]

Reply via email to