Dan Sugalski <dan (AT) sidhe (DOT) orgwrote:
I sync'd up with subversion this afternoon, and I'm finding that a
*lot* of things that used to work for me are now breaking really
badly. Specifically where there used to be sane fallbacks for pretty
much all of the MMD functions now we've got nothing and I'm having to
install a lot of crud I never used to have to.

You are not very verbose about what actually fails, but I presume that
you are speaking of P, which happened to call the mmd
fallback functions in absence of a C<mmdvtregisteroverload.

I assume that we didn't throw away all the default functions on
purpose, since that'd be more than a little foolish.

Well, if this is sane or foolish is probably a matter of taste or usage.
I think that arbitrary objects shouldn't have floating point
mathematical semantics. If your class C<isafloat then you can just
sublass a C<Float>. If it C<isainteger then subclass C<Integer>.

pragma n_operators 1
sub _main @MAIN
$P0 = subclass "Float", "Foo"
$P1 = new "Foo"# [2]
$P2 = new "Foo"
$P1 = 2
$P2 = 40
$P0 = $P1 + $P2
print $P0
print "\n"
typeof $S0, $P0
print $S0
print "\n"
end

Is this stuff
being worked on, or shall I take some time to throw the default code
back into the MMD subsystem?

All the fallback functions where just duplicating code from (mostly)
float.pmc or integer.pmc. All these functions are available in these
PMCs anyway, a lot of common code is in scalar.pmc.

The only thing that still needs work is to always return a PMC of a type
belonging to the type system of the HLL in use. Most of this is done [3],
only some explicit enum_class_* in classes/*.pmc needs replacing by the
equivalent of:

dest = pmc_new(INTERP,
Parrot_get_ctx_HLL_type(INTERP, enum_class_Float));

(this is from Complex.absolute - the abs() of a C<PyComplexC<isa>
C<PyFloatalbeit the C<absolutefunction is only implemented in Parrot
core and not in Python PMCs)

If the class needs some custom behavior, drop an appropriate function
into it's namespace and it works:

namespace ["Foo"]
sub __add
.param pmc l
.param pmc r
print "in add\n"
$P0 = new "Foo"
$P0 = 77
.return($P0)
end

leo

[1]
$ cat mmd1.imc
sub _main @MAIN
$P0 = newclass "Foo"
$I0 = find_type "Foo"

$P0 = new $I0
$P1 = new $I0
$P2 = new $I0
$P0 = $P1 + $P2
end

$ /parrot-0.1.2/parrot mmd1.imc
Can't find method '__get_number' for object 'Foo'

(The backtrace reveals that C<mmd_fallback_add_pmcwas called)

[2]
With a C<.HLLdeclaration numeric types are working too.

[3]
src/hll.c

Dan Sugalski wrote:

Right, so to reduce code duplication you remove stuff that's working so
people have to go reimplement the code. That makes *perfect* sense.

I've announced and summarized all these changes, e.g.
http://xrl.us/gayp on Apr. 8th

And, what is wrong about:

cl = subclass "Float", "MyFloat"

leo

Chip Salzenberg wrote:
Fri, Jun 03, 2005 at 02:50:38PM +0200, Leopold Toetsch wrote:

>>I've announced and summarized all these changes, e.g.
>>http://xrl.us/gayp on Apr. 8th

I didn't realize the implications when that was posted. I think the
native fallbacks are important.

and probably dangerous. Given two array-ish instances of a class
that implements __get_integer (get array size), Parrot would happily
execute:

$P0 = a << b # or other bitwise operations

By just depending on the fact that a missing __get_integer or
__get_number would inhibit the execution of the MMD fallback seems not
to be the best idea to me.

>cl = subclass "Float", "MyFloat"

In particular, I don't like the idea that an empty subclass provides
functionality that ought to have been available already.

++verbose please.

If I want a float-ish class with some customization it seems to be a
logical idea to use a base class (Float) that provides already all
defaults and then override what's different. The same is true for an
Integer based class (which was in fallbacks, when it comes to bitwise
operations).

I still don't see the point that an arbitrary "Foo" class shall have MMD
functions of a Float/Integer mix.

leo

Chip Salzenberg wrote:

I didn't realize the implications when that was posted. I think the
native fallbacks are important.

If we really want these fallbacks, it's rather easy to reestablish the
functionality. Given e.g.

classes/scalar.pmc:add (which Float intherits from)

we have

MMD_DEFAULT: {
yada
exactly the code that was in mmd_default: _add_pmc
}

This installs the MMD funtion add(Float, Any)

With a little change in parsing inside the PMC compiler we could define,
that:

MMD_DEFAULT, MMD_DEFAULT: {}

also defines the LHS of the operation, which we currently can't denote.
This would immediately give an implementation for

add(Any, Any)

without all the code duplication of the vanished mmd_fallback.c, without
any special cased code in the mmd lookup and without more entries in the
mmd_table that would prevent an efficient compression of it.

leo