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

finished/stable parts of parrot?

3 views
Skip to first unread message

Robin Redeker

unread,
Nov 20, 2003, 2:25:28 PM11/20/03
to perl6-i...@perl.org
Hi,

i don't know whether this list is the right list to ask this question:
I have been following the parrot (and perl6) development (mailing lists)
for some time now, and i can't wait to play around with parrot.
Currently i would like to target parrot for some language experiments.
But i wonder which parts of parrot are stable enough and which
part of the IMCC language is finished and wont change much in future?

cya,
Robin

--
Robin Redeker el...@x-paste.de

Leopold Toetsch

unread,
Nov 21, 2003, 6:10:06 AM11/21/03
to Robin Redeker, perl6-i...@perl.org
Robin Redeker <el...@x-paste.de> wrote:
> Hi,

Welcome

> Currently i would like to target parrot for some language experiments.
> But i wonder which parts of parrot are stable enough and which
> part of the IMCC language is finished and wont change much in future?

Existing syntax will not change much. The only part that is currently
under construction is related to subroutine calling conventions. But its
more a matter of adding shortcuts or simplifications then changing
existing syntax. Just s/\.pcc_sub/.sub/ comes to my mind.

> cya,
> Robin

leo

Melvin Smith

unread,
Nov 21, 2003, 10:48:59 AM11/21/03
to l...@toetsch.at, Robin Redeker, perl6-i...@perl.org
At 12:10 PM 11/21/2003 +0100, Leopold Toetsch wrote:
>Robin Redeker <el...@x-paste.de> wrote:
> > Hi,

Hi Robin,

> > Currently i would like to target parrot for some language experiments.
> > But i wonder which parts of parrot are stable enough and which
> > part of the IMCC language is finished and wont change much in future?
>
>Existing syntax will not change much. The only part that is currently
>under construction is related to subroutine calling conventions. But its
>more a matter of adding shortcuts or simplifications then changing
>existing syntax. Just s/\.pcc_sub/.sub/ comes to my mind.

What Leo said, with some more detail. There will be more
extending syntax than breaking syntax.

Here are my "short" list of things in the queue for IMCC. None of them are
what I would call "fundamental syntax structure" changes nor do many
actually break existing syntax.

1) We are adding "metadata" directives soon. This is optional
syntax which will not break existing code, we hope.

2) Adding a full "class" declaration syntax. Basically it is just another
phase of the metadata addition, but will be the preferred way to
declare non-anonymous classes. (.class/.field/.method directives)

3) Adding 2nd form of sub/method call. Currently you call by a locally
visible label with: _foo()
but if you call a sub that is in a register or variable you have to
construct
the PMC yourself and emit the code. Since most of Perl6's calling will
likely be done by the 2nd method (since sub addresses can change),
the new syntax (as discussed on IRC) is simply a * in front of the
identifier
or register. *foo() or *$Px would mean you have a pmc register holding a
sub PMC. (foo would have to be declared with .local pmc foo. While it
is possible to have IMCC figure out stuff without the *, we decided that
clarity was better for debugging and it easily maps to a different flag in
the AST interface (when it ever gets written).

4) Anything to do with shortcuts to class method calls in the form:
MyClass::foo() or *object.foo() is currently not available yet; you can't
use it, so there is no danger. Today to accomplish this you would have
to do:

Px = newsub _MyClass__foo
store_global "MyClass::foo", Px
...
fetch_global Px, "MyClass::foo"
# Setup args
invoke Px
# Retrieve returns

This is only a fake way of doing it and eventualy will be replaced by
the metadata section and call by name shortcut syntax.
.class MyClass
.method foo
.endclass

# P0 holds the object
ret = *P0.foo() # Or something similar


Up to here, there is no breakage to existing syntax.
However...

5) .pcc_sub will change from its own directive to an attribute of the
.sub directive. PCC is the default anyway, but if you wanted to be
explicit eventually you might write ".sub _foo : pcc, prototyped"
or something. Basically anything after the ':' will eventually map
to flags on an AST node that is fed to IMCC. However, IMCC
will always read the text version, and the short .sub _foo version
with no optional directives should always work; however it may
eventually mean non-prototyped or dual-convention, whereas now it
means pcc|prototyped.

6) .pcc_begin_return
# return statements
.pcc_end_return

Deprecated soon, but still supported for a few releases.
New syntax will be something like:

.return 10
.return (i,,j,k)
.return <flatten operator> Px
# in combination with
.yield

Since Parrot subs can return multiple values, just like calling a sub,
the return code will be nearly orthogonal to the call syntax, however,
since subs can return from multiple places, one IMCC directive will
be for setting the values up for return, and a second will take care of
emitting the actual return convention and doing the return.

7) Internal, IMCC generated labels that do not get global fixup will
probably look like @somelabel unless we figure that @ might have
a better potential use and assign some other character. @ will not
map to a HLL feature like Perl6 lists. Currently internal labels have
embedded # in them, but it has been discussed, and found to be
dangerous in the case of hand-written code. Currently this feature
is undecided.

Summary for your question:

If you declare your subs like:

.sub _foo {optional-attribute-directives}
.param int i
.param string s
...
# This is the only part to be deprecated
.pcc_begin_return
# return baz
.pcc_end_return
.end

And call them like:

$P11 = _foo($I0, $S1)

then you should be fairly safe from upcoming changes.

There are no promises, though, until Parrot1.0 :)

-Melvin


0 new messages