On Mon, Aug 18, 2008 at 5:25 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Will Coleda wrote:
>>>
>>> Any automatic mapping between multiple languages will fall down at some
>>> point in a very ugly way. I imagine modules will be developed to allow
>>> you
>>> to, for example, mask all Python typ
On Mon, 2008-08-18 at 17:44 -0400, Michael Peters wrote:
> Allison Randal wrote:
>
> > It's true that you can't get a Python array and expect it to respond to
> > all the same method calls as a Tcl array. But that Python array is just
> > another variable type, that accepts keyed access and meth
Allison Randal wrote:
It's true that you can't get a Python array and expect it to respond to
all the same method calls as a Tcl array. But that Python array is just
another variable type, that accepts keyed access and method calls. You
treat it as a user-defined data type, and read the docume
Will Coleda wrote:
Any automatic mapping between multiple languages will fall down at some
point in a very ugly way. I imagine modules will be developed to allow you
to, for example, mask all Python types from within your Perl 6 code as Perl
6 types. But users will always have the ability to go
On Tue, Aug 12, 2008 at 8:44 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
> The simple answer is Parrot won't do any automatic mapping of types between
> HLLs. If you call a Python library function that returns a Python Dictionary
> type, you'll get back a Python Dictionary PMC. You can interact w
The simple answer is Parrot won't do any automatic mapping of types
between HLLs. If you call a Python library function that returns a
Python Dictionary type, you'll get back a Python Dictionary PMC. You can
interact with it as a string keyed hash (because it implements the
string keyed vtable
From: "Will Coleda" <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 14:47:36 -0400
On Sat, Jul 26, 2008 at 10:38 PM, Bob Rogers
> Since HLLs can define their own multimethods on the existing Integer
> class without subclassing, and without fear of conflict, that is not
> sufficient r
On Wed, Jul 23, 2008 at 11:02 AM, chromatic <[EMAIL PROTECTED]> wrote:
> On Tuesday 22 July 2008 21:58:10 Mark Glines wrote:
>
>> Integer is a good example of the problem, actually.
>>
>> The internal storage format doesn't change,
>
> It certainly can. I imagine that Kea-CL's Integers autopromote
On Sat, Jul 26, 2008 at 10:38 PM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
> From: Mark Glines <[EMAIL PROTECTED]>
> Date: Tue, 22 Jul 2008 21:58:10 -0700
>
> . . .
>
> Integer is a good example of the problem, actually.
>
> The internal storage format doesn't change, but the methods you can
From: Mark Glines <[EMAIL PROTECTED]>
Date: Tue, 22 Jul 2008 21:58:10 -0700
. . .
Integer is a good example of the problem, actually.
The internal storage format doesn't change, but the methods you can call
on it definitely will. HLLs wrap the Integer class with their own
On Tuesday 22 July 2008 21:58:10 Mark Glines wrote:
> Integer is a good example of the problem, actually.
>
> The internal storage format doesn't change,
It certainly can. I imagine that Kea-CL's Integers autopromote to BigInts (or
whatever the name is), and that might require a certain precisi
Ter, 2008-07-22 às 15:37 -0700, chromatic escreveu:
> The wiki page at:
> http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes
> seems to be missing the rationale for *why* it's necessary to map types
> between languages?
I've added a little reasoning on the top of the art
On Tuesday 22 July 2008 15:37:33 chromatic wrote:
> The wiki page at:
>
> http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_not
>es
>
> seems to be missing the rationale for *why* it's necessary to map
> types between languages? (Also see "If Perl 6 has to care about the
> int
On Tue, 2008-07-22 at 15:37 -0700, chromatic wrote:
> The wiki page at:
>
> http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes
>
> seems to be missing the rationale for *why* it's necessary to map types
> between languages? (Also see "If Perl 6 has to care about the in
14 matches
Mail list logo
