takers wanted - a perl job

2 views
Skip to first unread message

Leopold Toetsch

unread,
Jun 24, 2005, 2:21:25 AM6/24/05
to Perl 6 Internals
The PMC compiler[1] needs some improvements: method inheritance.

We have e.g. classes/float.pmc with a bunch of methods:

METHOD PMC* cos() {
...

The PMC compiler creates code [2] so that these methods are installed
into the "Float" namespace at class_init time.

But all these methods should be available for Integer too, so that

.local pmc x, y
x = new Integer
x = 1
y = cos x

does the right thing.

The plan is to move these methods to classes/scalar.pmc, which is a
common ancestor of Float and Integer. But moving e.g. the "cos" function
into scalar.pmc makes it just being ignored. Thus the PMC compiler
should emit code so that functions defined with METHOD are inherited
exactly like plain vtable functions. The class_init code should have an
enter_nci_method with the appropriate namespace of the class.

Thanks,
leo

[1] build_tools/pmc2c.pl, lib/Parrot/Pmc2c.pm
[2] classes/float.c:..class_init enter_nci_method ..
see also the created *.dump files

Joshua Juran

unread,
Jun 24, 2005, 8:41:25 AM6/24/05
to Perl 6 Internals
On Jun 24, 2005, at 8:07 AM, Chip Salzenberg wrote:

> On Fri, Jun 24, 2005 at 08:21:25AM +0200, Leopold Toetsch wrote:
>> The plan is to move these methods to classes/scalar.pmc
>

> Last I remember, I asked for a number.pmc for Integer and Float to
> derive from. A Number isa Scalar. Is there some problem with Number?

Forgive my C++ bias, but why are these methods at all? Shouldn't
mathematical functions be functions? Shouldn't the transcendentals
take floating point values (converting from integers) and others be
overloaded for both types as appropriate?

Having asked the question, here's my answer (which I'm making up and
may not be accurate):

There's not a fixed set of numerical types -- consider bignums and
complex numbers. In C++ you would provide overloaded operators and
functions along with the type declaration, but like Perl 5, Parrot
blurs the distinction between operator and function, and method call
vs. function call, so the effect is the same.

Having read my answer, I'd say that transcendentals (e.g. cos()) belong
to Float-based types and any other types for which it makes sense to
define them. If you just happen to be dealing with an integral number
of radians (probably zero), which just happens to be stored in an
Integer, convert it to a Float first.

Speaking of radians, are there any plans for unit analysis? It would
be helpful to be able to write:

$angle = 60 degrees;
print cos $angle, "\n";
# prints 0.5

Josh

Chip Salzenberg

unread,
Jun 24, 2005, 8:07:52 AM6/24/05
to Leopold Toetsch, Perl 6 Internals
On Fri, Jun 24, 2005 at 08:21:25AM +0200, Leopold Toetsch wrote:
> The plan is to move these methods to classes/scalar.pmc

Last I remember, I asked for a number.pmc for Integer and Float to
derive from. A Number isa Scalar. Is there some problem with Number?

--
Chip Salzenberg <ch...@pobox.com>

Leopold Toetsch

unread,
Jun 24, 2005, 9:29:18 AM6/24/05
to Chip Salzenberg, Perl 6 Internals
Chip Salzenberg wrote:
> On Fri, Jun 24, 2005 at 08:21:25AM +0200, Leopold Toetsch wrote:
>
>>The plan is to move these methods to classes/scalar.pmc
>
>
> Last I remember, I asked for a number.pmc for Integer and Float to
> derive from. A Number isa Scalar. Is there some problem with Number?

I must have missed the Number PMC. Anyway: there are two possibiities:

a) Number is a concrete type then inheritance works out of the box.
b) Number is an abstract type (i.e. number) then the problem still exists.

The former has a vtable, type number, class name. The abstract number
has nothing, it's just used for inheriting vtable functionality.

leo

Leopold Toetsch

