{ p6i added ... this has turned into an interesting design discussion }
On Wed, Apr 05, 2006 at 03:54:51PM +0200, Leopold Toetsch wrote:
> On Tue, Apr 04, 2006 at 11:42:36AM -0700, Chip Salzenberg wrote:
> > I've done some [more] reading up on value types. [...]
> > Parrot 1.0 will _not_ have native support for anything like value types.
> > Parrot 1.0's type universe will consist entirely of [ISNP].
>
> A value PMC is just a PMC. I don't see a need to extend the type system,
> when supporting value PMCs. I see these more as just another PMC with
> different semantics (compared to current existing morphing PMCs).
Well, there's more than one kind of value type. I'm sure somebody
(*cough*Audrey*cough*) can provide us standard names from the literature,
but the key distinction I see is between a reference model and a value
model. I was talking about the value model, mostly.
1. "Value Model" for value objects
Extending the basic VM treatment of integers -- create and destroy them
without involving the GC subsystem, and copy them with memcpy() -- to new
user-created types. Imagine if time-critical Parrot code could
manipulate e.g. a complex number that was defined as nothing more than a
pair of N values just by copying it around rather than doing the "new
.Complex" zoo dance, perhaps to support high-speed graphics. Right now
you'd have to dive into C to do that sort of thing efficiently.
Cool concept, and will take a fair bit of design work to make useful, but
is not on my short list at the moment, and if Parrot 1.0 does without it,
that'll be OK with me.
Audrey pointed out that one way to handle this sort of value type is to
introduce a new kind of register, which is why saying 'stick with [ISNP]'
is synonymous with 'no value types' [of that nature].
2. "Reference Model" for value objects
In Parrot, this mostly amounts to unique read-only PMCs.
We'll have the read-only part, but the "unique" part, probably not.
By "unique" I'm talking about enforced global uniqueness of a given
value, e.g. string memoization. (A global uniqueness guarantee
ensures that e.g. "(1+1).id == 2.id".) Audrey requested this, but
I'm not planning to provide it. She's willing to do without ... or,
actually, is willing to implement it herself where needed.
(I actually don't object to the idea of enforced global global
uniqueness, but I don't know how Parrot should do it, and until object
construction is reviewed [and possibly reformed], I don't want to hang a
picture on the wall scheduled for demolition.)
Leo:
> Chip:
> > On Sun, Mar 12, 2006 at 02:35:11AM +0800, Audrey Tang wrote:
> > > The easy workaround for now is to have a "does readonly" interface in
> > > addition to the current "does scalar", which forbids all self-mutable
> > > vmethods.
> >
> > That's a good hack.
> >
> > Perhaps unrelated, perhaps not: Parrot will soon have a flyweight read-only
> > proxy PMC, which will address the use case of "sub foo($a)", in which $a
> > must be a read-only alias of the passed argument. Language implementors may
> > find this useful in some otherwise value-oriented situations.
>
> That would work of course. But I'm curious, where the 'flyweight' would
> come from. It would be the same as the existing Ref PMC. Or the same
> weight as a scalar container PMC.
Flyweight in terms of added semantics (very little) and visibility to users
(almost none). "You'll hardly know it's there." OTOH, memory usage will,
as you say, not be very different from a Ref, unless we hack something up
specially. I want to wait to see what actually uses memory before we start
optimizing one use case over another. In the average running Parrot app,
will there be more integers, or more readonly_proxies, or more of ... something
else?
--
Chip Salzenberg <[EMAIL PROTECTED]>
