On Thu, Jul 25, 2002 at 01:32:44PM -0700, Scott Walters wrote:
> On Thu, 25 Jul 2002, Mike Lambert wrote:
>
> > Scott Walters wrote:
> >
> > > Part of the beauty of PMCs is that you can have very compact
> > > storage given a dedicated eg int array type. Generating these
> > > would not be a bad thing. The typical case still remains, that
> > > arrays will contained mixtures of all datatypes.
> Given strict compile time typing, the optimizer could pick from one of:
> IntArray, NumArray, StringArray, PMCArray, MixedArray. "Could" being the
> disoperative word. If they were available, a user could provide hints by
> explicitly specifying which he wanted. Storing a PMC in an IntArray
> would cause it to be downgraded. Having things available never hurts.
IIRC having the ability to say in perl6 "this is an array of ints" and
have them stored in sizeof(int) was part of Larry's plan.
Which means that we have to have something to implement IntArray.
Partly I remember this, because "what about tainting" was one of the
pitfalls floating around (in that myself and others were assuming that perl6
will still have the concept of tainting available, and just because you
turn tainting on doesn't mean that you want your dense arrays of ints to
explode into PMCs).
I remember this because I remember proposing a solution - have the PMC
store a bit array in parallel with the int array, with 1 bit per entry to
recored taintedness. (Clearly if perl6 gives more than 2 levels of
taintedness that will need to increase to log2(levels) bits, but this will
still be smaller than a full blown PMC per entry.
> > However, returning referencse does have one major advantage. Indicating
> > the *lack* of something. If I retrieve a PMC which doesn't exist, I can
> > get NULL back. But if I retrieve the 5th index of an integer array for
> > which the length is 3, what am I supposed to get bacK? NaN? In this
> > context, retrieving a pointer to the referred element makes sense, and
> > allows us to "do things" to the keyed element, that aren't necessarily
> > supported by the vtable methods. I'm beginning to agree with you, here. :)
> >
> Promoting things to PMCs bring up an interesting point: a single instance
> of a certain PMC could be designated the "null PMC". As an int, a null
> PMC would "return 0;". It would be immutable and could be reused all
> over the place. It would be returned whenever a PMC was requested but
> the slot that would contain it contains nothing. Perhaps Parrot is already
> doing this and I completely missed it. Null pointers are a special case
> best avoided. Its better to have something always rather then something
> most of the time and not others. It could be compared to the official null object
> by pointer. Speed hack to deal with that case, nothing more.
This sounds much like the implementation of perl5, where PL_sv_undef is
the global SV that a literal C<undef> becomes. There is nothing stopping
parrot (or perl5) having more than 1 "exception" type PMCs that each signify
something different, but all return the same values when treated as an int
(eg all return 0;)
[in perl5 terms there could be undef and not_in_hash, both of which look like
undef to all perl code, but actually the latter is PL_sv_not_in_hash, and
certain code could check for it. (ie pp_exists in perl5 could be implemented
as a hash lookup that returned this marker SV, followed by a check, rather
than the current way)]
This would let code which is aware of the distinct values understand the
subtle distinctions in "failure" returned to it, but everything else wouldn't
need to care - it would all be undef.
In perl5, as of 5.8, there is one place (only?) where literal undef is
distinct from a scalar that is undefined - the new open code with three
arg open treats
open(TMP, "+>", undef) or die ...
as a request to open an anonymous temporary file, whereas
undef $a; open(TMP, "+>", $a) or die ...
will be treated as an attempt to open the named file, where the name is ""
(after warning about the use of an uninitialized value - you were running
with use warnings, weren't you?)
Whether 5.8's distinction between C<undef> and undefined is useful enough
to justify the special case is another matter.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