unread,
Jun 24, 2005, 9:37:58 AM6/24/05
to Joshua Juran, Perl 6 Internals
Joshua Juran wrote:
>
> On Jun 24, 2005, at 8:07 AM, Chip Salzenberg wrote:
>
>> On Fri, Jun 24, 2005 at 08:21:25AM +0200, Leopold Toetsch wrote:
>>
>>> The plan is to move these methods to classes/scalar.pmc
>>
>>
>> Last I remember, I asked for a number.pmc for Integer and Float to
>> derive from. A Number isa Scalar. Is there some problem with Number?
>
>
> Forgive my C++ bias, but why are these methods at all? Shouldn't
> mathematical functions be functions? Shouldn't the transcendentals take
> floating point values (converting from integers) and others be
> overloaded for both types as appropriate?

Well, at the surface these are opcodes like:

cos Px, Py

OTOH you can use it as a method too:

Px = Py."cos"()

or as a class method:

cl = getclass "Float"
Px = cl."cos"(Py)

> There's not a fixed set of numerical types -- consider bignums and
> complex numbers.

Sure. And therfore Complex.cos() is a different thingy, when implemented.

> ... If you just happen to be dealing with an integral number

> of radians (probably zero), which just happens to be stored in an
> Integer, convert it to a Float first.

Yes. But the problem is locating the cos() function. It's just a matter
of putting Float.cos() into the "Integer" namespace too.

> Speaking of radians, are there any plans for unit anaysis? It would be

> helpful to be able to write:
>
> $angle = 60 degrees;

That's something for fancy HLL modules.

> Josh

eo

Bob Rogers

unread,
Jun 24, 2005, 11:02:11 PM6/24/05
to Leopold Toetsch, Chip Salzenberg, Perl 6 Internals
From: Leopold Toetsch <l...@toetsch.at>
Date: Fri, 24 Jun 2005 15:29:18 +0200

Chip Salzenberg wrote:
> On Fri, Jun 24, 2005 at 08:21:25AM +0200, Leopold Toetsch wrote:
>
>>The plan is to move these methods to classes/scalar.pmc
>
> Last I remember, I asked for a number.pmc for Integer and Float to
> derive from. A Number isa Scalar. Is there some problem with Number?

I must have missed the Number PMC. Anyway: there are two possibiities:

a) Number is a concrete type then inheritance works out of the box.
b) Number is an abstract type (i.e. number) then the problem still exists.

Since Complex could also be considered a Number, but of a very different
sort, it might be worth constructing the type hierarchy to reflect this:

Scalar
Number
Real
Integer
Float
Complex

In this view, Number is necessarily abstract. I imagine Python also
does something like this?

The former has a vtable, type number, class name. The abstract number
has nothing, it's just used for inheriting vtable functionality.

leo

And methods?

-- Bob Rogers
http://rgrjr.dyndns.org/

Joshua Juran

unread,
Jun 25, 2005, 1:05:35 AM6/25/05
to Perl 6 Internals
On Jun 24, 2005, at 11:02 PM, Bob Rogers wrote:

> Since Complex could also be considered a Number, but of a very
> different
> sort, it might be worth constructing the type hierarchy to reflect
> this:
>
> Scalar
> Number
> Real
> Integer
> Float
> Complex

This is inaccurate. All integers are reals (in fact, all integers are
rationals and all rationals are reals), but floats are not all
integers. Factorial should be defined for integers but not floats.

Also, all reals are complex numbers (with a zero imaginary component).
Here's my suggested hierarchy with abstract types in lowercase and
instantiable types capitalized:

scalar
number (possibly complex)
real
rational
integer
Integer
BigInt
Ratio
Float
Complex
Quaternion
String
...

Also, what about non-scalar numbers such as vectors and matrices? Will
we have operators for dot-product and cross-product? Or is this
another HLL issue?

Josh

Bob Rogers

unread,
Jun 25, 2005, 10:20:54 AM6/25/05
to Joshua Juran, Perl 6 Internals
From: Joshua Juran <jju...@gmail.com>
Date: Sat, 25 Jun 2005 01:05:35 -0400

