On Mon, 22 Sep 2003, Leopold Toetsch wrote:
> We have vtables for "shr"/"shl" but not for "lsr". Is there a specific
> reason that these vtables are not in pdd02?
Mainly because languages generally only define a single left and right
shift operator
> The same is with "pow", though this could
We have vtables for "shr"/"shl" but not for "lsr". Is there a specific
reason that these vtables are not in pdd02?
The same is with "pow", though this could be treated like the
trigonometric ops, which we don't have for PMCs either.
BTW: What about trig ops for PMCs:
sin P1, P0 # no vtable
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> For us, teh equivalent would be returning a PerlInt if we find the
> result produces an integral value, and a PerlNum if it doesn't. (Assuming,
> of course, that the operation took place on two perl-style PMCs, as other
> languages may have different rules
On Tue, 9 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 9 Sep 2003, Leopold Toetsch wrote:
> >
> >> BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me.
> >> I think we need some clarification for the PerlNum implementation.
>
> > That's r
On Tue, Sep 09, 2003 at 08:41:56AM -0400, Dan Sugalski wrote:
> On Tue, 9 Sep 2003, Leopold Toetsch wrote:
> > BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me.
> > I think we need some clarification for the PerlNum implementation.
>
> That's right--perl math always ends up as
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 9 Sep 2003, Leopold Toetsch wrote:
>
>> BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me.
>> I think we need some clarification for the PerlNum implementation.
> That's right--perl math always ends up as floats.
I'm not sure:
On Tue, 9 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> > On Mon, 8 Sep 2003, Leopold Toetsch wrote:
> >>1) should these ops just be implemented or
> >>
> >
> > This one. We can consider pruning out unused variants later, after we've
> > been up and running and have reasonable HLL
Dan Sugalski wrote:
On Mon, 8 Sep 2003, Leopold Toetsch wrote:
1) should these ops just be implemented or
This one. We can consider pruning out unused variants later, after we've
been up and running and have reasonable HLL output to check against.
Ok. Started that.
- neg_p
- new vtables for cmod
Leon Brocard <[EMAIL PROTECTED]> writes:
> [Something! For the first time in ages!]
Hurrah! A summarizer breaths easily!
On Mon, 8 Sep 2003, Leopold Toetsch wrote:
> While playing with YAL (Yet Another Language) I'm discovering a lot of
> asymmetries in ops files:
>
> neg_p is missing (neg_p_p only, but neg_i is there)
> mod_p_p_i, mod_p_p_n are missing (add, sub, ... have these variants)
> keyed assign ops are m
Leopold Toetsch sent the following bits through the ether:
> 1) should these ops just be implemented or
At this point we want to make it really easy to target parrot. I know
it's not hard to work around these exceptions, but I reckon
implementing the complete set of ops for now would be a good id
hould these ops just be implemented or
2) should the assembler work around missing ops
3) should each HLL work around missing ops
leo
12 matches
Mail list logo