Re: finished/stable parts of parrot?

[Melvin Smith]

At 12:10 PM 11/21/2003 +0100, Leopold Toetsch wrote:
Robin Redeker <[EMAIL PROTECTED]> 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