Re: takers wanted - a perl job
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.
takers wanted - a perl job
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
Re: takers wanted - a perl job
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 [EMAIL PROTECTED]
Re: takers wanted - a perl job
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
Re: takers wanted - a perl job
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
Re: takers wanted - a perl job
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
Re: takers wanted - a perl job
From: Leopold Toetsch [EMAIL PROTECTED] 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/
Re: takers wanted - a perl job
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
Re: Takers wanted - a perl job
Robert Spier wrote: Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Hmm. Maybe this should be a commit action and not a test. It was under CVS. I'm pretty sure everyone ignored it there :) Well, it always depends, how responds looks like: Committed revision 1234 * ATT MAINFEST ERROR missing bla.bla ... * That is a little harder to miss. :) In CVS, it was just.. manicheck: Not in MANIFEST: $file manicheck: No such file: $file (Anyway, as said before - if someone writes the script - we'll run it.) -R
Re: Takers wanted - a perl job
Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Hmm. Maybe this should be a commit action and not a test. It was under CVS. I'm pretty sure everyone ignored it there :) -R
Re: Takers wanted - a perl job
On Wed, Apr 13, 2005 at 08:58:19AM -0700, Robert Spier wrote: Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Hmm. Maybe this should be a commit action and not a test. It was under CVS. I'm pretty sure everyone ignored it there :) They wouldn't ignore it if it caused the commit to fail now would they.
Re: Takers wanted - a perl job
Robert Spier wrote: Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Hmm. Maybe this should be a commit action and not a test. It was under CVS. I'm pretty sure everyone ignored it there :) Well, it always depends, how responds looks like: Committed revision 1234 * ATT MAINFEST ERROR missing bla.bla ... * -R leo
Re: Takers wanted - a perl job
On Tue, Apr 12, 2005 at 11:08:30AM +0200, Leopold Toetsch wrote: t/src/manifest.t tests 3 and 4 used to compare MANIFEST file entries against CVS/Entries. The latter is now .svn/entries with an xmlish syntax. The job is now to replace t/src/manifest.t:scan_cvs so that it extracts Cname items from .svn/entries and descends into Ckind=dir subdirectories. And no - I don't think, we need a full-fledged XML parser for this. No need to parse the XML files, svn list -R lists everything in the repo. And I suppose I just volunteered myself for the job.
Re: Takers wanted - a perl job
On Tue, Apr 12, 2005 at 02:50:57AM -0700, Michael G Schwern wrote: No need to parse the XML files, svn list -R lists everything in the repo. And I suppose I just volunteered myself for the job. $ svn list -R svn: '.' is not a working copy Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Nicholas Clark
Re: Takers wanted - a perl job
Leopold Toetsch wrote:
t/src/manifest.t tests 3 and 4 used to compare MANIFEST file entries
against CVS/Entries. The latter is now .svn/entries with an xmlish syntax.
The job is now to replace t/src/manifest.t:scan_cvs so that it extracts
Cname items from .svn/entries and descends into Ckind=dir
subdirectories. And no - I don't think, we need a full-fledged XML
parser for this.
No XML parser? Bummer, it would be sooo much simpler. ;-)
C:\parrot\.svnperl -MXML::Simple -MData::Dumper
-eprint(join \\n\, keys %{XMLin('entries')-{entry}})
encodings
ops
pf
ast
PBC_COMPAT
MANIFEST
...
VERSION
build_tools
README
Ron
Re: Takers wanted - a perl job
On Tue, Apr 12, 2005 at 10:54:14AM +0100, Nicholas Clark wrote: On Tue, Apr 12, 2005 at 02:50:57AM -0700, Michael G Schwern wrote: No need to parse the XML files, svn list -R lists everything in the repo. And I suppose I just volunteered myself for the job. $ svn list -R svn: '.' is not a working copy Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Hmm. Maybe this should be a commit action and not a test.
