Re: Sun Fortress and Perl 6

2005-04-30 Thread Autrijus Tang
On Sat, Apr 30, 2005 at 08:41:52AM +0200, Leopold Toetsch wrote:
> Anyway Parrots MMD system depends on types. *If* the Perl6 compiler defines
> above array as
> 
>   cl = subclass "FixedFloatArray", "num_Array_shape_3_3_3"

Yes, that is what I am planning to emit for hierarchical and other
subtyped signatures.  We also need to generate those for the
user-defined "subtype" things in Perl 6.

> then this kind of array would be a distinct type. The other possiblity
> is: we have one Multi_shaped_FloatArray, which takes an initializer with
> the dimensions (see e.g. classes/multiarray.pmc) then all these shaped
> num arrays would be one type, dispatching to the same routines.

Hm, I have no clue whether we can MMD based on shape of arrays.
Anyone has ideas about that?

Thanks,
/Autrijus/


pgpuFVTUQ16fv.pgp
Description: PGP signature


Re: Sun Fortress and Perl 6

2005-04-30 Thread Leopold Toetsch
Autrijus Tang <[EMAIL PROTECTED]> wrote:

> my sub get_book () of Hash of Array of Recipe {...}
> my num @nums = Array of num.new(:shape(3;3;3));

> Does Parrot's MMD carry this type information natively?

Neither of above. But:

  multi sub foo(Int $a, Num $b) { ... }

aka

  .sub foo @MULTI(Int, Num)

- creates a MultiSub PMC stored in the current namespace as "foo"
- stores the sub itself as "[EMAIL PROTECTED]@Num" and
- attaches that Sub PMC to the MultiSub

> ..., and Ponie can then
> reuse the same name-mangling to call into Perl 6 subroutines.

Well, I presume that this could cover just the static case, which with
the absence of types in Perl5/Ponie, would make it impossible to call
multisubs.

Anyway Parrots MMD system depends on types. *If* the Perl6 compiler defines
above array as

  cl = subclass "FixedFloatArray", "num_Array_shape_3_3_3"

then this kind of array would be a distinct type. The other possiblity
is: we have one Multi_shaped_FloatArray, which takes an initializer with
the dimensions (see e.g. classes/multiarray.pmc) then all these shaped
num arrays would be one type, dispatching to the same routines.

> Thanks,
> /Autrijus/

leo


Re: Sun Fortress and Perl 6

2005-04-29 Thread Autrijus Tang
On Fri, Apr 29, 2005 at 02:35:26PM -0400, Aaron Sherman wrote:
> > Sure, but Parrot is not the compiler, it's just something I need to
> > target.  Hierarchical signature checking should probably not be done in
> > the VM level.
> 
> How do other languages call P6 subroutines and methods? Parrot has a
> rather sophisticated signature checking scheme built into it's MMD.
> Ignoring it and building your own will cost you heavily in performance.
> Using it and name-mangling will cost you in inter-language operation
> (Ponie comes to mind), and cost you slightly in performance.
> 
> Do we have enough call for this that it's worth the hit?

Well, complex hierarchical types is mandated by S06 and S09 already:

my sub get_book () of Hash of Array of Recipe {...}
my num @nums = Array of num.new(:shape(3;3;3));

Does Parrot's MMD carry this type information natively?  I think the
type information has to be encoded somehow anyway, and Ponie can then
reuse the same name-mangling to call into Perl 6 subroutines.

If you have specific issues w.r.t inter-language operation between
Perl 5 and Perl 6, I'd love to hear about it.  I do hope you are not
suggesting that we drop the Perl 6 type system to shoehorn into the
Perl 5's /prototype/ signature semantics, though. :-)

Thanks,
/Autrijus/


pgpwO47fKc5no.pgp
Description: PGP signature


Re: Sun Fortress and Perl 6

2005-04-29 Thread Aaron Sherman
On Fri, 2005-04-29 at 08:54, Autrijus Tang wrote:
> On Fri, Apr 29, 2005 at 08:33:56AM -0400, Aaron Sherman wrote:
> > > Currently per S09, Perl 6 collection types all have uniform types,
> > > so one has to use the `List of Any` or `Array of Any` return type
> > > instead.  That seriously hinders inference and typechecking; however,
> > > I wonder if it is a design decision already made... :)

