Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

String.to_int() vs. opcode

6 views
Skip to first unread message

Chip Salzenberg

unread,
Aug 25, 2006, 3:15:55 PM8/25/06
to Leo Toetsch, parrot-...@perl.org
(For those not watching CVS, Leo's just added a METHOD to_int() to String.)

Seems like this is the kind of thing that needs to have a common subroutine
in the C source so it can be used elsewhere, and an opcode so it's usable
with an S register. And once you've done that, the METHOD becomes redundant.
--
Chip Salzenberg <ch...@pobox.com>

Will Coleda

unread,
Aug 25, 2006, 3:32:12 PM8/25/06
to Chip Salzenberg, Leo Toetsch, parrot-...@perl.org
What about 'say'? It's a method, not an opcode, and:

say $S0

works just fine.

I don't think there's *a priori* a problem to implicitly upgrade
something to a PMC to perform a non JIT-able task on it. I do think
pulling too hard at this thread might require a closer look at what's
current in src/pmc/ vs. src/*.c vs src/ops/ (where's there's
smoke...): a lot of the current state has been a result of organic
(rather than planned) growth.

Regards.

--
Will "Coke" Coleda
wi...@coleda.com


Jerry Gay

unread,
Aug 25, 2006, 3:49:30 PM8/25/06
to Will Coleda, Chip Salzenberg, Leo Toetsch, parrot-...@perl.org
On 8/25/06, Will Coleda <wi...@coleda.com> wrote:
> What about 'say'? It's a method, not an opcode, and:
>
> say $S0
>
> works just fine.
>
but C<say $I0> does *not* work.
i find that annoying.
either make the syntax for methods different than ops (eg C<$S0.say()>)
or make C<say> an opcode,
or dodge the syntax issue and make C<say> a method on all register types.

forcing me to convert the int to a string in order to auto-print a
newline instead of printing the int and the newline separately saves
me no code. having an op that's named the same as a parrot op but is
limited to one register type is confusing.

/flame off
~jerry

Chip Salzenberg

unread,
Aug 25, 2006, 4:03:25 PM8/25/06
to Will Coleda, Leo Toetsch, parrot-...@perl.org
On Fri, Aug 25, 2006 at 03:32:12PM -0400, Will Coleda wrote:
> What about 'say'? It's a method, not an opcode, and:
> say $S0
> works just fine.

Well, 'say' is a parrotio METHOD, not a String METHOD:

METHOD INTVAL say(STRING *s)

so the SELF is an io PMC and nothing is hard. Expressing to_int() as a
method where the SELF is a String PMC leaves the string registers out in the
cold.

The 'say' opcode also requires hackery in src/builtin.c; but since "requires
hackery" seems to be the status quo ante for half of Parrot, perhaps I should
let that go unmentiond. Oops, too late. ("Bitter? Oh, a *tad*.")

> I do think pulling too hard at this thread might require a closer look at
> what's current in src/pmc/ vs. src/*.c vs src/ops/ (where's there's
> smoke...): a lot of the current state has been a result of organic (rather
> than planned) growth.

No kidding. :-/
--
Chip Salzenberg <ch...@pobox.com>

Allison Randal

unread,
Sep 12, 2006, 2:38:07 PM9/12/06
to parrot-...@perl.org
jerry gay wrote:
>>
> but C<say $I0> does *not* work.
> i find that annoying.
> either make the syntax for methods different than ops (eg C<$S0.say()>)
> or make C<say> an opcode,
> or dodge the syntax issue and make C<say> a method on all register types.
>
> forcing me to convert the int to a string in order to auto-print a
> newline instead of printing the int and the newline separately saves
> me no code. having an op that's named the same as a parrot op but is
> limited to one register type is confusing.

Agreed.

> On Fri, Aug 25, 2006 at 03:32:12PM -0400, Will Coleda wrote:

>> I do think pulling too hard at this thread might require a closer look at
>> what's current in src/pmc/ vs. src/*.c vs src/ops/ (where's there's
>> smoke...): a lot of the current state has been a result of organic
(rather
>> than planned) growth.

Overall, this sounds like an excellent addition to the coding standards,
and an excellent task for the cage cleaners.

Allison

0 new messages