On a related note, I wonder how all this fits in with
methods and multimethods?
If we consider the current trig.ops as being equivalent
to, e.g. (expressed with approximate Perl 6 isms):
multi sub sin(Num $arg) : returns Num;
multi sub cos(Num $arg) : returns Num;
<ASIDE>
And, at some level I do think some of the more primitive
Perl 6 builtins should be expressed in a Perl syntax that
indicates "this is an op, go to it!" (like I implemented
in Jako. For example, the file 'string.jako' has guts
that look like this:
module string
{
sub concat :op (str dest, str s);
sub int index :op (str input, str pattern, int start);
sub int length :op (str dest);
sub str substr :op (str s, int i, int l);
}
(if
the sub name != the op name, then you can use :op='foo')
This ends up corresponding nicely to related syntax for
NCI. For example, here is Curses.jako:
module Curses
:fnlib = "libcurses.so"
{
sub int initscr :fn ();
sub int endwin :fn ();
sub int curs_set :fn (int x);
sub int addstr :fn (str s);
sub int refresh :fn ();
sub int move :fn (int x, int y);
sub int getch :fn ();
sub int box :fn (int screen, int v, int h);
sub int hline :fn (int ch, int n);
}
(if
the func name != the sub name, then you can use :fn='bar')
</ASIDE>
Now, along comes the Perl6Scalar PMC, which implements
multi sub sin(Perl6Scalar $arg) : returns Perl6Scalar;
multi sub cos(Perl6Scalar $arg) : returns Perl6Scalar;
In short, it would be nice if
PMC == Class with opaque implementation
(in our case its a C implementation, but I suppose as
soon as someone implements a class in Python and another
person uses it in Perl, its opaque in Perl). Hmm...
"Opaque" smells kind of like "closed", although maybe not
exactly.
Now, along comes some new class that doesn't implement its
own sin(), etc. What should happen? Well, if it is known to
be convertible without loss of information to something that
does have sin(), etc. then things should just work. If they
don't work fast enough, then someone can go to the trouble
to implement the appropriat multi sub in C. As long as we
never implicitly apply a lossy conversion, things should work
fine.
The deeper into the internals we can carry off the similarity
while still being Fast as All Get Out (TM), the better.
Regards,
-- Gregor
On Mon, 2003-09-22 at 15:08, Luke Palmer wrote:
> Brent Dax writes:
> > Dan Sugalski:
> > # Okay, since it seems reasonable to hang the trig functions off of
> > PMCs,
> > # we'd best get a list of the functions we want. I can think of:
> > #
> > # pow
> > # logarithm
> > # square root (yes, I know, it's for speed)
> > #
> > # Normal and hyperbolic versions of:
> > # sine
> > # cosine
> > # tangent
> > # cotangent
> > # arcsine
> > # arccosine
> > # arctangent
> > # arccotangent
> >
> > Okay, reality check. How often are we going to use acosh? Is it really
> > worth the space in the vtable for that few calls? And why can't we just
> > use find_method?
>
> And let's not forget our handy trig identities. We definitely don't
> need all those vtable. Technically, all we need are sine and arccosine.
> I think putting in cosine, arcsine, and [arc]?tangent would be nice,
> too. Cotangent is easy, and is so infrequently used that it's kind of
> silly to include. And hyperbolics are very infrequently used, and can
> be implemented in terms of exp, which in turn can be implemented in
> terms of pow, but shouldn't.
>
> > Basically, where do you draw the line between a vtable method and a
> > find_method method? Unless the line is "methods that everything should
> > support", I'd say it's been crossed when you add acosh to the vtable.
> > And if that *is* where the line is, don't be surprised when vtables
> > cross the megabyte line.
>
> But that's not even the line. There are a lot of methods in there which
> a lot of classes don't support. Now that we have find_method, it might
> be a good idea to define our critera for vtable functions, and then
> prune the vtable accordingly. Maybe.
>
> > I'm really starting to wonder: why do we have only one type of vtable?
> > Why are Closures, Pointers, and Scratchpads forced to implement acosh,
> > splice, pop, or even get_float? And why are PerlInts forced to
> > implement invoke and can_keyed?
> >
> > Vtable.tbl already divides vtables into sections. I suggest we take
> > this a step further and express these sections in the vtables itself.
> > Sections that a particular object didn't need would be loaded with a
> > default, in which all of the methods would throw an exception.
> >
> > The result would mean that something like:
> > pmc->vtable->add
> >
> > Might become:
> > pmc->vtable->math->add
> >
> > And:
> > pmc->vtable->add_keyed
> >
> > Might become:
> > pmc->vtable->keyed->math->add
> >
> > This would make it easier to implement non-keyed objects, and the extra
> > dereference would be lost in the overhead of dealing with keys and
> > aggregates anyway.
> >
> > Best of all, if a PMC class doesn't need math calls, it can simply put
> > this in its vtable definition, in place of the curlies delimiting the
> > set of math calls:
> >
> > &Parrot_pmc_default_math_vtable
>
> Hmm.
>
> I think that's a pretty good idea. Of course, the indirections cost,
> but we have to give space part of the tradeoff somewhere.
>
> On another, related, but not too related, note...
>
> That is to say,
>
> <rant>
>
> When I went and tried to implement the Infinity pmc, I ran into a lot of
> problems. I just wanted a value that could be put into a perlscalar
> that could act like an infinitely large (or small) integer. I ended up
> copying tons of code from PerlInt, etc. just to get the polymorphism to
> work (for some reason putting it all up into perlscalar died big-time).
>
> As far as the var/value split, we need something to support that.
> 'fetch' and 'store' would be really nice, as sort-of unkeyed variants of
> get_pmc_keyed. If something like this already exists, some ops to
> actually manipulate it would be nice. Then one could implement Infinity
> (or even PerlNum) as a non-polymorphic object, and let PerlScalar handle
> the polymorphism. Which, as far as adding new typed, I think would be a
> Very Good Thing.
>
> </rant>
>
> Luke
>
> > --Brent Dax <[EMAIL PROTECTED]>
> > Perl and Parrot hacker
> >
> > "Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
> > set myself on fire to prove it."
> >
--
Gregor Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
