Re: PMCs, setting, and suchlike things
Dan Sugalski [EMAIL PROTECTED] wrote: #2 is what you get with normal assignment. $foo = $bar, for example. $foo's assign vtable method is called with $bar as a parameter. $foo figures out what it should do--if it's a tied variable of some sort it should perform its assign action. (This includes throwing an exception if the assignment isn't valid) Otherwise it should typecheck the RHS and morph itself into the RHS's type. So in the following: my Complex $c = 3+4i; my $plain = 1.1; $plain = $c; I presume that $plain ends up as type Complex (with value 3+4i)? If so, how does $plain know how to morph itself into the RHS's type?
RE: PMCs, setting, and suchlike things
my Complex $c = 3+4i;
my $plain = 1.1;
$plain = $c;
This might be even more Complex than that - what if Complex can be
reduced? Should it? for instance:
my Complex $c = 3+4i;
my Complex $d = 4i;
my $plain = $c / $d;
Does $plain get promoted, or does the result from the division get demoted?
Should parrot bother to even check, or should it just promote automatically
and let the implementation decide? I think promotion would be best and
fastest for all circumstances. Perhaps there could be a sort of 'try' for
conversion that returns the best possible result? for instance:
my Complex $c = 3+4i;
my Complex $d = unknown qty;
my $plain = try_demote( $c / $d );
$plain now ISA Complex if it couldn't demote the result of the math, or it
is an int if it could. Now if you need to know, then just check:
$plain = $c / $d;
# the '(or)'s here are alternate forms, not comparison
if( $plain.ISA == Complex (or) $plain.Complex ){
print It promoted!\n;
}
elsif( $plain.ISA == Scalar (or) $plain.Scalar ) {
print Result was reduced!\n;
}
Ramblings of a madman,
Grant M.
RE: Globals
Dan wrote:
Yep, I've seen their plans. It's less an issue for us, at least as
far as globals are concerned, since we'll be doing that with
lexicals. (Python not having lexicals, after all) Globals are a bit
more interesting, since bytecode-loaded modules can't guarantee
global positions, since there's no way of knowing at runtime what's
been stuffed into the global tables already.
Anyway, doing this with lexicals, which we can know at compile time,
will get us these speed boosts, and has been on the list for ages.
Oh, I see. Just two quick questions:
* will sub definition create globals? I mean, does sub a {} create
a function PMC and store it into the a lexical? or will there be
a separate mechanism for functions?
* Is there any chance that lexicals get mapped to registers, at least
in the cases where the block doesn't use any dynamic features (MY%,
eval, etc..)?
Thanks.
-angel
Re: The Perils of set and PMCs
At 2:55 PM -0500 2/12/02, Clark C . Evans wrote: Abstract This proposal puts forth an extensible mechanism for the adaptation of an object to a context where a specific type, class, interface, or other protocol is expected. I like the proposal, and I think it's dead-on in identifying a number of issues. Most of which we don't have to deal with as such at the lowest levels here (joys of a fixed set of required methods :) but building in a mechanism to deal with them at a higher level would be really useful. It sounds like we need a doesa to mach isa--something that would let us check to see if a class provides a particular named interface, akin to seeing if a variable inherits from some baser class. Java has its interfaces, there's the Conforms To bits from Apple's version of Objective C, Ruby's got mixins Anyone care to take a look around and get a nice and simple list of everyone's requirements if there's more than what Clark's listed? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: PMCs, setting, and suchlike things
At 7:16 AM -0800 2/13/02, Wizard wrote: my Complex $c = 3+4i; my $plain = 1.1; $plain = $c; This might be even more Complex than that - what if Complex can be reduced? Should it? for instance: my Complex $c = 3+4i; my Complex $d = 4i; my $plain = $c / $d; Does $plain get promoted, or does the result from the division get demoted? Since $plain's not a fixed scalar type, it should be whatever the division of $c and $d produces, presumably a complex number. Should parrot bother to even check, or should it just promote automatically and let the implementation decide? I think promotion would be best and fastest for all circumstances. I prefer letting the destination decide, with automatic type changing as the default. Given the potentially large number of variable types that can be created, I can't picture a workable hierarchy that won't be restrictive here. Perhaps there could be a sort of 'try' for conversion that returns the best possible result? That's an interesting idea. I kind of like it--float it past Larry and p6-language and see what happens. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
