At 03:22 PM 20/04/2001 -0500, Garrett Goebel wrote:
>I hope our more enlightened subscribers can separate the
>chaff from the wheat. It provoked me to a lot of thought, if
>not enlightenment. Good ideas are in there, I hope they
>aren't ignored in favorite pastime of pointing out mistakes.
Thanks!
>One of the first things that impressed me when I looked at
>Python was the similarity between tying and special methods
>in Python. Python makes it so dang easy to map new meaning to
>built-in syntax. See:
>http://www.python.org/doc/current/ref/specialnames.html
Is it as powerful as Perl's tying/overloading model (when it works)?
I swear to look at it next week.
>If the http://dev.perl.org/rfc/9.pod rfc goes through, then
>the meaning of $ @ % are going to be changing a lot. It'd be
>nice if Perl6 classes could easily map methods where
>appropriate to built-in syntax, and use -> to call whatever
>other methods are provided.
Will look at it with more time next week too.
>I'm not sure I get your distinction between overloading
>variable vs. value semantics.
Well, basically, a variable is tied, and a value is overloaded. A variable
can hold one (or more) overloaded value, independent of the fact of it
being tied or not. (See below on $a = $b)
>Is this a good example?
>
>$foo[1] *= 2; # value dispatch
>@foo *= 2; # variable dispatch which might do an
> # $_ *= 2 value op for each item in @foo
Well, the second isn't actually a valid syntax in Perl 5. I know, this is
not a reason to disconsider it, since it (possibly) will be a valid syntax
in Perl 6.
So the answer is: it will depend on what the second thing will do in Perl 6.
If it does the same as `$_ *= 2 for (@foo)', then there's no need to attach
some magic information on @foo, because it will behave the same way for
every array. The magic will be on the values stored by @foo, since they
will do the `*' operation according to how they're overloaded to do it.
If it's something different, that depends on @foo, one question will have
to be answered to determine how to implement it: wheter @a = @b copies or
not the magic of @b to @a. See below:
> > $a = $b;
> >
> > ??? If I copy the vtable of $b to $a, $a will not be tied
> > anymore. If I don't, the value copied won't carry its
> > overloaded behaviour.
>
>This gets a little murky for me. Scalar as variable vs.
>scalar as value... When you tie something you are overloading
>the scalar as variable. In effect altering the way the
>variable operations are dispatched. $a = $b copies the value
>and not the variable and thus loses $b's possibly overloaded behavior.
The idea is: (I really don't know if I wrote this example before...)
$b is a non-tied variable, i.e., it has the vtable of a non-tied variable.
It holds an overloaded value, for example, a bignumber, that has PLUS,
MINUS, etc., ops that understand the bignumber structure. Thus, the value
of $b has a vtable for a bignumber.
$a, OTOH, is a tied variable, one that writes what is assigned to it to a
file. That means it has a vtable of a tied variable, that is different of
the one of $b. Not that it matters, but consider that $a has a
non-overloaded value, i.e., the vtable of the (current) value of $a is
different of the vtable of the value of $b.
What would happen when $a = $b? Semantically, according to the tying and
overloadings, the bignumber on $b should be written to the file $a is tied
to, and when fetching the value of $a, it should return a bignumber, with
all the overloaded operations that make the bignumber make sense.
But if I have all in one vtable (both the tying and overloading methods), I
wouldn't have how to set the vtable of $a according to the vtable of $b.
For example, if I set the vtable of $a to the vtable of $b, then $a would
ceasse to be tied, since $b's vtable is the one of a non-tied variable.
OTOH, if I don't copy it, and continue to use $a's vtable, when I fetch the
(new) value of $a, it won't be overloaded, since the former value of $a's
vtable doesn't have methods to access a bignumber.
That's why these vtables should be in different PMCs. And that's why I got
to the conclusion that variables and values are (and need to be) different
things.
Did I answer your question?
>package foo;
>use Tie::Scalar;
>@ISA = (Tie::StdScalar);
>sub STORE { ${$_[0]} += $_[1] * 2 }
>
>package main;
>tie $bar, foo;
>$baz = $bar = 1;
>print "$bar\t$baz\n";
>$baz = 1;
>print "$bar\t$baz\n";
>
>results in:
>2 2
>2 1
I'm sorry, but I didn't get it. What did you mean with this code?
> > The thing is: a variable is tied, a value is overloaded.
>
>You mean that Perl allows us to overloading a variable
>without distinguishing where the variable leaves off and its
>value begins. That we need to be able to overload both. Or as
>you say tie the variable, and overload the value. So that in
>some cases:
>
>$a = $b;
>
>Can set either, neither, or both the variable and value
>vtables for $a to match $b?
When you said `Perl allows us to overload...' you meant Perl 5, right?
$a = $b does the following:
Calls FETCH on $b. This returns the value of $b.
Calls STORE on $a, passing the value returned of the FETCH on $b as the
parameter.
After the operation, the vtable of $a hasn't been changed, so if it was
tied before, it will still be tied after the operation. The value $a points
is the same on as $b points, inclusive the vtable, so that the value of $a
will keep the overloading behaviour of the value of $b.
> > The equivalent of an AV should store an array of values rather
> > than variables.
>
>I disagree.
>
>$a = 1;
>@b = ($a);
>$c = $b[0];
>$d *= 2;
>
>Wouldn't you like to preserve the possibility of allowing $d
>get both the variable and value vtables of $a?
(after the patch)
Yes, maybe there's really a need for an array that holds variables and
calls their tied methods when set or get.
But (I think) this can actually be implemented as a tied array, that knows
their elements are variables and sets or gets them instead of plain values.
Yeah, that can surely be done... I'll probably write it sometime later.
> > I tried to identify the objects that exist in Perl 5, to try to
> > find the methods they implement. Well, three obvious things that are
> > objects of Perl 5 are the variables: scalars, arrays and hashes.
>
>I think you missed subroutine prototypes.
Thanks for remembering it. I actually probably missed much more than that.
The point I wanted to make is: everything the Perl language deals with
should be accessible from a low level API, preferrably in a flexible
approach like the one of vtables, that allows low level implementors to
`change' the behaviours of *ALL* Perl user level objects (with objects I
mean variables, values, code, packages, regexes, prototypes, ...).
>I do agree with what I believe is your underlying premise.
>That we should be able to semantically overload the built-in
>syntax of scalars, arrays, hashes, etc.
Yes, as I said before, of practically everything Perl deals with.
>I'm trying to figure out how this fits in with Larry's desire
>to have the grammar be dynamic. Unfortunately it'd take more
>coffee than Dan must make in an average week. Both the syntax
>and semantics being completely modifiable at runtime. That
>sounds nice. Oh what is that just over the horizon? The
>horror... the horror...
Yes. I actually am beginning to figure out a way to allow more levels of
extensibility, like adding new operators, etc. However, the base objects of
Perl (variables, values, code, ...) are actually a fixed set. Changing or
adding to them would (probably) change the whole language and interpreter.
> > 3. Code references
>
>Don't forget the code prototype/signature, and the
>implications of supporting multiple dispatch based on that signature.
I would actually appreciate some help, mostly here and the other places I
haven't included some pseudo-examples. I have not much idea about how this
is done now and how it should be done, I have only the idea that it should
be flexible and extendible in most ways.
Thanks for the feedback,
- Branden
