Bob Rogers <[EMAIL PROTECTED]> wrote:
> From: Leopold Toetsch <[EMAIL PROTECTED]>
> Date: Wed, 30 Mar 2005 08:57:55 +0200
>
> ... , is that you are assuming (as I did not) that each and
> every language built on top of Parrot will define its own PMC classes,
> even for primitive arithmetic types, when necessary to get the right MMD
> operator semantics. Is this correct?
Not necessarily. I'd like to have core scalar types with the most common
functionality, which - e.g. for Integer PMCs - seems to be an arbitrary
integer type with automatic promotion to bigint. If your language is
happy with that type and all semantics are the same, there is no need to
subclass the PMC.
But normally all these dynamic languages have some kind of
introspection. E.g.
$ python
>>> 1+2j
(1+2j)
The string representation of a different language could be "1+2i".
Not to speak about different semantics like using "+" for string
concatenation.
> One of my motivations for exploring Common Lisp in Parrot is summed up
> in four letters: CPAN. So I expect to want to call Perl[56] code and
> get back Perl data types for further mungery in Lisp (if I ever get that
> far). It might be the right thing in that case to accept the additional
> Perl semantics, but I'm not completely convinced. I tend to think of
> operator semantics as being "language scoped," but perhaps this is just
> personal bias, as I can't think of a really compelling reason why it
> should be so.
I don't know. But Perl scalar operator semantics seems to be to morph the
destination PMC to the value of the operation:
.language perl
a = Undef
a = b + c # a maybe promoted to bigint
Python semantics are that scalar operators always create a new result.
Python scalars including strings are immutable.
.language python
a = b + c # new "a" value created
The question now is, what happens, when you call a Perl module that
happens to return the scalar "b":
.language lisp
a = b + c
Lisp works here AFAIK like Python, e.g. a new destination should be
created. So it seems that under the pragma "lisp" or "python" this
should translate to:
n_add a, b, c # not existing op that creates new "a"
and within perl semantics
add a, b, c # reuse "a"
> 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.
> ... You wouldn't want the result of MMD dispatch to change
> because the compiler got cleverer about assigning things to registers,
> would you?
Parrot itself doesn't do this optimization. Only the HLL compiler can
emit such code, if the language provides a type system. Perl6 allows:
my int ($i, $j, $k); # use natural integer
$i = $j + $k # I0 = I1 + I2
This integer $i can't promote to a bigint for example.
The more important case is:
my int @ints; # array of plain integers
There are a few rare cases, where the HLL to parrot translator could
optimize to natural types though:
for i in xrange(1..10):
print i
Pyhon's xrange produces only natural ints.
> -- Bob Rogers
leo
