Bob Rogers <[EMAIL PROTECTED]> wrote: > From: Leopold Toetsch <[EMAIL PROTECTED]>
> ..., since I assume an > Int+String=>Number method will exist that coerces the string to a number > first. I imagine you could do this by creating a subclass of Int, > e.g. LispInt, and then defining a LispInt+String method that throws an > error. Yes, as said the builtin Integer can just provide the most common functionality. When it comes to infix operations with strings languages tend to be pretty different, so that there'll be a subclass for most of the languages. > ... But even then, you still lose Lisp semantics if calls into other > code return PerlInt's, or whatever. It depends, either you have a PerlInt for e.g. $Data::Dumper::Terse = 1; then you'd need Perl semantics to set the value. Or you get a result of some module, then you'd probably do the equivalent of: lispint = perlint But I'm handwaving here. > $ 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 > 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. > Yes. And, now that you mention it, I can see headaches when Perl > scribbles on Lisp or Python constant values. So it may be necessary > (shudder) to have interface routines between Perl code and the rest of > the world in order to avoid this. I hope I'm wrong. No, I think that's pretty correct. But you have to define an interface anyway (defperl my-perl-foo ...) or some such, I presume. > > But I am also concerned that a proliferation of low-level PMC types > > will be an obstacle to interoperability. It seems simpler to me to > > represent each distinct kind of mathematical object as a single PMC > > class > I don't get that. > I'm sorry; I'm not sure how to explain it better. Except perhaps to say > that I think that numbers as mathematical objects ought to be > represented in a way that is independent of the programming language > that spawned them, to the greatest extent possible. Well, classes and subclasses, with common functionality in the base class. > Also, the Int+String example above seems to point to a situation > where code could behave one way with its "native" numeric values, but > very differently with "foreign" numbers that represent the same > mathematical values. Admittedly, this particular example seems like a > corner case, but on the other hand it seems very odd, and a source of > more debugging headaches, that the "same" numbers could give different > results. That's right. And we can't do much against that: $perl_var = python_str + $perl_str executed inside a Perl environment would concatenate, *except* when Perl provides a more derived multi sub that does it the Perl way: $ perl -le "print '02a' + '3x'" 5 That means some of the nasty cases can be catched with some effort. That's one of the big advantages of MMD. > And so even in Lisp, you would want (and expect) different behavior > for "int" vs. "Int". Fine. > -- Bob Rogers leo
