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/floa
Dan Sugalski wrote:
> 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 vari
On Thu, 31 Aug 2000, Jarkko Hietaniemi wrote:
> How about
>
> to_string *
> from_string *
>
> as generalizations of formatted/pretty input/output and freeze/thaw
> (cf printf/Data::Dumper/Storable)?
Erm, I could see that, but freezing and printing are still different
operations, so I'm not sur
> "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 inter
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
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> Ken Fox wrote:
>> . The real problems of exception handling, closures, dynamic
>> scoping, etc. are just not possible to solve using simple C code.
>>
>> - Ken
DLN> I'm not talking about translating perl to C code, I'm ta
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,
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
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
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 whate
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 suc
At 04:05 PM 8/31/00 -0500, Jarkko Hietaniemi wrote:
>I'm confused (I might have missed some discussions, being busy in other
>fronts) so please bear with my silly questions.
>
> > type
>
>The basic set-in-stone types are...?
int, float, string, ref, hash, array. All of which have multiple lev
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
"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 c
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
> 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 an
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 b
>> 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 painles
I'm confused (I might have missed some discussions, being busy in other
fronts) so please bear with my silly questions.
> type
The basic set-in-stone types are...?
> name
Huh? A name for what? (How does this relate to a 'string'?)
> get_bool
Stored as...? char? int? Boolean or
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]
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 f
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.
type
name
get_bool
get_string *
get_int *
get_float *
get_value
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
[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 a
[cc'd to internals to check a possible performance problem.]
Steven W McDougall wrote:
> > The more interesting case is this:
> >
> > #!/my/path/to/perl
> > sub foo_generator { my $a = shift; sub { print $a++ } }
> > my $foo = foo_generator(1);
> > $foo->();
> > Thread->new($f
Chaim Frenkel wrote:
> You are now biting off quite a bit.
What good is half a transaction? If transactions are to be useful,
they should be fully supported -- including rolling back stuff some
third party module did to its internal variables. (Maybe that's a
little extreme ;)
> I believe that t
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
28 matches
Mail list logo
