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 in
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 d
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,
Damian Conway wrote:
So I'm going to go on to propose that we create a fifth class of
Junction: the "transjunction", with corresponding keyword C.
[...]
say (^10 G[<] one(3,7));
3 4 5 6
which could also be:
say every(^10) < one(3,7);
# Every value up to 10 that's greater than 3 or
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 li
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)
extra
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 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 caveat that ther
yary wrote:
> +1 on this
> On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang 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
>>
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 calli
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
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. Re
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 set
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 sh
Branch: refs/heads/master
Home: http://github.com/perl6/specs
Commit: 32511f7db34905c740ed1030a70995239f7cfb66
http://github.com/perl6/specs/commit/32511f7db34905c740ed1030a70995239f7cfb66
Author: TimToady
Date: 2010-10-25 (Mon, 25 Oct 2010)
Changed paths:
M S02-bits.pod
Log Message:
Jon Lang wrote:
> Personally, I don't think that it should be a public method: one thing
> about junctions is that you can use them interchangeably with ordinary
> scalars; giving them a public method breaks that. In particular, code
> that makes use of a Junction public method would break if you
Branch: refs/heads/master
Home: http://github.com/perl6/specs
Commit: 60aef3acd56f47b5a78721ca886b9fd3e22b366e
http://github.com/perl6/specs/commit/60aef3acd56f47b5a78721ca886b9fd3e22b366e
Author: TimToady
Date: 2010-10-25 (Mon, 25 Oct 2010)
Changed paths:
M S02-bits.pod
M S06-routi
17 matches
Mail list logo
