Missing MMD default functions?
Dan Sugalski
*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.
I assume that we didn't throw away all the default functions on
purpose, since that'd be more than a little foolish. Is this stuff
being worked on, or shall I take some time to throw the default code
back into the MMD subsystem?
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> 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 ParrotObjects, which happened to call the mmd
fallback functions in absence of a C<mmdvtregister> overload.
> 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<isa> float then you can just
sublass a C<Float>. If it C<isa> integer 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<PyComplex> C<isa>
C<PyFloat> albeit the C<absolute> function 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_pmc> was called)
[2]
With a C<.HLL> declaration numeric types are working too.
[3]
src/hll.c
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> 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 ParrotObjects, which happened to call the mmd
>fallback functions in absence of a C<mmdvtregister> overload.
>
>> 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.
Then they don't implement the floating point accessor vtable functions.
>All the fallback functions where just duplicating code from (mostly)
>float.pmc or integer.pmc.
Right, so to reduce code duplication you remove stuff that's working
so people have to go reimplement the code. That makes *perfect* sense.
Leopold Toetsch
> 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
Dan Sugalski
>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
It's been a long time since I sync'd up. I *assumed* that you
wouldn't break stuff. I don't know why.
>And, what is wrong about:
>
> cl = subclass "Float", "MyFloat"
Why should I have to sublcass anything to get basic functionality?
Don't bother answering that one. Having to deal with this sort of
crap is the single biggest reason I bailed. I'm happy to not have to
do so, and I'm going to keep on being bailed. Do whatever you want,
you're someone else's problem now.
Leopold Toetsch
> On 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
>
>
> 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
Leopold Toetsch
> 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
Dan Sugalski
>One could argue that by providing __get_integer, Foo class is
>automatically implying that it would serve where an Integer would.
>This is obviously what Dan was expecting. :-,
Dan was expecting sane defaults, that is when I do addition with two
PMCs that haven't otherwise said they behave specially that the
floating point values of the two PMCs are retrieved and added
together.
Y'know, like people would generally expect from all the languages in
the core set parrot cares about.
Chip Salzenberg
> Chip Salzenberg wrote:
> >On 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
> >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)
Well, aside from everything else, I think __get_integer shouldn't
return array size. But anyway.
> >> 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.
Perhaps I misunderstood, but I thought you were implying that MyFloat
would automatically have some features that Float did not, just by
virtue of the derivation. Sorry if I got that wrong.
> I still don't see the point that an arbitrary "Foo" class shall have MMD
> functions of a Float/Integer mix.
Hm. That's an interesting point.
One could argue that by providing __get_integer, Foo class is
automatically implying that it would serve where an Integer would.
This is obviously what Dan was expecting. :-,
On the other hand, C++ has been down that road, and it has potholes.
Just because an X->Y conversion exists does _not_ imply that an X will
do every place you want a Y. Ask anyone who's accidentally passed a
string as a char* without noticing. (C< operator char * () > is _not_
always your friend, and see also the C<explicit> keyword in ANSI C++.)
The new status quo is looking better.
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> http://xrl.us/gayp on Apr. 8th
I didn't realize the implications when that was posted. I think the
native fallbacks are important.
> 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.
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> Dan was expecting sane defaults, that is when I do addition with two
> PMCs that haven't otherwise said they behave specially that the
> floating point values of the two PMCs are retrieved and added
> together.
Is deriving from Float a hardship?
(This is not a rhetorical question.)
--
Chip Salzenberg <ch...@pobox.com>
Dan Sugalski
Mildly, yes. But... I'm not going to argue any more. It isn't worth
it. Do whatever you think is best, and if there's any followup you
think I should care about it'd be best to cc me, since I'm not on the
list any more.