> > I don't think Parrot would have any support for signature checking of
> > this sort... just a thought.

> Sure, but Parrot is not the compiler, it's just something I need to
> target.  Hierarchical signature checking should probably not be done in
> the VM level.

How do other languages call P6 subroutines and methods? Parrot has a
rather sophisticated signature checking scheme built into it's MMD.
Ignoring it and building your own will cost you heavily in performance.
Using it and name-mangling will cost you in inter-language operation
(Ponie comes to mind), and cost you slightly in performance.

Do we have enough call for this that it's worth the hit?

> > > 4. Software Transaction Memory
> > 
> > This is a good idea, but most of the things that it provides would
> > probably be better provided in a Parrot module, mocked up into each
> > client language in a module of their own, rather than as a core language
> > feature.
> 
> Sure, but saying atomic {} requires that the core Perl* PMCs has
> STM support built in.  Unless there is an easy way to swap out
> Perl* PMCs from underneath, I don't think that STM can be done
> as an extra add-on.

I'm not sure. I would think you could redefine them as needed, but I
don't know that.

> > > 7. AST definition
[...]
> > Isn't that called Pugs? ;-)
> 
> Not until Pugs is machine-translated to Perl 6, and having that
> form of AST definition in Perl 6 would help the process.  I think
> the translation needs to happen one way or another, anyway. :)

Yeah, yeah. I was joking.

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback




Re: Sun Fortress and Perl 6

2005-04-29 Thread Autrijus Tang
On Fri, Apr 29, 2005 at 08:33:56AM -0400, Aaron Sherman wrote:
> > Currently per S09, Perl 6 collection types all have uniform types,
> > so one has to use the `List of Any` or `Array of Any` return type
> > instead.  That seriously hinders inference and typechecking; however,
> > I wonder if it is a design decision already made... :)
> 
> I don't think Parrot would have any support for signature checking of
> this sort... just a thought.

Sure, but Parrot is not the compiler, it's just something I need to
target.  Hierarchical signature checking should probably not be done in
the VM level.

> > 4. Software Transaction Memory
> 
> This is a good idea, but most of the things that it provides would
> probably be better provided in a Parrot module, mocked up into each
> client language in a module of their own, rather than as a core language
> feature.

Sure, but saying atomic {} requires that the core Perl* PMCs has
STM support built in.  Unless there is an easy way to swap out
Perl* PMCs from underneath, I don't think that STM can be done
as an extra add-on.

> > 7. AST definition
> [...]
> > Is there something like it that exists somewhere for Perl 6?
> 
> Isn't that called Pugs? ;-)

Not until Pugs is machine-translated to Perl 6, and having that
form of AST definition in Perl 6 would help the process.  I think
the translation needs to happen one way or another, anyway. :)

Thanks,
/Autrijus/


pgpRtQ7YsJDkr.pgp
Description: PGP signature


Re: Sun Fortress and Perl 6

2005-04-29 Thread Aaron Sherman
On Wed, 2005-04-27 at 03:32, Autrijus Tang wrote:

