[#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:4948] Re: Perl 6 rumblings -- RFC 225 (v1) Data: Superpositions

From: schneik@...
Date: 2000-09-17 00:55:15 UTC
List: ruby-talk #4948


Dave Thomas wrote:

# Mark Slagell <ms@iastate.edu> writes:
#
# > At first glance, I like the idea of any/all -- they seem to have broad
# > applicability.
# >
# > Alternative name suggestions: "any_satisfies" and "all_satisfy" are
# > more descriptive but a bit long - maybe just adding question marks
# > would be good: "any?" and "all?".
#
# I like any? and all? We might want to make 'exists?' an alias for
# 'any?', and 'none?' == '!all?'.

And 'some?' for 'any?' as well, to complement 'none?'.

# Could I also vote for 'count'
#
#     thing.count { |i| i > 3 }

Yes, we'll count that as a vote. :-)  Make that two votes.

# Then... do we add it to Enumerable, so do we put it in a separate
# library
#
#    module Enumerable
#       include Existential
#
#   end
#
# Why do this? Two reasons. First, it avoids cluttering Enumerable
# (that's a poor reason). The second is that we get to play with it
# before committing changes to the interpreter.

Which means that people will likely play with a substantially wider range
of potentially useful things than otherwise, which is desirable for
maximally improving Ruby.

# I'm thinking that we
# implement it in Ruby, and put the source in lib/. We then see if it is
# useful and if it is actually used. If so, and if the performance hit
# of implementing it in Ruby proves to be too great, we can then move it
# in the the C source.
#
# In general, I'm thinking that this is a good way to do all kinds of
# new features: implement them first in Ruby before adding bulk to the
# interpreter.

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



In This Thread

Prev Next