On 02/07/01 Edwin Steiner wrote:
> [snip]
>
> I thought about it once more. Maybe I was confused by the *constant* NATIVE.
> Are you suggesting a kind of multiple dispatch (first operand selects
> the vtable, second operand selects the slot in the vtable)?
>
> So
> $dest = $first + $second
>
At 02:33 PM 2/7/2001 -0500, Buddha Buck wrote:
>At 01:14 PM 02-07-2001 -0500, Dan Sugalski wrote:
>>At 01:35 PM 2/7/2001 -0200, Branden wrote:
>>>As far as I know (and I could be _very_ wrong), the primary objectives of
>>>vtables are:
>>>1. Allowing extensible datatypes to be created by extension
Dan Sugalski wrote:
> At 01:35 PM 2/7/2001 -0200, Branden wrote:
> >2. Making the implementation of `tie' and `overload' more efficient
('cause
> >it's very slow in Perl 5).
>
> No, not at all. This isn't really a consideration as such. (The vtable
> functions as desinged are inadequate for most o
At 01:14 PM 02-07-2001 -0500, Dan Sugalski wrote:
>At 01:35 PM 2/7/2001 -0200, Branden wrote:
>>As far as I know (and I could be _very_ wrong), the primary objectives of
>>vtables are:
>>1. Allowing extensible datatypes to be created by extensions and used in
>>Perl.
>
>Secondarily, yes.
>
>>2. Ma
David Mitchell wrote:
> Perl 5 only supports Perl-mode tieing and overloading - ie, where
> the tied or overloaded functions that get called are Perl functions.
> This is slow and heavyweight, but it is easy to code (ie you write
> a Perl module with a few functions).
>
Actually, I think Perl 5 s
Branden wrote:
>
> Well, if it's not tie/overload, I didn't really understand why a vtable
> would have to be attached to a variable. I'd really like to see an example
> of variables whose vtables would have set_* and get_* different one from
> another, and another example of variables whose vtabl
> Dan,
>
> I think there is a real problem with your vtable approach.
[ etc etc ]
I think there's an important misconception about tieing and overloading
going on hre which I will attempt to clear up. (Then Dan and co
can point out that I;'m I;m wrong and have just made matters worsse ;-)
Firs
Dan Sugalski wrote:
>
> >2. Making the implementation of `tie' and `overload' more efficient
('cause
> >it's very slow in Perl 5).
>
> No, not at all. This isn't really a consideration as such. (The vtable
> functions as desinged are inadequate for most overloading, for example)
>
Well, if it's
At 03:45 PM 2/7/2001 -0200, Branden wrote:
>Dan,
>
>I think there is a real problem with your vtable approach. It involves
>tying, overloading and assignment. I'm not sure if I really got what you
>meant with the PDD, but I'm assuming:
>1. PMC's replace SV*.
Yes.
>2. Tying is handled by vtables
At 01:35 PM 2/7/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 05:41 PM 2/6/2001 -0200, Branden wrote:
> > > > >I actually don't see a reason why the vtable entries should be the
> > >opcodes.
> > > > >Is there?
> > > >
> > > > Speed.
> > > >
> > >
> > >Actually, I don't see the problem of
Dan,
I think there is a real problem with your vtable approach. It involves
tying, overloading and assignment. I'm not sure if I really got what you
meant with the PDD, but I'm assuming:
1. PMC's replace SV*.
2. Tying is handled by vtables that implement set_* and get_* entries to do
the magic s
At 11:13 AM 2/7/2001 +0100, Edwin Steiner wrote:
>Dan Sugalski wrote:
>[snip]
> > That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> > the martian death flu, along with too much blood in my caffeine stream) The
> > example
> >
> > $foo{bar} = $baz + $xyzzy[42];
> >
> > tu
Dan Sugalski wrote:
> At 05:41 PM 2/6/2001 -0200, Branden wrote:
> > > >I actually don't see a reason why the vtable entries should be the
> >opcodes.
> > > >Is there?
> > >
> > > Speed.
> > >
> >
> >Actually, I don't see the problem of defining a C function that would do:
> >
> > void add(SVA
Edwin Steiner wrote:
>
> Dan Sugalski wrote:
> [snip]
> > That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> > the martian death flu, along with too much blood in my caffeine stream) The
> > example
> >
> > $foo{bar} = $baz + $xyzzy[42];
> >
> > turns into
> >
> >baz
Dan Sugalski wrote:
[snip]
> That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> the martian death flu, along with too much blood in my caffeine stream) The
> example
>
> $foo{bar} = $baz + $xyzzy[42];
>
> turns into
>
>baz->vtable->add[NATIVE](foo, baz, xyzzy, key)
At 05:41 PM 2/6/2001 -0200, Branden wrote:
>Sorry, I promess it's the last reply for today! Please don't rant on me!
I have not yet begun to rant. :) And I won't start, either. (And you
certainly don't have to stop arguing your point. I don't claim to hold some
sort of divine inspiration on in
Sorry, I promess it's the last reply for today! Please don't rant on me!
Dan Sugalski wrote:
> At 04:23 PM 2/6/2001 -0200, Branden wrote:
> >Dan Sugalski wrote:
> > > Don't forget we have an opcode machine here--we are *not* emitting C
code
> > > to be compiled. That means we're going to be sto
On Tue, Feb 06, 2001 at 04:23:06PM -0200, Branden wrote:
> What's exactly a op dispatch? I _really_ don't know that. Please tell me so
> that I can answer this...
> ...
> I know that (althought I don't have the exact definition of opcode yet).
Oh boy. Look, Dan's been Good Cop, now it's my turn.
Dan Sugalski wrote:
> >In a certain way, overloading is a way to attach magic to a value, in
Perl5.
> >I don't know how it's implemented, but if $a contains an object that has
> >overloaded behaviour, and I do $b = $a, $b will contain a pointer to the
> >same object, with the same overloaded behav
At 04:23 PM 2/6/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 01:50 PM 2/6/2001 -0200, Branden wrote:
> > >In the approach using the vtables I propose, it would be:
> > >
> > >
> > > // get the PMC's that correspond to each variable...
> > > HVAR *foo = get_hvar("foo");
> > > SVAR *ba
At 04:32 PM 2/6/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 02:32 PM 2/6/2001 -0200, Branden wrote:
> > >I noticed I couldn't get it to work. The thing is that $x = ... makes a
> > >sv_setsv, what copies the value of the other SV (ST(0) in this case), but
> > >not its magic, and other s
Dan Sugalski wrote:
> At 02:32 PM 2/6/2001 -0200, Branden wrote:
> >I noticed I couldn't get it to work. The thing is that $x = ... makes a
> >sv_setsv, what copies the value of the other SV (ST(0) in this case), but
> >not its magic, and other stuff. Here is the difference between `variable'
> >a
Dan Sugalski wrote:
> At 01:50 PM 2/6/2001 -0200, Branden wrote:
> >In the approach using the vtables I propose, it would be:
> >
> >
> > // get the PMC's that correspond to each variable...
> > HVAR *foo = get_hvar("foo");
> > SVAR *baz = get_svar("baz");
> > AVAR *xyz = get_avar("xyzzy");
At 02:32 PM 2/6/2001 -0200, Branden wrote:
>I noticed I couldn't get it to work. The thing is that $x = ... makes a
>sv_setsv, what copies the value of the other SV (ST(0) in this case), but
>not its magic, and other stuff. Here is the difference between `variable'
>and `value'. In Perl5, at least
On Tue, Feb 06, 2001 at 02:32:16PM -0200, Branden wrote:
> I noticed I couldn't get it to work. The thing is that $x = ... makes a
> sv_setsv, what copies the value of the other SV (ST(0) in this case), but
> not its magic, and other stuff. Here is the difference between `variable'
> and `value'.
Simon Cozens wrote:
> Well, hmm. That's true and it's not true. Consider how
> $a = $b
> works in Perl 5: the gvsv operations produce two SVs, one for the value of
$a
> and for the value of $b. Then the value of $b is assigned to the value of
$a,
> and $a is changed. No difference between lval
At 01:50 PM 2/6/2001 -0200, Branden wrote:
>Simon Cozens wrote:
> > On Tue, Feb 06, 2001 at 11:30:12AM -0200, Branden wrote:
> > > I actually have some more on it, but I'm saving it for the next
>postings.
> > > I'll wait for your opinions first. I really hope to see critics about
>this.
> >
> > I
Dan Sugalski wrote:
> At 03:53 PM 2/6/2001 +, David Mitchell wrote:
> > > 2. Perl 5 doesn't separate well a `variable' from a `value', and this
> > should
> > > be done to achieve a more clear design.
> >
> >Perl5 does in fact make a clear separation. 'values' are SV structures
> >(and AVs and
On Tue, Feb 06, 2001 at 03:53:09PM +, David Mitchell wrote:
> Perl5 does in fact make a clear separation. 'values' are SV structures
> (and AVs and HVs etc). Variables are names in stashes, PADs etc
> that have a pointer to an SV or whatever.
Well, hmm. That's true and it's not true. Consider
At 03:53 PM 2/6/2001 +, David Mitchell wrote:
> > 2. Perl 5 doesn't separate well a `variable' from a `value', and this
> should
> > be done to achieve a more clear design.
>
>Perl5 does in fact make a clear separation. 'values' are SV structures
>(and AVs and HVs etc). Variables are names in
David Mitchell wrote:
> > 2. Perl 5 doesn't separate well a `variable' from a `value', and this
should
> > be done to achieve a more clear design.
>
> Perl5 does in fact make a clear separation. 'values' are SV structures
> (and AVs and HVs etc). Variables are names in stashes, PADs etc
> that hav
> 2. Perl 5 doesn't separate well a `variable' from a `value', and this should
> be done to achieve a more clear design.
Perl5 does in fact make a clear separation. 'values' are SV structures
(and AVs and HVs etc). Variables are names in stashes, PADs etc
that have a pointer to an SV or whatever.
Simon Cozens wrote:
> On Tue, Feb 06, 2001 at 11:30:12AM -0200, Branden wrote:
> > I actually have some more on it, but I'm saving it for the next
postings.
> > I'll wait for your opinions first. I really hope to see critics about
this.
>
> I don't understand what you think this gives us that the
On Tue, Feb 06, 2001 at 11:30:12AM -0200, Branden wrote:
> I actually have some more on it, but I'm saving it for the next postings.
> I'll wait for your opinions first. I really hope to see critics about this.
I don't understand what you think this gives us that the PDD doesn't.
--
For me, UNI
I have some thoughts on vtables and I actually think they should be pretty
different from what was proposed. Well, I'll tell you my ideas on vtables.
Please note that I'm not doing this as an intent to confront the other
proposal, or to create discordance and divergence. I'm presenting this
becau
35 matches
Mail list logo