> (via http://lambda-the-ultimate.org/node/view/673 )

LtU is a great site, BTW, I highly recommend it to anyone interested in
languages.

> There are a few things in that spec, though, that makes me wonder
> if Perl 6 should have it too:
[...]

> 2. Tuple types
> 
> sub foo () returns (Int, Bool, Array) {
> 
> Currently per S09, Perl 6 collection types all have uniform types,
> so one has to use the `List of Any` or `Array of Any` return type
> instead.  That seriously hinders inference and typechecking; however,
> I wonder if it is a design decision already made... :)

I don't think Parrot would have any support for signature checking of
this sort... just a thought.

> 3. Labels applies to blocks, not statements

I would say that this is a bad idea. We're keeping goto because it's
just darn useful for generated code, and for that same reason, it really
needs to be on a statement level, not a block level.

> 4. Software Transaction Memory

This is a good idea, but most of the things that it provides would
probably be better provided in a Parrot module, mocked up into each
client language in a module of their own, rather than as a core language
feature.

> 5. Macro model based on syntax expanders.

I'm pretty sure the combination of macros and grammar could easily
provide this in P6. It too is more of a module than a core language
feature, however.

> 6. Database-indexed module management
> 
> An embedded database (such as SQLite) can be used to track different
> revisions of installed modules on the local machine, manage upgrades,
> check api compatibility, and keep related logs;

And a darned good idea, that!

> 7. AST definition
[...]
> Is there something like it that exists somewhere for Perl 6?

Isn't that called Pugs? ;-)

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback




Re: Sun Fortress and Perl 6

2005-04-29 Thread Aaron Sherman
On Wed, 2005-04-27 at 09:46, Matt wrote:
> On Wed, 27 Apr 2005 03:32:12 -0400, Autrijus Tang <[EMAIL PROTECTED]>  
> wrote:
> > 3. Labels applies to blocks, not statements
[...]
> I've missed out on some Perl6 stuff, so excuse me as this was probably  
> already discussed.
> 
> Does that mean this is possible?

Keep in mind that you are replying to a description of Fortress, a sort
of "next generation FORTRAN" language specification from Sun, as it
could apply to Perl 6. The example was "perlish" (but note the lack of
";"s)

So, what you're asking is "if we did this kind of thing in Perl 6, would
this then be possible?"

Just clarifying.

PS: I read over the Fortress document last night after a friend who I
introduced to LtU had looked at it, and left it on my chair (I have such
good friends). It's a great read, and I recommend it. There are many
things in there that Perl 6 could snarf, but most of the really good
bits would probably be better just implemented as a grammar module.

I like the way you can lay out a matrix, and the auto-parallelization
stuff is kind of cool. By default a generator that you loop over with
for is parallelized, so:

for x â g do
action x
end

would perform the action for all values of x in an arbitrary and
potentially simultaneous order (threading where available). You can, of
course, request that such things happen sequentially if you want.

Then you get into the multi-generator loops:

for x â g1,
y â g2,
z â g3 do
action x, y, z
end

This would execute all permutations of x, y and z in parallel (or as
close to parallel as the execution environment allowed for).

Kind of neat.

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback




Re: Sun Fortress and Perl 6

2005-04-29 Thread Thomas Sandlaß
Autrijus Tang wrote:
1. Type variables as role parameters
> [..]
Curiously, A12 and S12 already allows something like that:
role List[Type $t] {
method first() returns ::($t);
method rest() returns List[::($t)];
method cons(::($t) $x) returns List[::($t)];
method append(List[::($t)] $xs) returns List[::($t)];
}
But I am not at all sure if this is the correct notation --
specifically, the "Type" type is not explained, and I'm not sure
how they are instantiated during the type checking phase at the
compile time.  Furthermore, I'm not sure that the ::($t) notation
is correct above.
Well, the ::() is the symbolic name syntax while ::Type is a
sigiled type/class/role etc. without prior declaration. This
is at least the way Damian used it. So the above could be
role List[ ::Type ]  # immediately introduces Type
{
method first() returns Type;
method rest() returns List[Type];
method cons(Type $x) returns List[Type];
method append(List[Type] $xs) returns List[Type];
}
Actually the same applies for all types:
my ::Foo $foo;
Even I don't know exactly when ::Foo has to be available at the latest.

-
2. Tuple types
sub foo () returns (Int, Bool, Array) {
I think we have that. It's
sub foo () returns :(Int, Bool, Array) {...}
If you like you could use :() for the sig as well.
And it might be applicable for variables, too.
my @a:( Int, Bool, Array) = (23, true, [1,2,3] );
my %h:( count => Int, state => Bool, data => Array )
= { count =>  23, state => true, data => [1,2,3] };
%h = "blubb";  # type error "no such field"
%h = 8;  # type error "%h:(Bool)"
A function type could be &:(Str,Int,Int):(Str) or so.
Actually &(Str,Int,Int):(Str) looks better.
But we have &foo:(Str,Int,Int) OTOH. So I'm unsure here.
Even sub foo():(Int) {...} might be OK.
In general I think we have:
  ( term )
 :( type spec )
::( symbolic ref/name )

-
3. Labels applies to blocks, not statements
Accordding to Luke that hasn't really been on the agenda.
But the postfix colon is heavily wanted elsewhere. With
Block as a Code subclass we might have:
block foo
{
   say "Hello!";
   say "Hi!";
}
Regards,
--
TSa (Thomas Sandlaß)


Re: Sun Fortress and Perl 6

2005-04-27 Thread Sam Vilain
Luke Palmer wrote:
`is pure` would be great to have! For possible auto-memoization of
likely-to-be-slow subs it can be useful, but it also makes great
documentation.
It's going in there whether Larry likes it or not[1].  There are so
incredibly many optimizations that you can do on pure functions, it's
not even funny.  Haha.  Er...
How about the one that goes further and also implies that the function
is strictly typed throughout;
  is ML
He'd love that, for sure!
:)
Sam.


Re: Sun Fortress and Perl 6

2005-04-27 Thread Matt
On Wed, 27 Apr 2005 03:32:12 -0400, Autrijus Tang <[EMAIL PROTECTED]>  
wrote:
3. Labels applies to blocks, not statements
Instead of this:
LABEL:
say "Hello!"
say "Hi!"
One has to write this (essentially creating named blocks):
LABEL: {
say "Hello!"
say "Hi!"
}
It makes sense because labels are frequently only used for block
control; the only thing that requires them at the statement level
is goto(), and you can still goto(LABEL) if you really want to.
I've missed out on some Perl6 stuff, so excuse me as this was probably  
already discussed.

Does that mean this is possible?
my Int $i = 0;
LABEL: {
say $i;
$i++;
next if $i < 5;
}
With no next/break/continue/whatever it is, the code block is executed  
only once.  But you still have the ability to treat it as a loop of sorts?

4. Software Transaction Memory
Yes! that would be awesome!  I've never used Haskell, but I can see the  
good uses for it :)



