[#4766] Wiki — "Glen Stampoultzis" <trinexus@...>

21 messages 2000/09/04
[#4768] RE: Wiki — "NAKAMURA, Hiroshi" <nahi@...> 2000/09/04

Hi, Glen,

[#4783] Re: Wiki — Masatoshi SEKI <m_seki@...> 2000/09/04

[#4785] Re: Wiki — "NAKAMURA, Hiroshi" <nakahiro@...> 2000/09/05

Howdy,

[#4883] Re-binding a block — Dave Thomas <Dave@...>

16 messages 2000/09/12

[#4930] Perl 6 rumblings -- RFC 225 (v1) Data: Superpositions — Conrad Schneiker <schneik@...>

Hi,

11 messages 2000/09/15

[#4936] Ruby Book Eng. translation editor's questions — Jon Babcock <jon@...>

20 messages 2000/09/16

[#5045] Proposal: Add constants to Math — Robert Feldt <feldt@...>

15 messages 2000/09/21

[#5077] Crazy idea? infix method calls — hal9000@...

This is a generalization of the "in" operator idea which I

17 messages 2000/09/22

[#5157] Compile Problem with 1.6.1 — Scott Billings <aerogems@...>

When I try to compile Ruby 1.6.1, I get the following error:

15 messages 2000/09/27

[ruby-talk:4994] Re: Perl 6 rumblings -- RFC 225 (v1) Data: Superpositions (fwd)

From: schneik@...
Date: 2000-09-18 18:33:27 UTC
List: ruby-talk #4994


Michael G. Schwern wrote:

# On Mon, Sep 18, 2000 at 10:35:49AM +0000, John Carter wrote:
# > This looks like a well flung gauntlet for the wizards of AUTOLOAD (or
# > something)
# >
# > Someone took the Perl 6 RFC 225 Data Superpositions paper and sent it
to
# > ruby talk.
# >
# > Matz the author of ruby promptly demonstrated the power and cleanness
of
# > the Ruby iterators.
#
# I don't think its quite understood *what* RFC 225 is proposing.

That *was* correct, although the initial misunderstanding looks like it
will produce some useful additions to Ruby.

# any()
# and all() aren't just some sort of glorified grep() operators.  Its
# quantum superpositions!

Alternatively, one might say that the misunderstood variants of any() and
all() were *insufficiently* glorified, i.e. that correctly understood that
they are really super-glorified grep() operators.

Anyway, Mathiew Bouchard already pointed out this discrepancy, although no
one has addressed it yet. (Perhaps this is due to the change of
thread/subject line, perhaps because it is more difficult, or perhaps
because some key people are toiling away on English Ruby books or the
imminent release of Ruby 1.6.0).

In any case, thanks much for your followup--hopefully your even more
informative post will produce even more interesting results.

Mathieu Bouchard wrote:
>
> > |>         if (any(@value) < 10) { ... }
> > |>         die unless all(@tests)->($data);
> > |> ought to be available to all Perl users.
> >
> > This can be easily accomplished by the method like
> >   module Enumerable
> >     def any; self.each do |item| return true if yield(item); end
> >       return false; end
> >     def all; self.each do |item| return false unless yield(item); end
> >       return true; end; end
> > Pretty easy huh?
>
> The two are somewhat different. What you propose is two short-circuited
> applications of Enumerable#inject (See end of faq). I would like to see
> them in Enumerable (but I would like to see #inject before that)
>
> (insert strong australian accent here)
>
> What Damian proposes is that instead of wrapping an expression in a
bunch
> of any/all blocks, you could insert "any" and "all" specifiers _inside_
> the expression. This could mean that [1,2,3].any would do is mimic all
the
> objects it contains at once, and that every message sent to that
> collective would be dispatched to all contained objects, and their
results
> would be combined in a new "any" object containing all the results;
> eventually, when the value of a Boolean Collective is observed,
something
> magical happens ("collapsing of states") which OR's the members of the
> Collective together and gives a result.
>
> Damian says it's to emulate quantum-computing constructs in a current
> computer, but I think he's really trying to market Prolog/Icon's
> goal-directed programming concepts to the Perl masses.
>
> I admit I have some difficulty separating the concepts of inject-based
> functions and goal-directed computing, from a point of view of result
> (maybe because it's been a while since i last used/seen
> goal-directedness, apart from regexps). The notation and execution is
> however different.
>
> I'd like it very much if someone would post examples of a goal-directed
> expression that is non-trivial (or convoluted) to write using Matz'
> any/all functions.
>
> PS: now that I think of it, collapsed 'true' booleans in expressions
> containing 'any' are tagged with the values of 'any' that produced the
> 'true'... or something like that.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)



In This Thread

Prev Next