On Fri, Feb 19, 2010 at 06:20:18PM -0000, Whiteknight wrote:
> Point noted, and in the spirit of musing I would turn this around on you
> again and ask why treating an array as an integer value should return the
> element count of that array? This is very much a perlism, when many other
> languages would require you to call length($P0), or $P0.count, or
> $P0.length, or some variation thereof. [...]
I fear that you routinely ascribe to my suggestions and comments
far more Perl-think and Perl-based motives than are actually present.
If this is the case, please stop doing so.
None of what I wrote above depends on or has anything specifically
to do with a perlish interpretation of arrays. In one comment above
I did give an example of an Array returning its element count, but
there I was simply citing Parrot existing behavior for arrays,
and not intending to imply that this is the way arrays are
supposed to behave when treated as integers.
More to the point, even NQP doesn't impose this interprestation
on arrays. NQP truly does wish to be as transparent as
possible to the underlying vm and objects, so if you say
my $value := +$obj;
then what NQP wants to give you is $obj's idea of its numeric
value, whatever that happens to be. NQP absolutely does *not*
say or imply "if $obj is an array, then its numeric value is
the number of elements in the array" -- that choice is
entirely up to the underlying objects and vm (Parrot in this
instance).
This extends even to variables that have the @ sigil -- with
my @array := XYZArray.new;
my $value := +...@array;
you get whatever XYZArray reports as its numeric value, which
can be whatever the XYZArray implementor decided was
appropriate.
> If getting the integer form of an array is really code for "get the number
> of elements" (which, I think, is especially unnecessary in light of the
> "elements" opcode and VTABLE), it really is a bit of an extra stretch to
> suggest that calling get_number should only be able to return a floating-
> point representation of what get_integer returns (which, again, is just a
> convenience copy of VTABLE_elements).
The choice to have Parrot arrays return the number of elements
as its integer value was made long before I started working
on things, and it's not something that either I or NQP require.
If an NQP programmer wants to be sure to get the number of elements
in an array and not rely on the PMC's get_number interface, the code is:
my $value := pir::elements(@array);
Or, if @array has a method for returning its number of elements, you
can use that:
my $value := @array.elems();
The meaning of +...@array is not at all dependent on Perl.
> Maybe I suggest that get_number
> should return a value for the array which is more suited for representing
> as a floating point: Maybe memory utilization percentage, some sort of
> compression metric, memory fragmentation percentage?
I suspect you mean this as a strawman argument, but overall
the suggestion would seem to be a very poor one. The point of
the vtable interfaces is to promote language interoperability, and
not as places to hang behaviors we think might be appropriate.
In Parrot, the commonly understood meaning of get_integer is
"give me your integer value", and the common understanding of
get_number is "give me your floating-point value". I think that
the vast majority of us would be very surprised to have get_integer
and get_number use such wildly different semantics (whatever
they may be).
Again, the point of my previous comment was simply to say that
if a PMC provides a get_integer vtable, it would seem to make
sense in most cases to have it go ahead and provide get_number
as well. This does not seem to me to be a particularly perlish
view of things.
> ... but it does go to show that other languages have very
> different notion of how an array type should respond to a
> "get an integer" or "get a number" request.
Sure, but how many of those languages have the notion that
"get an integer' and "get a number" are radically different,
as you suggest above?
Again, I'm not at all saying that "get_integer" or "get_number"
on an array must always return the number of elements, or
basing my suggestion on this perl-specific behavior. I'm simply
saying that if a PMC provides get_integer (whatever that ends up
meaning for the PMC, in whatever language), then providing the
equivalent value for get_number often makes a lot more sense
than throwing an "not implemented" exception. (And I think
it makes much more sense than putting in some other behavior
that just happens to provide a floating point value.)
If your dislike of perlisms in Parrot is so great that you
believe that Parrot's core array PMCs should not have the
current get_integer behavior, that's actually okay with me.
It won't affect NQP one bit. But let's at least have get_number
and get_integer be reasonably consistent wherever we do provide them.
Pm
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
