#1445: Add ResizableStringArray.get_number VTABLE function
-----------------------------+----------------------------------------------
Reporter: Austin_Hastings | Owner:
Type: todo | Status: new
Priority: normal | Milestone:
Component: none | Version: 2.0.0
Severity: medium | Keywords: rsa, ResizableStringArray,
get_number, NQP
Lang: | Patch:
Platform: |
-----------------------------+----------------------------------------------
Comment(by whiteknight):
Replying to [comment:8 pmichaud]:
> 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.
I apologize if this is the way my comments have been viewed. This is not
my intention. All of my objections and criticisms are aimed at Parrot and
it's design, not at you or at NQP. Parrot's design has been strongly
influenced by Perl5 for, as far as I can tell, the entirety of the
project. In many cases I think that influence is fine. In some I think it
doesn't make sense in light of Parrot's greater goals.
> 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.
My point was that this is how arrays are treated in Perl5: In a numerical
context an array returns it's element count. I can't think of too many
other languages where this is the default behavior for an array (of
course, we have to stretch the notion of "context" when talking about
other languages).
> 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.
It was a strawman, but does illustrate a point. When I say "get a
floating-point number from that array", there are a handful of different
values that could be reasonably returned. Likewise, when I say "get an
integer from that array", it doesnt ''have to'' mean get the element
count. Parrot defines VTABLE_get_integer on arrays to be identical to
VTABLE_elements by convention, and I don't think that's necessarily the
best idea. We also like to think about VTABLE_get_number as returning the
same value in a different format as VTABLE_get_integer by convention, when
I don't think that always makes good sense either. And then saying that
Arrays should be forced to implement VTABLE_get_number as a cast over
VTABLE_get_integer is just compiling a strange decision onto a strange
decision. Sure, we can talk about PMCs interoperating and how there's this
magical common interface, but the reality is we're talking about using
arrays as items in non-vector mathematical equations, and that requires
several leaps of logic and understanding that I don't think Parrot should
be forcing at the lowest level.
> 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.
If it is the intention that get_integer and get_number always return the
same number only in different formats, then that is a guarantee that we
should enforce. We can discuss that topic in a different ticket if changes
need to be made.
> 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?
It has to depend on the type. Integer.get_number and Float.get_integer
have certain expectations but other more complicated types do not. I can
imagine legitimate types where the ideas of "give me an integer" and "give
me a number" could easily be expected to return different values.
> 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.
I have no dislike of perlisms, it is not a criticism to say that they
exist or that Parrot has been influenced by them. It is also not an insult
to say that many other HLLs do not share the same kinds of semantics.
So long as things do stay consistent (or, more realistically, begin to
approach consistency) I will not be unhappy, but my strong preference is
in not providing VTABLEs on types where they are not necessary and not
creating a de facto standard where PMC types are compelled to provide
large numbers of extra VTABLEs. Consistently minimal is always easier to
get right and maintain than consistently complicated. We could argue all
day, of course, about what constitutes an acceptable "minimum".
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1445#comment:9>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
