Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:43 PM +0200 8/10/04, Leopold Toetsch wrote:
>>We currently have two integer PMCs, we need another one for Python.
>>But before just copy&paste another file, I'd really have done that
>>right.
> I think what we need's a policy here. Larry's weighed in on what
> Perl's going to want, which is cool. (In part because I'd lost track
> of this message :)
> So, for us:
> 1) The base types don't change. Ints stay Ints, Strings stay Strings,
> and so on.
Is an C<__Integer> PMC really useful then? Ok, it could spit out a
warning or error on overflow. But basically one could use a natural
INTVAL instead.
Anyway: Perl6 and Python integer PMCs seem to be almost identical. Both
just provide integers of arbitrary size. Python folks are talking about
unifying C<int> and C<long> so that there is no distinction anymore.
Given that we already need two almost identical integer PMCs, it would
be just simpler, if the provided base type implements 99% of all the code
and that the Python or Perl Int just inherits from the base type.
[ more rules ]
> 5) We need to set up an alias and namespace system so languages can
> generally ignore this. Perl's going to want its base int class named
> "int" or "Int", and so is Python, and we should make at least a
> minimal attempt to set things up so that code that looks up PMC
> classes by name actually behaves right.
We have AFAIK this class names:
Perl6 Python
natural int IRef int -
integer PMC Int int
What happens, if some Python code calls a Perl6 module that returns an
integer PMC and Python code does:
>>> ret_val=1 # from Perl6 module
>>> type(ret_val)
<type 'int'>
> If someone wants to take on ownership of the existing PDD on our base
> types that's fine with me.
Yep, takers wanted.
leo
