2 views

Skip to first unread message

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

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

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

> 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>

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?

> 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

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?

>

> 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

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

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/

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

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

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.

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

> ...

> 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.

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

+-/*.

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

Search

Clear search

Close search

Google apps

Main menu