On Fri, Jan 11, 2008 at 01:56:44PM -0800, Dave Whipp wrote:
> S06 says that we need to say "eager" if (@in === @out). So:
>
> @data ==> eager map { $^x + 1 } ==> @data.
>
>
> Is it possible to modify a feed operator using the assignment meta-operator
> described in S02 and, if so, is the "eager" implict?
>
> @data ==>= map { $_ + 1 };
Nobody has actually implemented the feed operators yet, so what you
read about them is guesswork. In this case the word "spec" is short
for "speculation", and we'll get a better idea of how feeds interact
with mutable structures when we have an implementation to play with.
I don't profess to be smart enough to know the answer in advance.
As for assignment-op forms, in the current "STD" grammar, feeds are
not currently even considered operators, but statement separators, so
there is no possibility of using them in an assignment metaoperator
(or any other metaoperator, for that matter). Given that feeds
are intended to indicate one form of declarative parallelism, I
doubt there will be a lot of call for building mutating operators
out of them. I think that feeds are more properly in the realm of
functional programming, and side effects are generally to be avoided
in that mindset. Even without that, we do have to be careful not to
define @data in terms of itself accidentally.
Alternately, you can view feeds as the primitives in an event
processing system, but in that case the ends of a feed should be
viewed as independent processing elements. Use of the name of a
data structure like @data as a proxy for both a source and a sink
of data would need to be very carefully defined. And I think the
conservative thing here is to avoid defining that till we know more
about why anyone would want to represent an event loop with "@data".
Basically, my current view is that a data structure cannot be
considered both a source and a sink without some mechanism for
keeping the new values from clobbering the old ones. With shell
pipes, that usually involves copying the data somewhere along the
way, even if that is hidden by replacing the inode under a filename.
Feedback loops can be a very powerful way of generating data in a
language with as powerful a type system as, say, Haskell, but I don't
think Perl aiming to be in that brainspace. Arbitrary restrictions
will likely be needed until all the implementations can agree on
what's possible and practical in the base language or in extensions.
Larry
