Re: Tweaking junctions
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 intentions, and then there are intentions. I know what I intended when I invented the original idea, and it wasn't just the narrow purpose for which they were added to Perl 6. :-) Problem 2 could be solved by defining a new (and public!) C.eigenstates method in the Junction class. [...] I think that you're proposed solution is a bit too specific: That's because I didn't explain Part B of my nefarious plan! namely that, if you'd only give me proper eigenstates, I'd give you an even nicer alternative. I actually think that the meta doesn't belong on the operator at all (though I have no problem with that idea in itself). Instead, I think the meta should be placed on the data (which, of course, is what any(), all(), one(), and none() already do). So I'm going to go on to propose that we create a fifth class of Junction: the transjunction, with corresponding keyword Cevery. [snip] 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? Start with a list of the names of the operators, generate a string containing all four argument variations for each operator, then eval it.
Lazy Strings and Regexes
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 done on a lazy string, is that lazy string turned into a normal string? If we can efficiently match against a lazy string, and if this doesn't turn the lazy string into a (large) normal string, then the best way to process a file might be something similar to: my $fh = open ... err die; my $contents = cat($fh.lines); , followed by matching on $contents. Better still would be to provide a way for filehandles to be directly asked to produce a lazy Str which reflects the file.
Re: Tweaking junctions
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 the name of maintainability, I probably should benchmark it both ways. Thanks for pointing that out, Ben. Damian
Re: Tweaking junctions
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 Cevery.
[...]
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 7 but not both
[...]
I just think those all read much better than the (otherwise excellent)
meta-operator. In much the same way that the existing junctive types
read better than their functional or operator-oriented alternatives.
I think that the two proposals are equivalent, in the sense that either
can be trivially implemented using the other. So it is indeed a question
of which one reads better and fits in better. And I agree, your Cevery
proposal does read better (at least to an English speaker).
However, I am a little concerned that the transjunction magically
changes an operator that returns a Boolean value into one that returns a
list. If the usage of a transjuction is non-local to its creation then
this could result in surprises, and hence frustrating debugging sessions.
If I wanted to write intentionally confusing code (which sometimes
happens due to carelessness) then I might take advantage of the fact
that Cevery is, in English, a synonym for Call, not Cany:
if every(@values) one(3..7) {...}
I'd like these in the core language (for performance and universal
accessibility), but if not, I already have a nearly-complete
implementation of a module implementing them, which runs successfully on
the current release of Rakudo*. I append said model for your amusement
(and suggestions!).
++
Dave.
Re: Tweaking junctions
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.
Technically, it turns the operator into one that returns a transjunction.
The surprise occurs because tranjunctions self-eigenvalue in a list context.
That's a huge convenience in direct usages, but not an essential component
of the proposal if indeed it proves too surprising in indirect usages.
However, if we did lose that feature then usages like:
say eigenvalues every(@number) one(3,7);
sacrifices more than a little of the construct's original appeal, I think.
If I wanted to write intentionally confusing code (which sometimes happens
due to carelessness) then I might take advantage of the fact that Cevery
is, in English, a synonym for Call, not Cany:
if every(@values) one(3..7) {...}
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)
extract(@values) one(3..7)
...of which, only Cselect really seems a good alternative.
Any other suggestions most welcome!
Damian
Re: Tweaking junctions
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) extract(@values) one(3..7) ...of which, only Cselect really seems a good alternative. Any other suggestions most welcome! My suggestion is, of course, to move it to the operator: @values G one(3..7) which has a pleasing (to my mind) symmetry with Perl6-isms such as @values X* 2 Failing that, perhaps Cfilter might work (though I always find myself wanting to qualify a filter as either filter-in or filter-out).
Lists vs sets
+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 caveat that there's no guarantee about the order in which you'll get the set's members; only that you'll get each member exactly once. The current approach is of much more limited value in programming. 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.
Re: Lists vs sets
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 for, with the caveat that there's no guarantee about the order in which you'll get the set's members; only that you'll get each member exactly once. The current approach is of much more limited value in programming. 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 terms of what you'd typically want to do with it. By implementation-wise, are you referring to under the hood details? If so, I agree: it's OK to implement a set internally as a hash. But as far as the user is concerned, it ought to look like a list. Well, technically, a list should look like a set that has additional features. But as Damian pointed out earlier, one reason why he chose to use lists in his transjunction module instead of sets is that as they are now, you can iterate over a list; but you can't iterate over a set. From a practical standpoint, sets would be considerably more attractive if you could iterate over them as well without having to first turn them into lists via the .k method. Thus my suggestion to treat a set as a list of unique values without a guaranteed order, at least as far as the user is concerned. -- Jonathan Dataweaver Lang
Re: Lists vs sets
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 calling for. On Oct 25, 2010, at 08:08 PM, 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 for, with the caveat that there's no guarantee about the order in which you'll get the set's members; only that you'll get each member exactly once. The current approach is of much more limited value in programming. 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.
Re: Lists vs sets
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 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. On Oct 25, 2010, at 08:08 PM, 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 for, with the caveat that there's no guarantee about the order in which you'll get the set's members; only that you'll get each member exactly once. The current approach is of much more limited value in programming. 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.
Re: Lists vs sets
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. Really, as long as Set does Iterable, it's not as important if it's treated as hash-like or list-like - though I'd still prefer to deal with @sets rather than %sets. Conceptually, it feels like a better fit. -- Jonathan Dataweaver Lang
Re: Lists vs sets
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, 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
Re: Lists vs sets
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 should be looking as which roles each of these does rather than which classes each of them is. -- Jonathan Dataweaver Lang
[perl6/specs] 32511f: [S02] be more explicit about iterating sets/bags
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 S02-bits.pod Log Message: --- [S02] be more explicit about iterating sets/bags The intent has always been that when you use a set or bag as a list, it behaves as a list of its keys, regardless of any underlying hash interface it might also respond to. You must use .pairs explicitly to get the hash pairs out of a set or bag as a list.
