Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

remote generators and a macro language proposal

0 views
Skip to first unread message

David Nicol

unread,
Jul 22, 2002, 2:19:19 AM7/22/02
to perl6-l...@perl.org, tern-d...@mail.freesoftware.fsf.org, poop-...@lists.sourceforge.net

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 tern-d...@mail.freesoftware.fsf.org
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?

Luke Palmer

unread,
Jul 22, 2002, 10:03:26 AM7/22/02
to tern-d...@mail.freesoftware.fsf.org, perl6-l...@perl.org, poop-...@lists.sourceforge.net
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 tern-d...@mail.freesoftware.fsf.org
> 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

Chip Salzenberg

unread,
Oct 10, 2002, 3:31:18 PM10/10/02
to Luke Palmer, perl6-l...@perl.org
According to Luke Palmer:

> for ( grep { $_{smoker} and $_{age} > 18 } @Subscribers ) {
> .send($Cigarette_Advertisement)
> }

Hm, would this work too:

for ( grep { .{smoker} and .{age} > 18 } @Subscribers )
{ .send($ciggie_ad) }

? I think .{x} reads better than $_{x} , esp. in parallel with the
method call in the same loop.
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"It furthers one to have somewhere to go."

Larry Wall

unread,
Oct 10, 2002, 8:16:50 PM10/10/02
to Chip Salzenberg, Luke Palmer, perl6-l...@perl.org
On Thu, 10 Oct 2002, Chip Salzenberg wrote:
: According to Luke Palmer:

: > for ( grep { $_{smoker} and $_{age} > 18 } @Subscribers ) {
: > .send($Cigarette_Advertisement)
: > }
:
: Hm, would this work too:
:
: for ( grep { .{smoker} and .{age} > 18 } @Subscribers )
: { .send($ciggie_ad) }
:
: ? I think .{x} reads better than $_{x} , esp. in parallel with the
: method call in the same loop.

Didn't see the original, but if those are attributes, why wouldn't
it just be:

for grep { .smoker and .age > 18 } @Subscribers {
.send($ciggie_ad)
}

'Course, this might be more readable:

for @Subscribers {
.send($ciggie_ad) if .smoker and .age > 18;
}

Most smokers don't know what "grep" means, after all...

Larry

0 new messages