From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Fri, 1 Apr 2005 08:42:53 +0200
Bob Rogers <[EMAIL PROTECTED]> wrote:
> From: Leopold Toetsch <[EMAIL PROTECTED]>
> . . .
> $ python
> >>> 1+2j
> (1+2j)
> That is a good point, but subclassing isn't the only way to skin this
> particular cat. To follow your example, the Lisp syntax for this
> particular complex number is "#C(1 2)", but this is produced only by
> printing operators; there is no "coerce-to-string" operation per se. So
> Lisp could define "__lisp__print_object" methods on each of the base
> arithmetic classes, and then it would be able to get away without
> subclassing them (at least as far as this issue is concerned).
No, not really. There's a common method already in core:
o."__repr"() # $o.perl in Perl6 speak
Seems to me that this is a method that produces Python syntax, and works
only for Python classes. Since Lisp uses a different printed
representation, Lisp needs a distinct operation. And since "__repr__"
is defined only on Python PMCs, those methods would need to be moved to
more generic PMC classes in order for numbers generated by Lisp (or
anything else) to use Python syntax when printed in Python.
> also has the advantage that this same (eq_addr) number will appear as
> "(1+2j)" when printed by Python code and "#C(1 2)" when printed by Lisp
> code, which is (IMHO) as it should be.
I don't think, that this effect can be achieved by
"__list_print_object". Python or Perl wouldn't know that it exists.
They wouldn't have to know -- or even care. All such methods would be
defined and used only by the Lisp system, so that wouldn't affect other
languages. Their PMC classes would all inherit suitable methods for
Parrot-defined base classes, and so they would still print correctly in
Lisp.
In fact, I have noticed two common styles of interoperation between
coexisting Lisp systems:
1. System A can define methods for its own generic (MMD) functions
that specialize on System B's classes. The generic function has a name
that belongs to one of System A's packages, so only code that is aware
of System A can call it.
2. System A can define methods for generic functions of System B
that specialize on one or more of System A's classes. This would appear
to tresspass into System B's semantic space, except that System B will
only invoke those new methods if it has instances of those System A
classes. And it can't do that by accident, because those classes have
names in System A's packages.
The "__lisp__print_object" vs. "__repr__" thing is of course an
example of the second style, with Parrot as System B. If necessary, of
course, I could do this for arithmetic operations as well, which is what
I think you've been trying to tell me all along. If so, I apologize for
being dense.
At this point I've degenerated to thinking aloud, so I'll quit now.
But this thread has helped me visualize how language interoperation can
work, and I hope it has shed some light on the issues generally (though
perhaps only for others of similar density).
-- Bob Rogers
http://rgrjr.dyndns.org/