Re: Sun Fortress and Perl 6

2005-04-27 Thread Paul Johnson
On Wed, Apr 27, 2005 at 01:53:11AM -0600, Luke Palmer wrote:

> Juerd writes:
> > Autrijus Tang skribis 2005-04-27 17:04 (+0800):
> > > I can certainly see a `is pure` trait on Perl 6 function that declares
> > > them to be safe from side effects.  In a sense, `is const` also does that.
> > 
> > `is pure` would be great to have! For possible auto-memoization of
> > likely-to-be-slow subs it can be useful, but it also makes great
> > documentation.
> 
> It's going in there whether Larry likes it or not[1].  There are so
> incredibly many optimizations that you can do on pure functions, it's
> not even funny.  Haha.  Er...

For those too young to have had net access at the time, I'll note that
we have had a discussion along these lines before.  At that time most
people disliked the word "pure", but since then it would seem that for
some strange reason more people have been exposed to functional
programming.

  http://www.mail-archive.com/perl6-language@perl.org/msg11967.html

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net


Re: Sun Fortress and Perl 6

2005-04-27 Thread Nigel Sandever
On 27 Apr 2005 08:21:27 -, [EMAIL PROTECTED] (Rafael Garcia-Suarez) 
wrote:
> Autrijus Tang wrote in perl.perl6.language :
> >
> > 4. Software Transaction Memory
> >
> > Like GHC Haskell, Fortress introduces the `atomic` operator that takes a
> > block, and ensures that any code running inside the block, in a
> > concurrent setting, must happen transactionally -- i.e. if some
> > precondition is modified by another thread before this block runs
> > completely, then it is rolled back and tried again.  This slides covers
> > some aspects of STM as used in GHC:
> >
> > http://homepages.inf.ed.ac.uk/wadler/linksetaps/slides/peyton-jones.ppt
> >
> > In Fortress, there is also an `atomic` trait for functions, that
> > declares the entire function as atomic.
> 
> Interesting; and this rolling-back approach avoids the deadlock issues
> raised by the use of semaphores (like in Java's synchronization
> approach).
> 
> But, as the slides point out, you can't do I/O or syscalls from an
> atomic function; and in Haskell you can ensure that with the wise use of
> monads. Perl 6 has no monads, last time I checked...
> 

For an alternative approach to concurrency control, that sets out to be a 
possible future standard; specifically designed to address the shortcomings of 
Java's semaphores; that is in the public domain; has already been ported to 
several platforms in several langauges and is known to be implementable on both 
linux and win32; please see 

