Sun Fortress and Perl 6
Autrijus Tang
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:<sql>` 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/
Rafael Garcia-Suarez
>
> 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).
Juerd
> 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
Autrijus Tang
> Autrijus Tang wrote in perl.perl6.language :
> >
> > 4. Software Transaction Memory
> > 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/
Luke Palmer
> 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
Paul Johnson
> 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-l...@perl.org/msg11967.html
--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net
Nigel Sandever
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
Matt
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 :)
Sam Vilain
>>`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.
Thomas Sandlaß
> 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<foo> = "blubb"; # type error "no such field"
%h<state> = 8; # type error "%h<state>:(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ß)
Aaron Sherman
> On Wed, 27 Apr 2005 03:32:12 -0400, Autrijus Tang <autr...@autrijus.org>
> 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 <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Aaron Sherman
> (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? ;-)
Autrijus Tang
> > 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/
Autrijus Tang
> > 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.
>
> 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/
Aaron Sherman
> 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.