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 = ;
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 10:48 AM + 2/13/02, Dave Mitchell wrote: >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)? Yup. >If so, how does $plain know how to "morph itself into the RHS's type"? The general rule is: If a PMC is not a fixed type, it tosses its contents and becomes whatever's assigned to it. If it is a fixed type, it extracts what it can as best it can from the source and uses that. In this case, $plain is a boring old scalar, so it becomes a Complex. If, later on, you assigned a string to it, it'd become a boring scalar with a string component. On the other hand, $c is a Complex, and you can't assign anything that's not a Complex or a subclass of Complex, to it. If you try, the destination gets from the source whatever it can that's useable. (There's a limited stock of things that can be chosen--various ints, floats, or strings) The compiler may also emit typechecking opcodes to pitch a fit when you try an incompatible assignment -- 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
Dan Sugalski <[EMAIL PROTECTED]> wrote: > >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)? > > Yup. > > >If so, how does $plain know how to "morph itself into the RHS's type"? > > The general rule is: If a PMC is not a fixed type, it tosses its > contents and becomes whatever's assigned to it. If it is a fixed > type, it extracts what it can as best it can from the source and uses > that. Thanks. I just want to assert/clarify that the job of "becoming whatever's assigned to it" is delegated to the src PMC, since $plain won't itself know how to do this?
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
RE: Globals
At 3:05 PM +0100 2/13/02, Angel Faus wrote:
>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?
sub a{} is global. my sub a{} is lexical. A function PMC's created in
either case, the only question is where it's stuck.
>* 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..)?
Absolutely. Optimizing away lexicals entirely is an issue for the
optimizer, and there are some potential problems with doing it in
perl (since you can snoop almost anywhere, there are a limited number
of places you can optimize variables away entirely). But other
languages with less introspection can definitely do that without a
problem.
--
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
Dan Sugalski wrote: > >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. The value of the result is actually '3' after reducing, but I'm assuming that a division of a type Complex by a type Complex would assume a result of type Complex, regardless of the actual value. This is why I assumed that the result would be promoted, even if it's not actually necessary. > >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. I have to subscribe to ANOTHER list?!?!? <><> Actually, maybe if I just post it with a note that I'm not subscribed :-). Grant M.
Re: PMCs, setting, and suchlike things
At 03:43 PM 02-13-2002 +, Dave Mitchell you wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > >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)?
> >
> > Yup.
> >
> > >If so, how does $plain know how to "morph itself into the RHS's type"?
> >
> > The general rule is: If a PMC is not a fixed type, it tosses its
> > contents and becomes whatever's assigned to it. If it is a fixed
> > type, it extracts what it can as best it can from the source and uses
> > that.
>
>Thanks.
>I just want to assert/clarify that the job of "becoming whatever's
>assigned to it" is delegated to the src PMC, since $plain won't itself know
>how to do this?
I assumed that the logic for assigning PMC to PMC would be something like:
if (destPMC is specified as typeX) {
if (srcPMC ISA typeX) {
destPMC <- srcPMC
} else {
destPMC <- typeX.convert(srcPMC);
}
} else {
destPMC <- srcPMC
}
in pseudocode form.
If we assume that there is a universal "root" type such that all PMC's are
ISA typeRoot, and that typeX.convert(PMCofTypeY) is trivial if typeY ISA
typeX, then this simplifies to
destPMC <- destPCM.declaredtype.convert(srcPMC);
Why does that look too simple?
RE: PMCs, setting, and suchlike things [forward from p6-internals]
This came up on perl6-internals, and Dan liked the "try" suggestion and
suggested That I post it here for comments. I'm not subscribed to
p6-language, so you'll need to include me in any replies where you want a
response from me.
=
Dave Mitchell <[EMAIL PROTECTED]> 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 (which is actually '3' after reducing) get promoted to Complex,
or does the result from the division get demoted?
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 = ;
my $plain = try_demote( $c / $d );
$plain now ISA Complex if it couldn't demote the result of the math, or it
ISA scalar (int or float) if it could. Now if you need to know, then just
check:
$plain = try_demote( $c / $d );
# the '(or)'s here are alternate forms, not comparison
if( $plain.type == "Complex" (or) $plain.Complex ){
print "It promoted!\n";
}
elsif( $plain.type == "Scalar" (or) $plain.Scalar ) {
print "Result was reduced!\n";
}
Ramblings of a madman,
Grant M.
Re: PMCs, setting, and suchlike things [forward from p6-internals]
"Wizard" <[EMAIL PROTECTED]> writes:
> This came up on perl6-internals, and Dan liked the "try" suggestion and
> suggested That I post it here for comments. I'm not subscribed to
> p6-language, so you'll need to include me in any replies where you want a
> response from me.
> =
> Dave Mitchell <[EMAIL PROTECTED]> 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 (which is actually '3' after reducing) get promoted to Complex,
> or does the result from the division get demoted?
In general I'd say that $plain shouldn't change class (I'm not sure
it's being demoted; after all, a real number has more constraints on
it than a complex number), for the same reason that
Rectangle.new(sides => [1, 1]).isa('Square');
should return false.
>
> 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 = ;
> my $plain = try_demote( $c / $d );
>
> $plain now ISA Complex if it couldn't demote the result of the math, or it
> ISA scalar (int or float) if it could. Now if you need to know, then just
> check:
>
> $plain = try_demote( $c / $d );
> # the '(or)'s here are alternate forms, not comparison
> if( $plain.type == "Complex" (or) $plain.Complex ){
>print "It promoted!\n";
> }
> elsif( $plain.type == "Scalar" (or) $plain.Scalar ) {
>print "Result was reduced!\n";
> }
Demote is a really bad name I think.
$plain = most_appropriate_type($c / $d);
might be better, but it's still ugly.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: PMCs, setting, and suchlike things [forward from p6-internals]
> "W" == Wizard <[EMAIL PROTECTED]> writes:
>> my Complex $c = 3+4i;
>> my $plain = 1.1;
>> $plain = $c;
W> This might be even more "Complex" than that - what if Complex can be
W> reduced? Should it? for instance:
W> my Complex $c = 3+4i;
W> my Complex $d = 4i;
W> my $plain = $c / $d;
W> Does $plain (which is actually '3' after reducing) get promoted to
W> Complex, or does the result from the division get demoted?
wouldn't the new value actually be 3/4i + 1? i think you would need
$c - 4i
to get just a real part out.
W> Perhaps there could be a sort of 'try' for conversion that returns the best
W> possible result? for instance:
W> my Complex $c = 3+4i;
W> my Complex $d = ;
W> my $plain = try_demote( $c / $d );
W> $plain now ISA Complex if it couldn't demote the result of the math, or it
W> ISA scalar (int or float) if it could. Now if you need to know, then just
W> check:
W> $plain = try_demote( $c / $d );
W> # the '(or)'s here are alternate forms, not comparison
W> if( $plain.type == "Complex" (or) $plain.Complex ){
W>print "It promoted!\n";
W> }
or as dan said in internal, if plain is not tagged with any type, it
just gets the complex value. that would be handled by the $plain.Complex
case as all untyped scalars can take any value. but i think a simpler
and faster test of no typing should be in there. another post in
internals had psuedo code with that test
Buddha Buck <[EMAIL PROTECTED]> wrote:
if (destPMC is specified as typeX) {
if (srcPMC ISA typeX) {
destPMC <- srcPMC
} else {
destPMC <- typeX.convert(srcPMC);
}
} else {
destPMC <- srcPMC
}
i take that first if to mean destPMC has any fixed type. else it just
takes on the type of the source.
W> elsif( $plain.type == "Scalar" (or) $plain.Scalar ) {
W>print "Result was reduced!\n";
W> }
plain scalars should handle any type. maybe that example should be int
or float? if you assign a complex value to an int/float it should reduce
to the real part of the value and assign that (with int/float conversion
as needed).
if you wanted the imaginary part only you would have to do:
$imag = $complex.imaginary
or would this be possible?
my $imag is imaginary ; # not complex!
$imag = $complex ;
that would cause the imaginary method/extraction to be called on
$complex and the scalar int/float would be assigned to $imag. $imag
could also have an int/float property which would further reduce the
value.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: PMCs, setting, and suchlike things
At 11:12 AM -0500 2/13/02, Buddha Buck wrote:
>At 03:43 PM 02-13-2002 +, Dave Mitchell you wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> >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)?
>>>
>>> Yup.
>>>
>>> >If so, how does $plain know how to "morph itself into the RHS's type"?
>>>
>>> The general rule is: If a PMC is not a fixed type, it tosses its
>>> contents and becomes whatever's assigned to it. If it is a fixed
>>> type, it extracts what it can as best it can from the source and uses
>>> that.
>>
>>Thanks.
>>I just want to assert/clarify that the job of "becoming whatever's
>>assigned to it" is delegated to the src PMC, since $plain won't itself know
>>how to do this?
>
>I assumed that the logic for assigning PMC to PMC would be something like:
>
>if (destPMC is specified as typeX) {
>if (srcPMC ISA typeX) {
> destPMC <- srcPMC
>} else {
> destPMC <- typeX.convert(srcPMC);
>}
>} else {
> destPMC <- srcPMC
>}
>
>in pseudocode form.
Right, for typed variables. Most variables (i.e. anything you
declared with a plain "my $foo" or "our @bar") are untyped and can
change their types as needed.
If you did:
my $foo;
$foo = Dog.new();
$foo = FireHydrant.new();
$foo would first be a Dog, then a FireHydrant. When it changed to a
FireHydrant the previous contents would get blown away.
>If we assume that there is a universal "root" type such that all
>PMC's are ISA typeRoot, and that typeX.convert(PMCofTypeY) is
>trivial if typeY ISA typeX, then this simplifies to
>
> destPMC <- destPCM.declaredtype.convert(srcPMC);
>
>Why does that look too simple?
Because I don't think we can assume a universal root, at least not
for the engine. For perl, sure, but not for parrot. Besides you hit
combinatorial explosion there pretty fast.
--
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 3:43 PM + 2/13/02, Dave Mitchell wrote: >Dan Sugalski <[EMAIL PROTECTED]> wrote: >> >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)? >> >> Yup. >> >> >If so, how does $plain know how to "morph itself into the RHS's type"? >> >> The general rule is: If a PMC is not a fixed type, it tosses its >> contents and becomes whatever's assigned to it. If it is a fixed >> type, it extracts what it can as best it can from the source and uses >> that. > >Thanks. >I just want to assert/clarify that the job of "becoming whatever's >assigned to it" is delegated to the src PMC, since $plain won't itself know >how to do this? Sort of--delegated to the source PMC's vtable in parts. The sequence goes: Destination PMC calls its own destructor, if it has one Destination PMC calls clone on the source PMC, passing itself in as the PMC to be cloned into. -- 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 [forward from p6-internals]
> my Complex $c = 3+4i;
> my Complex $d = 4i;
> my $plain = $c / $d;
>
> Does $plain (which is actually '3' after reducing) get promoted to
> Complex, or does the result from the division get demoted?
In a related matter, computer languages with Symbolic Mathematics
capabilities, like Mapple, let you explicitly demand where do you want the
operation to take place.
This could be done naturally in perl6 using the colon meta-operator:
my $plain = $c - $d : Math::Reals # 3.0
my $plain = $c - $d : Math::Complex # 3.0 + 0i
As long it is well documented and consistent, it doesn't really matter which
one is the default.
Adding this feature is useful in a wider area of applications:
2 ^ 4 : Math::FiniteField(7) # -> 1
Or even:
sqrt(2 : Math::Integers) # -> exception or not-a-number
sqrt(2 : Math::FiniteField(7)) # -> 3
sqrt(2 : Math::TrueReals) # -> "sqrt(2)"
In general, any mathematical operation should be capable of taking
optionally the structure where the operations is defined, and a whole
universe of fun will open for us mathematicians.. :-)
(Just think of factoring polynomials in F[25][X] over its algebraic
closure... mmm...)
This can be implemented having operations defined as:
sub operator:DIV($a, $b : $structure) {
if $structure and $strcture.can('DIV') {$structure.DIV($a,$b)}
elsif $a.can('DIV') {$a.DIV($a,$b)}
elsif $b.can('DIV') {$c.DIV($a,$b)}
else {..throw exception..}
}
On the other hand, it is (it will be) perfectly possible to do it as an user
module, so this post it's actually a big OT, and you should better forget
it, in case you have been unfortunate enough to read until here...
Oh. Damn.
-angel
RE: PMCs, setting, and suchlike things [forward from p6-internals]
> In a related matter, computer languages with Symbolic Mathematics > capabilities, like Mapple, let you explicitly demand where do > you want the operation to take place. > > This could be done naturally in perl6 using the colon meta-operator: > > my $plain = $c - $d : Math::Complex # 3.0 + 0i > sqrt(2 : Math::Integers) # -> exception or not-a-number Not a bad idea,. I beleive that the perl6 adjective operator (for functions) will be a semicolon, not a colon. I'm not sure how it is planned to apply it to operators. Its also plausable to use properties: my $plain2 is Math::Complex = $c - $d. That would require overloading the '-' operator based on return type; and could get a bit nasty. Dave.
Re: PMCs, setting, and suchlike things [forward from p6-internals]
: 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 (which is actually '3' after reducing) get promoted to Complex, : or does the result from the division get demoted? I wish you guys would quit confusing variables with values. As an unmarked variable, $plain can hold a Complex just as easily as any other type. Now, if you'd said my num $plain = $c / $d; that would be more like the situation you're thinking of. Larry
Re: The Perils of set and PMCs
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Simon Cozens) wrote:
> It's a pretty simple concept. We need to assign one PMC to another.
> We'll have to do it all the time:
>
> $a = $b;
>
> $a and $b are both PMCs, and we need to set the value of one to the
> value of the other, so let's write it as
>
> set P1, P2
>
> Excellent. Until, of course, we have to implement it. We'll implement
> it by calling some vtable method on P1, that much is obvious. But which
> one?
Actually I don't think that it is obvious at all.
I see three cases.
Both $a and $b are untyped ("my $a;"). This is easy, duplicate $b and its
dynamic type (e.g. $b is a reference to a hash, then $a becomes another
reference to that hash; $b holds an int then $a will hold a copy of that
int).
Both $a and $b and typed, with the same type, this is the other easy
case---copy the value again.
However if $a and $b are of difference types (e.g. $a is an int and $b in
untyped, or $a is a string and $b is an reference to an array of snafu).
There could be two ways of writing this: $a does the conversion (has a
"set_from_" method), or $b does it (has a "get_as_" method). Given
dynamic loading and adding extra types, the types may not know about each
other when those types were implemented.
In the worst case, types created independently without any knowledge of
the other we can only do something like "stringise and unstringise" or
raise a "don't know how to convert error" (quite possibly at compile
time).
If one type knows about the other then it should be possible to ask it to
do the conversion (and some sort of arbitrary "assignee's conversion wins"
in case of both ways possible). Thus given:
my snafu $a = Something();
my foobar $b;
$b = $a;
the compiler tries:
does foobar have a set P1, P2, "snafu" method?
yes -> use it
does snafu have a get_as "foobar" method?
yes -> use it
else see above (go via some intermediate type or error)
The trick is likely to be balancing complex rules about conversions (look
at C++98 for an example of how complex this can be and what to avoid)
while DWIM to a sufficient degree (for some definition of sufficient).
The point of this messaging really being, that we need to allow
types/classes to define how they convert to other types and since this is
not known at the time of creation of the other type (let alone Perl6) we
need a certain degree of "see what the types will do".
Richard
--
[EMAIL PROTECTED]
RE: PMCs, setting, and suchlike things [forward from p6-internals]
>> my $plain = $c - $d : Math::Complex # 3.0 + 0i >> sqrt(2 : Math::Integers) # -> exception or not-a-number >Not a bad idea,. I beleive that the perl6 adjective operator >(for functions) will be a semicolon, not a colon. I'm not >sure how it is planned to apply it to operators. > >Its also plausable to use properties: > >my $plain2 is Math::Complex = $c - $d. > >That would require overloading the '-' operator based on >return type; and could get a bit nasty. > The nice thing about being per-operation (or per-function) is that in some cases, the place where you want to define the operation is not alone defined by the operands. Is more like a kind of enviroment where things happen. While most cases can be handled with a rich type system, others do need explicit information about the structure where the operation is defined (although, to be honest, they are probably the lesser). [The example I've got in mind is factoring a polynomal, where the type of the object (Polynomal of real parameters) doesn't determine the place where you factor it (over Q, R, a finite extension, ...? ) ] A second one (probably more important) is that with adverbs you can use both classes (Math::Complex) and instance objects ( Math::FiniteFields::F(8) ) as long as they have the right set of methods. I don't know if you can say : my $plain2 is $structureObject = $c - $d; do you? This allows structures to be user-constructed objects if needed (and only if needed), and thus in theory (probably only in theory) you could even define an algebra of structures. And finally, I find some syntatic pleasure in: print [0,2,3] * [1,3,4] : $myEuclidianSpace; -angel who must have taken the rant pill today...
Re: cvs commit: parrot/types bignum.c bignum.h bignum_test.pl
> continue to pass. Also a shed load of comments. Thats something we could definitely use more of. -Melvin
[PATCH] Fix calculation of byte code end
The type changes in struct Packfile break the pointer math used in a few places
to calculate the address of the end of the loaded byte code. This causes
segfaults in build_asm in jit.c when using -j. It also breaks the bounds
checking on opcode address in runops_slow_core.
The patch adds the necessary cast to correct the code_end calculations.
--
Jason
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.68
diff -u -r1.68 interpreter.c
--- interpreter.c 5 Feb 2002 09:20:07 - 1.68
+++ interpreter.c 14 Feb 2002 03:24:44 -
@@ -68,7 +68,7 @@
code_start = (opcode_t *)interpreter->code->byte_code;
code_size = interpreter->code->byte_code_size;
-code_end = (opcode_t *)(interpreter->code->byte_code + code_size);
+code_end = (opcode_t *)((char *)interpreter->code->byte_code + code_size);
pc = core(interpreter, pc);
@@ -294,7 +294,7 @@
code_start = (opcode_t *)interpreter->code->byte_code;
code_size = interpreter->code->byte_code_size;
-code_end = (opcode_t *)(interpreter->code->byte_code + code_size);
+code_end = (opcode_t *)((char *)interpreter->code->byte_code + code_size);
jit_code = build_asm(interpreter, pc, code_start, code_end);
#ifdef ALPHA
@@ -345,7 +345,7 @@
code_start = (opcode_t *)interpreter->code->byte_code;
code_size = interpreter->code->byte_code_size;
-code_end = (opcode_t *)(interpreter->code->byte_code + code_size);
+code_end = (opcode_t *)((char *)interpreter->code->byte_code + code_size);
code_start_prederef = pc_prederef;
Index: runops_cores.c
===
RCS file: /home/perlcvs/parrot/runops_cores.c,v
retrieving revision 1.11
diff -u -r1.11 runops_cores.c
--- runops_cores.c 22 Jan 2002 16:57:25 - 1.11
+++ runops_cores.c 14 Feb 2002 03:24:44 -
@@ -49,7 +49,7 @@
code_start = (opcode_t *)interpreter->code->byte_code;
code_size = interpreter->code->byte_code_size;
-code_end = (opcode_t *)(interpreter->code->byte_code + code_size);
+code_end = (opcode_t *)((char *)interpreter->code->byte_code + code_size);
if (interpreter->flags & PARROT_TRACE_FLAG) {
trace_op(interpreter, code_start, code_end, pc);
Re: [PATCH] Fix calculation of byte code end
At 10:43 PM -0500 2/13/02, Jason Gloudon wrote: >The type changes in struct Packfile break the pointer math used in a >few places >to calculate the address of the end of the loaded byte code. This causes >segfaults in build_asm in jit.c when using -j. It also breaks the bounds >checking on opcode address in runops_slow_core. > >The patch adds the necessary cast to correct the code_end calculations. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
