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

Dismiss

Inconsistent opcode names

5 views

Skip to first unread message

unread,

Nov 20, 2004, 8:06:33 PM11/20/04

to Perl 6 Internals

Is there a reason why we have "find_type", but "loadlib"; "eq_str" but "isnull" ?

unread,

Nov 21, 2004, 4:20:02 AM11/21/04

to William Coleda, perl6-i...@perl.org

William Coleda <wi...@coleda.com> wrote:

> Is there a reason why we have "find_type", but "loadlib"; "eq_str" but
> "isnull" ?

In ancient days the perl5-based assembler tools had troubles with
underscores in opcode names, as the operands (for the fullnames) are
encoded like:

add_p_p_p # add Px, Py, Pz

There *was* a restriction. For readability a few more underscores are
probably ok:

find_ lex, global, type
load_ lib, bytecode
is_ null, same, true, false, lt ... gt # but isa

There are likely some more inconsistencies, which should be fixed rather
sooner then later.

Dan, is that ok with you?

leo

unread,

Nov 21, 2004, 8:20:12 AM11/21/04

to l...@toetsch.at, perl6-i...@perl.org

Leopold Toetsch wrote:
>
> There are likely some more inconsistencies, which should be fixed rather
> sooner then later.

One that I noticed:

=item B<getattribute>(out PMC, in PMC, in STR)
=item B<getprop>(out PMC, in STR, in PMC)

- Sam Ruby

unread,

Nov 21, 2004, 9:56:05 AM11/21/04

to Sam Ruby, perl6-i...@perl.org

> One that I noticed:

Yeah, and get_repr, get_addr. Same with set*

> - Sam Ruby

leo

unread,

Nov 21, 2004, 2:18:08 PM11/21/04

to William Coleda, Perl 6 Internals

On Sat, Nov 20, 2004 at 08:06:33PM -0500, William Coleda wrote:
> Is there a reason why we have "find_type", but "loadlib"; "eq_str" but
> "isnull" ?

I was just reading something blasting PHP for not being consistent about
core naming conventions particularly about "this_that" vs "thisthat".
FWIW.

--
Michael G Schwern sch...@pobox.com http://www.pobox.com/~schwern/
You're more radiant than a memory of breathtaking ecstasy.

0 new messages