On Oct 22, 6:41 pm, dam...@conway.org (Damian Conway) wrote:
Dave Whipp wrote:
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narrow purpose
for which they were introduced.
Hmm. There are
I know that perl6 has / will have lazy strings, since (in
S32::Containers) the List role defines a cat method, which returns a
Cat object, which does the Str interface, but generates the string
lazily.
First, are Cat objects documented anywhere else?
Secondly, if a regular expression match is
Ben Goldberg asked:
I'm probably missing something, but wouldn't it have been easier to
write that module by using eval STRING to create all of those infix
operators?
Sure. But the module is already slow to start up. I was concerned
that it would get even slower with an embedded eval. But, in
Dave Whipp noted:
I think that the two proposals are equivalent, in the sense that either can
be trivially implemented using the other.
Agreed.
However, I am a little concerned that the transjunction magically changes
an operator that returns a Boolean value into one that returns a list.
Damian Conway wrote:
Yes, Ted Z. pointed out to me that, as the name of this construct,
every has ambiguity and synonym issues. Other possibilities are:
select(@values) one(3..7)
those(@values) one(3..7)
whichever(@values) one(3..7)
itemize(@values) one(3..7)
First off, let me weigh in on Damian's original point: I agree that
Junction!eigenvalues should be renamed to more accurately reflect what
it is (perhaps to something like Junction!seedvalues, since what it's
really trying to produce is a list of the values that it's using to
define the Junction),
+1 on this
On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang datawea...@gmail.com wrote:
As for the bit about sets vs. lists: personally, I'd prefer that there
not be quite as much difference between them as there currently is.
That is, I'd rather sets be usable wherever lists are called for, with
the
yary wrote:
+1 on this
On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang datawea...@gmail.com wrote:
As for the bit about sets vs. lists: personally, I'd prefer that there
not be quite as much difference between them as there currently is.
That is, I'd rather sets be usable wherever lists are called
That sounds like a subclass of Bag to me.
But I don't think that thinking about who is subclassing whom is is how to
think about this in Perl 6. All of these types are capable of doing the
Iterable role, and that is what methods that could operate on a List, Array,
Bag, or Set, should be
Sorry:
I meant capable *in theory*. It's not in the spec right now for Sets or Bags.
On Oct 25, 2010, at 08:41 PM, Mason Kramer wrote:
That sounds like a subclass of Bag to me.
But I don't think that thinking about who is subclassing whom is is how to
think about this in Perl 6. All of
Mason Kramer wrote:
But I don't think that thinking about who is subclassing whom is is how to
think about this in Perl 6. All of these types are capable of doing the
Iterable role, and that is what methods that could operate on a List, Array,
Bag, or Set, should be calling for.
This.
yary wrote:
I think of a list conceptually as a subclass of a set- a list is a
set, with indexing and ordering added. Implementation-wise I presume
they are quite different, since a set falls nicely into the keys of a
hash in therms of what you'd typically want to do with it.
If a list is a
Darren Duncan wrote:
If a list is a set, does that mean that a list only contains/returns each
element once when iterated? If a list can have duplicates, then a list
isn't a set, I would think. -- Darren Duncan
Thus Mason's point about Bags. Really, I think that Mason's right in
that we
Branch: refs/heads/master
Home: http://github.com/perl6/specs
Commit: 32511f7db34905c740ed1030a70995239f7cfb66
http://github.com/perl6/specs/commit/32511f7db34905c740ed1030a70995239f7cfb66
Author: TimToady la...@wall.org
Date: 2010-10-25 (Mon, 25 Oct 2010)
Changed paths:
M
14 matches
Mail list logo
