On Tue, 29 Oct 2002, Larry Wall wrote:
> Maybe we should just say that you can put it anywhere that makes sense,
> and let the perl parser sort out the sheep from the goats. The basic
> rule is that for any op, [op] is also expected in the same place.
It would be nice to have a fully generalized set of applicative
manipulators. The basic set in applicative languages like Haskell generally
includes map, zip, fold and do; from these others can be constructed, but
for efficiency in an imperative language we'd probably want a few more like
apply and cross-product.
It strikes me that [op] is a composition of yet more basic facilities; thus
@a [+] @b
would be something like
map { $_[0] + $_[1]) } zip @a, @b
In general it would be nice to be able to make shorthands for arbitrary
compositions; eg, with some definition for "zip" that results in the above,
one could then go simply
@a zip:+ @b
which while not as short as @a [+] @b, is more obviously a specific instance
of a more general construct.
-=*@*=-
Apropos substitution, I still like the idea of having matched sub-strings as
magic L-values. I think the ".=" assignment operator makes this a lot more
feasible than simply using a straight assignment, which as Larry mentioned
before would be problematic with its right-to-left evaluation. But for an
assignment operator that needn't necessarily be the case, and indeed
implicitly is not the case. Using the ".=" operator, we could have:
Perl5: Perl6:
$a =~ s/\d/X/; $a ~ /(\d)/ = "X";
$a =~ s/\d/X/g; $a ~ /(\d)/ [=] "X";
$a =~ s/\d/ ($&+1)%10 /eg; $a ~ /(\d)/ [.=] { ($_+1)%10 };
Or if you don't like switching from = to .=, just stick with ".=" and define
that ".literal" always returns the literal, after evaluating and discarding
the LHS, and ".=literal" likewise evaluates the LHS, then sets the LHS to
the literal value.
> So if the user defines a postfix:! for factorial, they automatically get
> _[!] for that as well.
postfix vs infix ... mumble ... parsing nightmare ... mumble ...
> I think we could also allow
>
> @a [??] @b [::] @c
>
> But it's not clear whether we can parse
>
> @a = [undef][...]
What about
$a = $x lazy:? $y : $z
so that $a is thus an object which when stringified (or numified or
whatever) chooses whether it's $y or $z, but not until?
-Martin