On Jun 24, 2005, at 11:02 PM, Bob Rogers wrote:

> Since Complex could also be considered a Number, but of a very
> different
> sort, it might be worth constructing the type hierarchy to reflect
> this:
>
> Scalar
> Number
> Real
> Integer
> Float
> Complex

This is inaccurate. All integers are reals (in fact, all integers are
rationals and all rationals are reals), but floats are not all
integers. Factorial should be defined for integers but not floats.

That's pretty much what I thought I had said. But I notice that the
indentation on Float used a tab, but not on Integer, so I'll bet your
mail client displayed them differently. (I've converted them all to
spaces above.)

Also, all reals are complex numbers (with a zero imaginary component).

That is mathematically accurate, but inconvenient to implement [1].

Here's my suggested hierarchy with abstract types in lowercase and
instantiable types capitalized:

scalar
number (possibly complex)
real
rational
integer
Integer
BigInt
Ratio
Float
Complex
Quaternion
String
...

Except for Quaternion, this is very close to the Common Lisp type
hierarchy for "number" [1], which was the inspiration for my proposal.
I had left out rational and Ratio because I don't think any of the
Parrot core languages require them, but it would make life easier down
the road if "rational" were included in the core type hierarchy.

FWIW, the main difference is that CL also subdivides Complex into
(complex float) and (complex rational), but that is best left to a
Lisp-specific subclass in any case.

Also, what about non-scalar numbers such as vectors and matrices? Will
we have operators for dot-product and cross-product? Or is this
another HLL issue?

Josh

I think it's an HLL thing; it seems like a big piece to implement in
Parrot. Such an implementation might be useful to support perl6
hyperoperators, but IMHO this is better left to generated PIR.

-- Bob

[1] http://www.lispworks.com/documentation/HyperSpec/Body/t_number.htm,
"Notes" at the bottom of the page.

Sam Vilain

unread,
Jun 26, 2005, 4:38:27 AM6/26/05
to Joshua Juran, Perl 6 Internals
Joshua Juran wrote:
> scalar
> number (possibly complex)
> real
> rational
> integer
> Integer
> BigInt
> Ratio
> Float
> Complex
> Quaternion
> String
> ...

Trying to fit every problem into a rigid inheritance tree is perhaps the
failure of the strict Class-based Object Oriented paradigm; that is, if
you count multiple inheritance and interfaces as afterthoughts rather
than the intent of Class-based Inheritance.

With reference to this Venn diagram:

http://svn.openfoundry.org/pugs/ext/Perl-MetaModel/docs/number-types.png

Here are the corresponding Rule descriptions; structure stolen from Haskell;

role Num;
role Real does Num;
role Fractional does Num;
role Integral does Real;
class Int does Integral;
class int does Integral; # unboxed...
role RealFrac does Real does Fractional;
class Rational does RealFrac;
class IntRatio does RealFrac;
role Floating does Fractional;
role RealFrac does Floating;
role RealFloat does RealFrac does Floating;
class Float does RealFloat;
class Double does RealFloat;
class ComplexFloat does Floating;
class ComplexDouble does Floating;

I would suggest this as a good starting point. One thing that Haskell
is good at is math.

Sam.

m...@gwu.edu

unread,
Jun 29, 2005, 12:26:31 AM6/29/05
to
As a thought, one can also start with groups, rings and fields.
Inheritance is automatic: a field is a ring is a group. Most of your
better math functions have power series expansions. All you would have
to do is define the basic operations +-/* for a specific instantiation
of the structure. 0 and 1 are predefined in rings and fields, 1 or 0,
depending, in groups. A mechanism for field extensions gives you the
complex numbers, and stranger things for free. You could pre-define
many base fields, reals, Z mod p, etc. That could all be hidden in
+-/*.

Obviously there are many syntactic and logical issues. Lots of stuff
could be pre-defined, like your floats and ints, for regular users.

Mike

Reply all
Reply to author
Forward
0 new messages