String.to_int() vs. opcode

[Chip Salzenberg]

(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]

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]

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]

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]

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