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
