On Mon, 22 Jul 2002, david nicol wrote:
>
> 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.
Nifty. Ooh, I like it. Btw, you're on the Perl 6 list, so:
for ( grep { $_{smoker} and $_{age} > 18 } @Subscribers ) {
.send($Cigarette_Advertisement)
}
> 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;
What's $_? You said the block is B and the array is A, so which one's the
topic? Did you mean ... is map { B ? B : () } 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.
Well, we've already discussed macros, but it didn't go anywhere, and I'd
like it to. First, that syntax isn't going to work. C<is> is already
used to assign compile-time properties. The syntax you're proposing
requires infinite lookahead (is that a problem, or not?). Also, how does
the reader know you're assigning a macro. There's nothing to stand out and
grab his attention saying "this is a macro."
I don't see what's wrong with C<macro>.
I don't think a macro could be a function-call-scope grammar change as I
was originally. It's hard to alter the grammar to include arbitrary code
between two arguments.
But it could be possible to use the ever-so-cool regex engine to solve
this particular problem. Assume C<macro> gets its arguments as strings.
grammar Perl6_to_SQL { ... }
macro grep($block, $array) {
$block =~ /<Perl6_to_SQL>/;
return { send_to_SQL_server($0{query}, $array); }
}
I mean, you get the idea. There's a lot of problems with what I just
wrote, the first being: "Why does macro get its arguments as strings while
it gets to give back a compiled bit of code?" But I figure this idea is a
start....
Also, how do we know to call the special SQL grep instead of the builtin
grep?
If only there was a clean way to introspect on compiled code... then we
wouldn't even need macros here. (Hint, hint)
> 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.
C<tie>ing is going to work quite differently, from what I hear. So it
might be possible to overload any function to call a special version when
your type of array is used. You just have to write all the special
versions.
> 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.
Erm, I'll go with the second one, or maybe the first. Not the third,
because "builtin" is getting so fuzzy.
> 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?
Sure. I think the idea is a very interesting problem. I'd like to know
if you've read the Apocalypses (for some definition of "read") and
Exegeses, because you seem to be thinking in Perl 5... which is allowed in
Perl 6, but not recommended.
Luke
