Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:05 PM 12/12/00 +, David Mitchell wrote:
> >Also, some of the standard perumations would also need to do some
> >re-invoking, eg
> >($int - $num) would invoke Int->sub[NUM](sv1,sv2,0), which itself would
> >just fall
> >through to Num->sub[INT](
At 06:05 PM 12/12/00 +, David Mitchell wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > > If we assume that ints and nums are perl builtins, and that some people
> > > have implemented the following external types: byte (
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> That is a Language and not an internals issue - Larry will tell us.
> But I suspect the answer is that it should "work" without any special
> stuff for simple perl5-ish types - because you need to be able to
> translate 98% of 98% of perl5 programs.
On Thu, Nov 30, 2000 at 06:43:35PM +, David Mitchell wrote:
> * do values ever get demoted - eg an expression inolving bigints that evaluates
> to 0: should this be returned as an int or a bigint?
[I may have mailed this already]
Experimentation on perl5 says yes.
Making the sv_setuv actuall
On Tue, Dec 12, 2000 at 06:05:30PM +, David Mitchell wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > > If we assume that ints and nums are perl builtins, and that some people
> > > have implemented the following externa
David Mitchell <[EMAIL PROTECTED]> writes:
>
>I think this this boils down to 2 important questions, and I'd be interested in
>hearing people's opinions of them.
>
>1. Does the Perl 6 language require some explicit syntax and/or semnatics to
>handle multiple and user-defined numeric types?
>Eg "my
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > If we assume that ints and nums are perl builtins, and that some people
> > have implemented the following external types: byte (eg as implemented
> > as a specialised array type), bigre
On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> If we assume that ints and nums are perl builtins, and that some people
> have implemented the following external types: byte (eg as implemented
> as a specialised array type), bigreal, complex, bigcomplex, bigrat,
> quaternian; the
On Thu, 07 Dec 2000, Dan Sugalski <[EMAIL PROTECTED]> mused:
> >My original suggestion was that scalar types provide a method that says
> >how 'big' it is (so complex > bigreal > real > int etc),
> >and pp_add(), pp_sub() etc use these values to call the method associated
> >with the biggest oper
At 02:01 PM 12/7/00 +, David Mitchell wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > > All the math is easy if the scalars are of known types. Addition and
> > > > mul
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > > All the math is easy if the scalars are of known types. Addition and
> > > multiplication are easy if only one of the scalars involved i
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > All the math is easy if the scalars are of known types. Addition and
> > multiplication are easy if only one of the scalars involved is of known
> > type. Math with both of unknown type
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Dave M wrote:
> >That was probably me. (Which means it was probsbly a daft proposal,
> >and everyone rightly ignored it ;-)
> >The basic idea was that all numeric SV types must provide methods
> >that extract their vlaue as an integer or float of a size
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> Is all that really necessary? Why not a non-vtbl function that knows how
>> to add numeric types?
DS> Which numeric types? Int? BigInt? Num? BigNum? Complex numbers? One of the
DS> reasons to go with the vtable stuff is to allow for smal
At 11:24 AM 12/1/00 +, David Mitchell wrote:
>and Buddha Buck <[EMAIL PROTECTED]> wrote:
>
> > I seem to remember a suggestion made a long time ago that would have the
> > vtable include methods to convert to the "standard types", so that if the
> > calls were b->vtable->add(b,a) (and both ope
At 03:02 PM 11/30/00 -0500, Buddha Buck wrote:
>At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote:
>>At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>>> > (Moved over to -internals, since it's not really a parser API thing)
>>> >
>>
At 04:05 PM 11/30/00 -0500, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> The "add" op would, in C code, do something like:
> >>
> >> void add() {
> >> P6Scaler *addend;
> >> P6Scaler *adder;
> >>
> >> addend = pop(); adder = pop();
> >> push addend->vtable-
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I would have wanted to limit the vtbl to self manipulation functions.
> Set, get, convert, etc. Cross object operations would/should be
> outside the realm of the object. (It seems like trying to lift yourself
> by the bootstraps.)
There is a certainly
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> The "add" op would, in C code, do something like:
>>
>> void add() {
>> P6Scaler *addend;
>> P6Scaler *adder;
>>
>> addend = pop(); adder = pop();
>> push addend->vtable->add(addend, adder);
>> }
>>
>> it would be up to the addend->vta
At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote:
>At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>> > (Moved over to -internals, since it's not really a parser API thing)
>> >
>> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wro
At 01:51 PM 11/30/00 -0500, Buddha Buck wrote:
>At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>
>(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>
>>$a=1; $b =3; $c = $a + $b
>>
>>
>> > If they don't exist already, th
At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
> > (Moved over to -internals, since it's not really a parser API thing)
> >
> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >Presumably. But why are you then still talkin
At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>$a=1; $b =3; $c = $a + $b
>
>
> > If they don't exist already, then something like:
> >
> > newscalar a, n
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> It looks to me like add needs to be polymorphic and work out the best
> compromise for the type of scalar to create based on the integer/num/
> complex/oddball types of its two operands.
>
> [Oh. but I'm blinkered in this because I'm attempting to make
On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
> (Moved over to -internals, since it's not really a parser API thing)
>
> At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> >Presumably. But why are you then still talking about "the IV slot in
> >a scalar"...? I'm slow today.
(Moved over to -internals, since it's not really a parser API thing)
At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>Presumably. But why are you then still talking about "the IV slot in
>a scalar"...? I'm slow today. Show me how
>
> $a = 1.2; $b = 3; $c = $a + $b;
>
>is going to
26 matches
Mail list logo
