From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
[...]
> Well, I think that's all I have to say on the subject. Now
> I'd like to hear from you. Do this all make sense? Is it
> useful? Is it worth for Perl 6? Is it too clumsy? Are there
> things I didn't mention here?
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.
> I'm expecting valuable feedback on this.
It was a mighty long read...
> Internal Design of Tie & Overload
> ---------------------------------
[...]
> What's so bad about tying in Perl 5? I guess it's the fact
> that it's a special case, instead of the general case.
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
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.
I'm not sure I get your distinction between overloading
variable vs. value semantics. 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
> $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.
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
> 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?
> 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?
> 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.
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.
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...
> 3. Code references
>
> The vtable for code references would actually have a method for
> evaluating the code, passing some parameters (a list of values) and
> returning some of them. It's necessary to add a mechanism
> for telling the code in which context (scalar, list, void)
> it's being called.
>
> Here would be an appropriate place to put methods to inspect
> what a code do. For example, there could be an interface to
> access the actual bytecode produced by a method. Afterall,
> that's what the interpreter needs to run a piece of code.
Don't forget the code prototype/signature, and the
implications of supporting multiple dispatch based on that signature.
