unary and infix ops summary and todo

0 views
Skip to first unread message

Leopold Toetsch

unread,
Apr 29, 2005, 5:18:25 AM4/29/05
to Perl 6 Internals
1) we now have a rather complete set of opcodes that return a new result
PMC, all prefixed by "n_", e.g.

n_add Px, Py, 1
n_abs Px, Py

These opcodes can/should be used by HLLs like Python, which have the
semantics of immutable scalars and newly created result PMCs.

2) Tests for all these opcodes are very welcome

3) Proposal: PIR syntax enhancement

.pragma n_operators
...
Px = Py + 1
...
[EOF]

Within this pragma (valid inside and until end of file) the shortcuts
'+', '-', ... should translate to "n_add", "n_sub", ...
This simplifies the adaption of already existing compiler code and is a
bit more readable.

4) HLL to Parrot core type mappings.

Most of Parrot's core classes functionality can now be inherited by
HLL-specific classes. But there are still some explicit type enums in
classes/*.pmc that should be HLL-dependent. E.g.

Complex.absolute()
result = pmc_new(.. enum_class_Float)

This should rather be a TclFloat, PyFloat, whatever. To achieve this,
we'd need a mapping for core PMCs and an HLL language specifier.

E.g.:

# file1
.HLL python python_group # language, shared lib
.type_map Float => PyFloat
.type_map Integer => PyInt
...

# file2
.HLL tcl tcl_group
.type_map Float => TclFloat
.type_map Integer => TclInt

The C<.type_map> has to be specified just once. The C<.HLL> in each
source file. If no C<.HLL> was seen, the language defaults to parrot.
Instead of the bare words, we could demand quoted strings too.

Comments welcome,
leo

Jerry Gay

unread,
Apr 29, 2005, 10:01:45 AM4/29/05
to Leopold Toetsch, Perl 6 Internals
On 4/29/05, Leopold Toetsch <l...@toetsch.at> wrote:
> 3) Proposal: PIR syntax enhancement
>
> .pragma n_operators
> ...
> Px = Py + 1
> ...
> [EOF]
>
> Within this pragma (valid inside and until end of file) the shortcuts
> '+', '-', ... should translate to "n_add", "n_sub", ...
> This simplifies the adaption of already existing compiler code and is a
> bit more readable.

will this pragma affect all '.include'd files too? i dunno if this is
good or bad.

can it be reversed? something like:
.pragma n_operators
...
Px= Py + 1
...
.pragma a_operators
Pz= Pi + 1
[EOF]

i'm remembering my days with 'perl -w' and would rather have the 'use
warnings;' functionality (scoping, both on AND off switches, etc.)

~jerry

Leopold Toetsch

unread,
Apr 29, 2005, 11:39:37 AM4/29/05
to jerry gay, perl6-i...@perl.org
Jerry Gay <jerr...@gmail.com> wrote:
> On 4/29/05, Leopold Toetsch <l...@toetsch.at> wrote:
>> 3) Proposal: PIR syntax enhancement
>>
>> .pragma n_operators
>> ...
>> Px = Py + 1
>> ...
>> [EOF]
>>
>> Within this pragma (valid inside and until end of file) the shortcuts
>> '+', '-', ... should translate to "n_add", "n_sub", ...
>> This simplifies the adaption of already existing compiler code and is a
>> bit more readable.

> will this pragma affect all '.include'd files too? i dunno if this is
> good or bad.

.include files are just included and become part of the source file, so
yes. But that's not good, if the .include file contains code too. Seems
tath we need:

.pragma n_operators push 0 # or 1
.pragma n_operators pop

> can it be reversed? something like:
> .pragma n_operators
> ...
> Px= Py + 1
> ...
> .pragma a_operators

Good idea. So maybe just:

.pragma n_operators 0 # file default
.pragma n_operators 1

> ~jerry

leo

Bob Rogers

unread,
Apr 30, 2005, 10:02:51 PM4/30/05
to Leopold Toetsch, Perl 6 Internals
From: Leopold Toetsch <l...@toetsch.at>
Date: Fri, 29 Apr 2005 11:18:25 +0200

1) we now have a rather complete set of opcodes that return a new result
PMC, all prefixed by "n_", e.g.

n_add Px, Py, 1
n_abs Px, Py

. . .

2) Tests for all these opcodes are very welcome

I have started writing a t/op/n_arithmetics.t test, based directly on
t/op/arithmetics.t. But I notice that if I try

P0 = n_add P0, 1

I get the error:

error:imcc:op not found 'n_infix' (n_infix<3>)

Shouldn't this just replace the PMC in P0 with a new PMC? Or is this
something that is not completed yet?

-- Bob Rogers
http://rgrjr.dyndns.org/

Leopold Toetsch

unread,
May 1, 2005, 4:51:27 AM5/1/05
to Bob Rogers, Perl 6 Internals
Bob Rogers wrote:
> Also, I notice that n_ceil and n_floor are not implemented. Should
> they be?

floor, ceil is currently implemented for native types only. As long as
we don't have PMC variants, we don't have n_ceil and n_floor either.

I don't know, if we need PMC variants and vtable functions.

> -- Bob

leo

Leopold Toetsch

unread,
May 1, 2005, 5:18:47 AM5/1/05
to Bob Rogers, perl6-i...@perl.org
Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:

> I have started writing a t/op/n_arithmetics.t test, based directly on
> t/op/arithmetics.t.

Great, thanks.

> ... But I notice that if I try

> P0 = n_add P0, 1

> I get the error:

Accidentally converted to an inplace operation. Is fixed here already.
I'll committ it RSN.

Thanks,
leo

Bob Rogers

unread,
May 1, 2005, 10:45:29 PM5/1/05
to l...@toetsch.at, perl6-i...@perl.org
From: Leopold Toetsch <l...@toetsch.at>
Date: Sun, 1 May 2005 11:18:47 +0200

Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:

> I have started writing a t/op/n_arithmetics.t test, based directly on
> t/op/arithmetics.t.

Great, thanks.

No problem. See attached. It should cover everything that is covered
in arithmetics.t that makes sense for the n_* ops. Is there anything
missing?

> ... But I notice that if I try

> P0 = n_add P0, 1

> I get the error:

Accidentally converted to an inplace operation. Is fixed here already.
I'll committ it RSN.

I notice this case works now, so it's covered; thanks.

From: Leopold Toetsch <l...@toetsch.at>
Date: Sun, 01 May 2005 10:51:27 +0200

Bob Rogers wrote:
> Also, I notice that n_ceil and n_floor are not implemented. Should
> they be?

floor, ceil is currently implemented for native types only. As long as
we don't have PMC variants, we don't have n_ceil and n_floor either.

OK; I wasn't paying attention, it seems.

I don't know, if we need PMC variants and vtable functions.

The semantics of floor and ceil are pretty close to the metal anyway, so
I'm not sure what PMC versions would buy, other than convenience. I'll
assume the decision is therefore "no" -- until decided otherwise, of
course. ;-}

n_arithmetics.t

Leopold Toetsch

unread,
May 2, 2005, 8:10:18 AM5/2/05
to Bob Rogers, perl6-i...@perl.org
Bob Rogers wrote:
> From: Leopold Toetsch <l...@toetsch.at>
> Date: Sun, 1 May 2005 11:18:47 +0200
>
> Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:
>
> > I have started writing a t/op/n_arithmetics.t test, based directly on
> > t/op/arithmetics.t.
>
> Great, thanks.
>
> No problem. See attached.

Thanks, applied - as t/pmc/n_arithmetics.t though

> The semantics of floor and ceil are pretty close to the metal anyway, so
> I'm not sure what PMC versions would buy, other than convenience. I'll
> assume the decision is therefore "no" -- until decided otherwise, of
> course. ;-}

Yep

Thanks,
leo

Leopold Toetsch

unread,
May 20, 2005, 4:36:06 AM5/20/05
to perl6-i...@perl.org
Leopold Toetsch <l...@toetsch.at> wrote:

> 3) Proposal: PIR syntax enhancement

> .pragma n_operators
> ...
> Px = Py + 1
> ...
> [EOF]

> Within this pragma (valid inside and until end of file) the shortcuts
> '+', '-', ... should translate to "n_add", "n_sub", ...
> This simplifies the adaption of already existing compiler code and is a
> bit more readable.

Done now.

.pragma n_operators 0 # off
.pragma n_operators 1 # turn it on

WRT include files: the intended behavior is that the state of the
n_operators setting reverts to the state before the file inclusion:

.pragma n_operators 1
...
.include "foo.imc"

# n_operators is 1 again

*But* inside the include file the last pragma setting is used. This can
be changed easily by not copying the setting in imcc.l:new_frame().

OTOH we could just demand that include files with code have to set /
reset that pragma to the desired value. It's kind of a documentation how
the semantics of

a = b + c # new a PMC or not

actually are inside that file.

After we have found a consensus I'd be glad with some tests additionally
to the one in t/pmc/n_arithmetics.t

Thanks,
leo

Reply all
Reply to author
Forward
0 new messages