http://gee.cs.oswego.edu/dl/cpjslides/util.pdf

for the potted overview, and 

http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

for a fairly comrehensive examination.

Perl 6/Parrot probably doesn't need everything there, but it might form the 
basis for them.

njs




Re: Sun Fortress and Perl 6

2005-04-27 Thread Luke Palmer
Juerd writes:
> Autrijus Tang skribis 2005-04-27 17:04 (+0800):
> > I can certainly see a `is pure` trait on Perl 6 function that declares
> > them to be safe from side effects.  In a sense, `is const` also does that.
> 
> `is pure` would be great to have! For possible auto-memoization of
> likely-to-be-slow subs it can be useful, but it also makes great
> documentation.

It's going in there whether Larry likes it or not[1].  There are so
incredibly many optimizations that you can do on pure functions, it's
not even funny.  Haha.  Er...

[1] Of course if Larry doesn't like it (now _that's_ funny) then it will
go in a module that will be mysteriously tied to Perl 6's guts.

Luke


Re: Sun Fortress and Perl 6

2005-04-27 Thread Juerd
Autrijus Tang skribis 2005-04-27 17:04 (+0800):
> I can certainly see a `is pure` trait on Perl 6 function that declares
> them to be safe from side effects.  In a sense, `is const` also does that.

`is pure` would be great to have! For possible auto-memoization of
likely-to-be-slow subs it can be useful, but it also makes great
documentation.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: Sun Fortress and Perl 6

2005-04-27 Thread Autrijus Tang
On Wed, Apr 27, 2005 at 08:21:27AM -, Rafael Garcia-Suarez wrote:
> Autrijus Tang wrote in perl.perl6.language :
> >
> > 4. Software Transaction Memory
> > In Fortress, there is also an `atomic` trait for functions, that
> > declares the entire function as atomic.
> 
> Interesting; and this rolling-back approach avoids the deadlock issues
> raised by the use of semaphores (like in Java's synchronization
> approach).
> 
> But, as the slides point out, you can't do I/O or syscalls from an
> atomic function; and in Haskell you can ensure that with the wise use of
> monads. Perl 6 has no monads, last time I checked...

In Haskell there is an unsafeIOtoSTM call that lets you do IO inside
the atomic function; it's just that the IO is unsafe; it will be run
repeatedly and cannot be rolled back.

I can certainly see a `is pure` trait on Perl 6 function that declares
them to be safe from side effects.  In a sense, `is const` also does that.

Thanks,
/Autrijus/


pgpRTXAVSxXU6.pgp
Description: PGP signature


Re: Sun Fortress and Perl 6

2005-04-27 Thread Rafael Garcia-Suarez
Autrijus Tang wrote in perl.perl6.language :
>
> 4. Software Transaction Memory
>
> Like GHC Haskell, Fortress introduces the `atomic` operator that takes a
> block, and ensures that any code running inside the block, in a
> concurrent setting, must happen transactionally -- i.e. if some
> precondition is modified by another thread before this block runs
> completely, then it is rolled back and tried again.  This slides covers
> some aspects of STM as used in GHC:
>
> http://homepages.inf.ed.ac.uk/wadler/linksetaps/slides/peyton-jones.ppt
>
> In Fortress, there is also an `atomic` trait for functions, that
> declares the entire function as atomic.

Interesting; and this rolling-back approach avoids the deadlock issues
raised by the use of semaphores (like in Java's synchronization
approach).

But, as the slides point out, you can't do I/O or syscalls from an
atomic function; and in Haskell you can ensure that with the wise use of
monads. Perl 6 has no monads, last time I checked...

> 6. Database-indexed module management
>
> An embedded database (such as SQLite) can be used to track different
> revisions of installed modules on the local machine, manage upgrades,
> check api compatibility, and keep related logs; see Chapter 4 for
> details.  I have long wanted something like that for CPANPLUS, instead
> of the current, limited, nonversioned, unrevertable, partial information
> provided by .packlist files.

Plea : don't mess up with the job of the packagers and of the package
manangement systems. You can write one, or several, but you can't assume
they will be used, or that only one of them will be used at the same
time on the same system. I think that if somethings needs to be
standardised here is a complete, correct, useful metadata format (à la
META.yml).


