Re: Sun Fortress and Perl 6
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] };
%hfoo = blubb; # type error no such field
%hstate = 8; # type error %hstate:(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
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
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
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: Quickcheck of context of index expressions
On Tue, Apr 26, 2005 at 03:33:44AM +0800, Autrijus Tang wrote: : Another quick check on expression context for indexed expressions. : Please sanity-check the return value of want() below: : : @x[0] = want(); # scalar context Good. : @x[want()] = $_; # scalar context : @x[want()] = @_; # scalar context Maybe unknown context, which defaults to list. : @x[0,] = want(); # list context : @x[want(),] = $_; # list context : @x[want(),] = @_; # list context : $_ = @x[want()]; # scalar context : @_ = @x[want()]; # list context No, I think they're all list context. Larry
Re: Quickcheck of context of index expressions
On Tue, Apr 26, 2005 at 03:56:37AM +0800, Autrijus Tang wrote:
: On Tue, Apr 26, 2005 at 03:33:44AM +0800, Autrijus Tang wrote:
: Another quick check on expression context for indexed expressions.
: Please sanity-check the return value of want() below:
:
: @x[0] = want(); # scalar context
: @x[want()] = $_;# scalar context
: @x[want()] = @_;# scalar context
: @x[0,] = want();# list context
: @x[want(),] = $_; # list context
: @x[want(),] = @_; # list context
: $_ = @x[want()];# scalar context
: @_ = @x[want()];# list context
:
: Oh, and under the S02 rules above (the index expression inherits
: outer context on RHS), Pugs currently does this:
:
: $_ = %x{ 1, 2 }
: --- reduces to ---
: $_ = %x{ [1, 2] }
: --- reduces to ---
: $_ = %x{ 1 2 }
:
: Which is, well, very surprising. Where did I get wrong?
I think S02 is probably wrong. It should be unknown/list context.
Sorry for the short answers, but I'm in Russia behind a flakey network
connection, which is probably going away entirely at any moment (the
network connection, not Russia.) I can clarify more next week when
I get back.
Larry
Re: Quickcheck of context of index expressions
On Fri, Apr 29, 2005 at 06:22:57AM -0700, Larry Wall wrote: : @x[want()] = $_; # scalar context : @x[want()] = @_; # scalar context Maybe unknown context, which defaults to list. I think allowing unknown LHS index expression to default to scalar context is a bit more useful here. Since we have: @x[0] = @y;# scalar @x[0,] = @y;# list This may be more intuitive: @x[idx()] = @y;# scalar @x[idx(),] = @y;# list Than this: @x[+idx()] = @y;# scalar @x[idx()] = @y;# list But I don't really feel strongly one way or another, as long as it is specced down. :) Thanks, /Autrijus/ pgpQVFZNKCIEY.pgp Description: PGP signature
Re: Quickcheck of context of index expressions
On Fri, Apr 29, 2005 at 06:22:57AM -0700, Larry Wall wrote: : @x[want()] = $_; # scalar context : @x[want()] = @_; # scalar context Maybe unknown context, which defaults to list. : @x[0,] = want(); # list context : @x[want(),] = $_; # list context : @x[want(),] = @_; # list context : $_ = @x[want()]; # scalar context : @_ = @x[want()]; # list context No, I think they're all list context. Okay. r2478 has them reverted to the original form, which inspects the declared return type of want() to see if it is a subtype of Scalar; if it is, then it is taken as scalar context; otherwise (or if multiple multisubs are possible), it defaults to list context. Thanks, /Autrijus/ pgp0HZ5CR3H7H.pgp Description: PGP signature
S04 -- closure traits clarification
Greetings,
In trying to hack closure trait support into pugs, I have some
questions about closure traits, variable with will traits and
introspection. (Apologies if some of this has been discussed on the
list before -- I'm just going off of the synopses, which if definite
clarification on some of these issues has been made, should probably be
updated to reflect the decisions made.)
Firstly, it is suggested in S04 that variables indicated with a will
predicate contribute to the corresponding block-level trait. I.e., if
we have the following bit of code:
if $dbh {
my $sth will undo {$dbh.rollback} will keep {$dbh.commit} = FIRST
{$dbh.prepare($query)};
UNDO {
say DB error!;
}
KEEP {
say We're good!;
}
}
Then the block has in effect 5 total traits, 2 UNDO block, 2 KEEP
blocks and 1 FIRST blocks. From what I understand, the blocks for each
trait are executed in FIFO order, thus we would rollback before we
report the error in this contrived example.
Questions:
1) What type of introspection, if any, are we providing to the language
level? I.e., are we providing something along the lines of
%traits = ?BLOCK.traits
where %traits is keyed on trait name (FIRST, LAST, whatever) and in
turn is an array of closures? This would mean, for instance that we
could say
?BLOCK.traitsFIRST
to get the current block's FIRST closures, if any. When parsing the
block for traits, coming across a new FIRST block would be akin to
saying:
push ?BLOCK.traitsFIRST, {...block contents...}
Specifically, I'm looking for definition of the syntax, which is only
alluded to in the Synopsis.
2) If we accept the introspection at the block-level above, it seems
clear that we should also accept the same .traits method on variables.
I.e., in the above DBI example, we should get back the closure(s) for
undoing by referring to $sth.traitsUNDO. Is a variable-level trait a
single entry, or can we have multiple will undo {...} predicates on a
single variable? (The utility of such is left as an exercise to the
reader.)
3) User-definable traits. Now, this may be a closed domain of sorts,
but do we need to allow for the possibility of user-defined traits?
(I'm thinking here of variable-level will predicates.) If so, do
user-defined traits get normalized to UPPER? It would seem like we
would want consistency here, because if will undo {...} and UNDO
{...} get stored in the same trait slot, we're obviously transforming
one of the identifiers -- should this behavior be specific to our
built-in ones, or to all traits?
4) Which of the closure traits are supported as will predicates on
variables? Not all of the closure traits make sense on the
variable-level -- this information will be useful when trying to parse
the will predicates.
Thanks,
David Christensen
Re: S04 -- closure traits clarification
David Christensen writes:
Greetings,
In trying to hack closure trait support into pugs, I have some
questions about closure traits, variable with will traits and
introspection. (Apologies if some of this has been discussed on the
list before -- I'm just going off of the synopses, which if definite
clarification on some of these issues has been made, should probably be
updated to reflect the decisions made.)
Firstly, it is suggested in S04 that variables indicated with a will
predicate contribute to the corresponding block-level trait.
Not really. `will` is just defined as:
$a will foo {...}
Is the same as:
$a is foo({...})
So it's up to foo to associate itself with the block.
I.e., if we have the following bit of code:
if $dbh {
my $sth will undo {$dbh.rollback} will keep {$dbh.commit} = FIRST
{$dbh.prepare($query)};
UNDO {
say DB error!;
}
KEEP {
say We're good!;
}
}
Then the block has in effect 5 total traits, 2 UNDO block, 2 KEEP
blocks and 1 FIRST blocks. From what I understand, the blocks for each
trait are executed in FIFO order, thus we would rollback before we
report the error in this contrived example.
Nope. Entry-time blocks are executed in declaration order. Exit-time
blocks are executed in reverse declaration order. Just like CHECK and
END in Perl 5.
Questions:
1) What type of introspection, if any, are we providing to the language
level? I.e., are we providing something along the lines of
%traits = ?BLOCK.traits
where %traits is keyed on trait name (FIRST, LAST, whatever) and in
turn is an array of closures? This would mean, for instance that we
could say
?BLOCK.traitsFIRST
to get the current block's FIRST closures, if any. When parsing the
block for traits, coming across a new FIRST block would be akin to
saying:
push ?BLOCK.traitsFIRST, {...block contents...}
Specifically, I'm looking for definition of the syntax, which is only
alluded to in the Synopsis.
What you are saying here seems reasonable. However, we have to remember
that the closures are different for each run. So the traits are not
associated with the block, but with the particular runtime instance of
the block. Maybe that's what ?BLOCK refers to anyway.
I wonder how you could talk about the traits of a sub that isn't
currently executing.
2) If we accept the introspection at the block-level above, it seems
clear that we should also accept the same .traits method on variables.
I.e., in the above DBI example, we should get back the closure(s) for
undoing by referring to $sth.traitsUNDO. Is a variable-level trait a
single entry, or can we have multiple will undo {...} predicates on a
single variable? (The utility of such is left as an exercise to the
reader.)
The question is, are you asking about the variable or the value? For
instance:
my $block = ?BLOCK; # _not_ calling
$block.traits;# variable traits or ?BLOCK traits?
We probably just use whatever the equivalent of `tied` is these days.
Let's call it, er, `tied`.
$block.traits; # ?BLOCK traits
(tied $block).traits; # variable traits
3) User-definable traits. Now, this may be a closed domain of sorts,
but do we need to allow for the possibility of user-defined traits?
No. By which I mean OF COURSE!
(I'm thinking here of variable-level will predicates.) If so, do
user-defined traits get normalized to UPPER?
No. Block level traits are different from variable traits, and they
should be declared separately. The variable trait `undo` for instance
probably just pushes an UNDO handler on its caller. Likewise, the UNDO
macro (?) does precisely the same thing.
But people are allowed to declare traits that are all caps, and block
handlers which are lowercase, and any combination of the above. Perl
culture will try to enforce against that, however.
It would seem like we would want consistency here, because if will
undo {...} and UNDO {...} get stored in the same trait slot, we're
obviously transforming one of the identifiers -- should this behavior
be specific to our built-in ones, or to all traits?
4) Which of the closure traits are supported as will predicates on
variables? Not all of the closure traits make sense on the
variable-level -- this information will be useful when trying to parse
the will predicates.
Hmm, not quite sure. Traits are a pretty big thing, and I'm not sure
what it buys you to hack them in. I'd start by implementing the block
handlers without variable traits.
Luke
Re: Junctions of classes, roles, etc.
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote: so we had junctions of Code references some days ago, what's with junctions of Class and Role objects? :) Could we see some code that shows why this is a good idea? My initial reaction is horror; I can very easily see huge numbers of subtle, hard-to-reproduce bugs coming out of this. On the other hand, I do not immediately see major applications...most of what I can see is things that reduce the amount of code needed, but don't actually accomplish anything fundamentally new. What do junctions of Class|Role objects give us that can't be achieved in other ways? I'm quite willing to believe that there are such things, but I'm not coming up with them. --Dks
Re: Sun Fortress and Perl 6
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
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: Junctions of classes, roles, etc.
David Storrs [EMAIL PROTECTED] wrote:
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
Could we see some code that shows why this is a good idea? My initial
reaction is horror; I can very easily see huge numbers of subtle,
hard-to-reproduce bugs coming out of this. On the other hand, I do
not immediately see major applications...most of what I can see is
things that reduce the amount of code needed, but don't actually
accomplish anything fundamentally new. What do junctions of
Class|Role objects give us that can't be achieved in other ways?
I'm quite willing to believe that there are such things, but I'm not
coming up with them.
What do you think this is?
sub foo(Str | Int $bar) { ... }
Or this one, which is even more important?
sub foo(Any | Junction $bar) { ... }
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
