unary and infix ops summary and todo
Leopold Toetsch
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
> 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
> 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
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
> 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
> 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
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. ;-}
Leopold Toetsch
> 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
> 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