Sun Fortress and Perl 6

2005-04-27 Thread Autrijus Tang
Fortress is Sun's project at making a next-generation computer language.
I like its technical report very, very much:

http://research.sun.com/projects/plrg/fortress0618.pdf
(via http://lambda-the-ultimate.org/node/view/673 )

Syntax aside (eg. their `=` and `:=` has the reverse meaning
in Perl 6), so far everything I'm seeing in it has a very close
correspondence to Perl 6, most notably the roles/traits system, use of
unicode symbols (see Appendix C for a cute way to transcribe unicode
programs in ASCII), and its creator's desire to make a language
optimized for evolvability.  Oh, and it has return type MMD. ;-)

There are a few things in that spec, though, that makes me wonder
if Perl 6 should have it too:

-

1. Type variables as role parameters

Fortress's List type is as this:

trait List [T]
first(): T
rest(): List [T]
cons(x: T): List [T]
append(xs: List[T]): List [T]
end

Curiously, A12 and S12 already allows something like that:

role List[Type $t] {
method first() returns ::($t);
method rest() returns List[::($t)];
method cons(::($t) $x) returns List[::($t)];
method append(List[::($t)] $xs) returns List[::($t)];
}

But I am not at all sure if this is the correct notation --
specifically, the "Type" type is not explained, and I'm not sure
how they are instantiated during the type checking phase at the
compile time.  Furthermore, I'm not sure that the ::($t) notation
is correct above.

-

2. Tuple types

sub foo () returns (Int, Bool, Array) {

Currently per S09, Perl 6 collection types all have uniform types,
so one has to use the `List of Any` or `Array of Any` return type
instead.  That seriously hinders inference and typechecking; however,
I wonder if it is a design decision already made... :)

-

3. Labels applies to blocks, not statements

Instead of this:

LABEL:
say "Hello!"
say "Hi!"

One has to write this (essentially creating named blocks):

LABEL: {
say "Hello!"
say "Hi!"
}

It makes sense because labels are frequently only used for block
control; the only thing that requires them at the statement level
is goto(), and you can still goto(LABEL) if you really want to.

-

4. Software Transaction Memory

Like GHC Haskell, Fortress introduces the `atomic` operator that takes a
block, and ensures that any code running inside the block, in a
concurrent setting, must happen transactionally -- i.e. if some
precondition is modified by another thread before this block runs
completely, then it is rolled back and tried again.  This slides covers
some aspects of STM as used in GHC:

http://homepages.inf.ed.ac.uk/wadler/linksetaps/slides/peyton-jones.ppt

In Fortress, there is also an `atomic` trait for functions, that
declares the entire function as atomic.

I mention this, instead of the more powerful automatic parallelization 
features, because STM can be retrofitted on any VM with boxed storage
types, while parallelization is a much harder problem that may not be
in Parrot's interest to tackle.

-

5. Macro model based on syntax expanders.

See section 3.4, "Support for Domain-specific Languages" in the
technical report.  For example, it allows:

syntax sql exp end escape ~ = parseSQL(exp)

Which defines, in Perl 6 terms, a `macro prefix:` that allows
the ~ symbol as an escape clause:

sub find_things (Field $thing) {
sql {
SELECT description FROM
SELECT ~$thing FROM things
}
}

The thing here is that all syntax error and type error is detected at
compile time, unlike the usual qq{} solution.

-

6. Database-indexed module management

An embedded database (such as SQLite) can be used to track different
revisions of installed modules on the local machine, manage upgrades,
check api compatibility, and keep related logs; see Chapter 4 for
details.  I have long wanted something like that for CPANPLUS, instead
of the current, limited, nonversioned, unrevertable, partial information
provided by .packlist files.

-

7. AST definition

Appendix A has "A Description of Fortress Abstract Syntax in Fortress
Concrete Syntax", which lays out the SyntaxTree class and all traits and
objects it may contain with Perl 6 concrete definitions.  I think this
will complement nicely with the Rule-based Perl 6 grammar file, as the
grammar itself does not neccessary contain AST information it generates.

Is there something like it that exists somewhere for Perl 6?

Thanks,
/Autrijus/


pgp