[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
words about as
Fisher Mark wrote:
The rest of us with our TVs, VCRs, and so on have only compiled
code in our devices.
I'd buy a microwave that resets to 'JAPH' after a power failure.
Maybe. ;)
- Ken
At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
Okay, here's a list of functions I think should go into variable vtables.
Functions marked with a * will take an optional type offset so we can
handle asking for various permutations of the basic type.
Perhaps I'm missing something... Is this for
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]
get_int *
get_float *
Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
Having lately been battling a lot with quad ints and doubles vs long doubles
I seriously want this interface not to suck.
I was a tad concerned there, too. I'm hoping one can painlessly
Dan Sugalski wrote:
get_value
set_value
Wouldn't these go on the SV and not on the inner type? Maybe I'm
thinking value when you're saying variable? The following seem useful
on variables too:
before_get_value
after_get_value
before_set_value
after_set_value
There ought to be
Wouldn't these go on the SV and not on the inner type? Maybe I'm
thinking value when you're saying variable? The following seem useful
on variables too:
before_get_value
after_get_value
before_set_value
after_set_value
There ought to be specializations of get_value and
Jarkko Hietaniemi writes:
I'm not too worried about getting the vtbl right at the first because
it will be pretty obvious how it should go once the code starts to form.
Some planning isn't that painful :-)
Yes. Especially given that vtables are an unbenchmarked change. It'd
be good to
"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
At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
Okay, here's a list of functions I think should go into variable vtables.
Functions marked with a * will take an optional type offset so we can
handle asking for various permutations of the basic type.
At 03:12 PM 8/31/00 -0600, Tom Christiansen wrote:
get_int *
get_float *
Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
Having lately been battling a lot with quad ints and doubles vs long
doubles
I seriously want this interface not to suck.
I was a
At 05:30 PM 8/31/00 -0400, Ken Fox wrote:
Dan Sugalski wrote:
get_value
set_value
Wouldn't these go on the SV and not on the inner type? Maybe I'm
thinking value when you're saying variable?
Nope. The get/set value functions are for when something knows what the SV
(or whatever we
At 03:45 PM 8/31/00 -0600, Nathan Torkington wrote:
Jarkko Hietaniemi writes:
I'm not too worried about getting the vtbl right at the first because
it will be pretty obvious how it should go once the code starts to form.
Some planning isn't that painful :-)
Yes. Especially given that
Dan Sugalski wrote:
Okay, here's a list of functions I think should go into variable vtables.
All the math functions are in here. Can the entries that my type does
not use be replaced with other functions that my type does use?
Functions marked with a * will take an optional type offset
Ken Fox wrote:
. The real problems of exception handling, closures, dynamic
scoping, etc. are just not possible to solve using simple C code.
- Ken
I'm not talking about translating perl to C code, I'm talking about
translating perl to machine language.
C is babytalk compared to Perl,
How about
to_string *
from_string *
as generalizations of formatted/pretty input/output and freeze/thaw
(cf printf/Data::Dumper/Storable)?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
"KF" == Ken Fox [EMAIL PROTECTED] writes:
KF Chaim Frenkel wrote:
You are now biting off quite a bit.
KF What good is half a transaction? If transactions are to be useful,
KF they should be fully supported -- including rolling back stuff some
KF third party module did to its internal
Dan Sugalski wrote:
get_value
set_value
The get/set value functions are for when something knows what the SV (or
whatever we call it) really is and can handle the raw data. For example,
if my code knew a SV held a complex number (which doesn't map well to the
int/float/char
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
19 matches
Mail list logo
