The thought process went something like this.
In a world of distributed perl data, we want an
expression like
foreach (grep { $_->{smoker} and $_->{age} > 18 } @Subscribers){
$->send($Cigarette_Advertisement)
}
to do the filtering on the machine that holds the subscribers
array, which is tied to something, and we want this to be
transparent, meaning we want to use grep rather than writing the
expression in SQL.
This would imply an extension of the array tieing interface,
so we can send the grep block to the data server, and get back
a generator object for foreach to shift qualifying subscribers
off of. Which implies having generators (aka iterators) in the
language. But thinking about how to make that interface as
simple as possible, one recalls that any C<grep> can be rewritten
as a C<map>
grep BLOCK B ARRAY A is map { $_ ? $_ : () } A;
so that's my macro definition syntax proposal.
BAREWORD+ is EXPRESSION ;
and the BAREWORD+ is the macro name, followed by TYPE, NAME
pairs, as in the example. The magic word that informs the
compiler that it's a macro definition is "is" but "means"
would work too.
Given arbitrarily precice typing in the bareword section,
this syntax would allow for early-as-reasonable bound type-based
subroutine/method polymorphism as well as simplifying the core
by allowing all the loop constructs to be written in terms
of C<while> and C<while> to be written in terms of C<if>
Please direct comments to [EMAIL PROTECTED]
which I am shocked to discover I never created before right now (!)
Back to creating generators from tied arrays, I think it might
be possible to set up by extending the array tieing interface to
have optional MAP and a SORT methods. Making those sane would
require an additional package-provided way to call functions on
the local machine, or possibly just to deparse the provided block
and do it all locally if it has methods in it that aren't safe to
send home to the server, or possibly a way to query a block as to
if it has any non-core methods in it. I think we can safely
assume that TRUTH and GREATER_THAN are going to mean the same thing
on our data server as they do on our mass mailer.
Am I making sense?
