### Featherweight Perl6.

Hi. Today I have started working on specifying and implementing Featherweight Perl6 (FP6), a side-effect-free subset of Perl6: http://autrijus.org/pugs/fp6/ # FP6, the language http://autrijus.org/pugs/ # Pugs, the implementation Since I am not well-versed in past Perl6 language discussions, my reading of Synopses is bound to be incorrect in many fundamental regards. For example, in the Some Example Code section, I have no idea why ([$x, @$xs]) does not need the slurpy star, but (*$x, [EMAIL PROTECTED]) does. (cf. S06, version 5, Unpacking array parameters.) I'm also a bit unclear on how to pattern-match a pair in subroutine signatures, as in the add_pair example. Also, is the all lists are lazy by default rule correctly used in the @squares and @fib examples? Is there a way to turn them into functions instead of arrays? Finally, the distributive laws and semantics for one() gives me troubles, as my intuition on how to evaluate one() is weak. As the implementation progresses, I'll probably bother the list with many of such naive questions. Thanks in advance for your patience. :-) Cheers, /Autrijus/ pgp50mSBIwRPd.pgp Description: PGP signature

### Re: Featherweight Perl6.

Autrijus Tang writes: Hi. Today I have started working on specifying and implementing Featherweight Perl6 (FP6), a side-effect-free subset of Perl6: http://autrijus.org/pugs/fp6/ # FP6, the language http://autrijus.org/pugs/ # Pugs, the implementation Awesome. This should be a good initial test for how well the language spec (so far) is holding together. Since I am not well-versed in past Perl6 language discussions, my reading of Synopses is bound to be incorrect in many fundamental regards. Yours too? :-) For example, in the Some Example Code section, I have no idea why ([$x, @$xs]) does not need the slurpy star, but (*$x, [EMAIL PROTECTED]) does. (cf. S06, version 5, Unpacking array parameters.) Okay, to quote (for those following along): multi sub length ([ $x, [EMAIL PROTECTED] ]) { 1 + @xs.elems } # why not *$x I think they're both valid. The point of the slurpy scalar is to provide list context to an argument that would otherwise be given scalar context. But when you're passing arrays that have little parameter lists inside, you're always in list context, so the slurpy star is a no-op. I'm also a bit unclear on how to pattern-match a pair in subroutine signatures, as in the add_pair example. Quoting: add_pair ::= - ($x = $y) { $x + $y } # valid? Hmm, defining subs like that is a little odd. But if you insist: add_pair ::= - Pair $x { $x.key + $x.value } That is, if it is declared to take a pair in that position, the named argument functionality is surpressed. Also, is the all lists are lazy by default rule correctly used in the @squares and @fib examples? Is there a way to turn them into functions instead of arrays? @fib ::= (1, 1, for zip(@fib;@fib[1...]) - { $^a + $^b }) I don't know why you're doing compile-time binding (::=) in this case. And you can't really embed a for inside an expression like that. That's why we have map: @fib := (1, 1, map { $^a + $^b } zip(@fib; @fib[1...])) And there are some subtle problems that could happen having to do with order of operations. I'll try my best to make this work in perl6, since I love this kind of thing. Finally, the distributive laws and semantics for one() gives me troubles, as my intuition on how to evaluate one() is weak. Mine too. I've never seen much use for one(). But you can think of all junctions as simply a set together with a boolean evaluation operation. They all distribute the same way; they nest inside each other with the associativity of the operator that they're distributing over (or from left to right if your in a function call or something). Where they differ is in boolean evaluation, and the semantics there are obvious. Evaluate recursively. (But things do get tricky when they have to return something---I'm not even sure we've hashed that out yet) As the implementation progresses, I'll probably bother the list with many of such naive questions. Thanks in advance for your patience. :-) Such naive questions are the only things we have to test the coherency of the design. Please, keep them coming. Luke

### Re: Featherweight Perl6.

On Wed, Feb 02, 2005 at 04:07:26PM -0700, Luke Palmer wrote: Also, is the all lists are lazy by default rule correctly used in the @squares and @fib examples? Is there a way to turn them into functions instead of arrays? @fib ::= (1, 1, for zip(@fib;@fib[1...]) - { $^a + $^b }) I don't know why you're doing compile-time binding (::=) in this case. Mostly because I've only started implementing ::= and not := (and certainly not =). And you can't really embed a for inside an expression like that. That's why we have map: @fib := (1, 1, map { $^a + $^b } zip(@fib; @fib[1...])) I have updated the page to have this instead: @fib ::= (1, 1, zip(@fib; @fib[1...]).map( $^a + $^b )) Can you explain how ::= is different from := here? Does ::= require all the RHS terms to be defined first, and := somehow allows for recursive let? Finally, the distributive laws and semantics for one() gives me troubles, as my intuition on how to evaluate one() is weak. Mine too. I've never seen much use for one(). But you can think of all junctions as simply a set together with a boolean evaluation operation. They all distribute the same way; they nest inside each other with the associativity of the operator that they're distributing over (or from left to right if your in a function call or something). Hmm. S09v4 says that conjunction (all) and injunction (none) are always distributed prior to abjunction (one) and disjunction (any). Where they differ is in boolean evaluation, and the semantics there are obvious. Evaluate recursively. (But things do get tricky when they have to return something---I'm not even sure we've hashed that out yet) Yes, in boolean context the intuition is obvious. I'm mostly puzzling over the behaviour in other contexts, both as values and (even more confusingly) as lvalues. As the implementation progresses, I'll probably bother the list with many of such naive questions. Thanks in advance for your patience. :-) Such naive questions are the only things we have to test the coherency of the design. Please, keep them coming. I will. :) Thanks, /Autrijus/ pgpdecrZKDaeF.pgp Description: PGP signature