Re: IO Multiplexing
On Fri, Nov 12, 2010 at 8:21 PM, Stefan O'Rear stefa...@cox.net wrote: This goes without saying. One caveat - it should be possible to pass integer file descriptors. Integer file descriptions should exist in the POSIX module, just like Win32 handles should exist in the Win32 module, but they don't have a place in the standard IO. That said, some kind of cross-platform opaque type for low level IO handles may be useful, if only for comparisons. Absolutely not. TIMTOWDI. There will be a select() function (in the POSIX module, not the default namespace!), and it will take parameters as close as possible to POSIX.1's definition. Perl without system calls is not Perl. I agree. TIMTOWDI. Perl without system calls is not Perl. True, but those other ways don't necessarily have to be part of the standard IO, or even the core. Leon
Re: Lessons to learn from ithreads (was: threads?)
On Wed, Oct 13, 2010 at 1:13 PM, Tim Bunce tim.bu...@pobox.com wrote: If you wanted to start a hundred threads in a language that has good support for async constructs you're almost certainly using the wrong approach. In the world of perl6 I expect threads to be used rarely and for specific unavoidably-bocking tasks, like db access, and where true concurrency is needed. I agree starting a large number of threads is usually the wrong approach, but at the same time I see more reasons to use threads than just avoiding blocking. We live in a multicore world, and it would be nice if it was easy to actually use those cores. I know people who are deploying to 24 core systems now, and that number will only grow. Processes shouldn't be the only way to utilize that. (Adding thread/multiplicity support to NYTProf shouldn't be too hard. I don't have the time/inclination to do it at the moment, but I'll fully support anyone who has.) I hate how you once again make my todo list grow :-p
Re: Ruby Fibers (was: threads?)
On Wed, Oct 13, 2010 at 1:20 AM, Tim Bunce tim.bu...@pobox.com wrote: I've not used them, but Ruby 1.9 Fibers (continuations) and the EventMachine Reactor pattern seem interesting. Continuations and fibers are incredibly useful and should be easy to implement on parrot/rakudo but they aren't really concurrency. They're a solution to a different problem.
Re: threads?
On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg ben-goldb...@hotmail.com wrote: If thread-unsafe subroutines are called, then something like ithreads might be used. For the love of $DEITY, let's please not repeat ithreads!
Re: threads?
On Tue, Oct 12, 2010 at 4:22 PM, Damian Conway dam...@conway.org wrote: The problem is: while most people can agree on what have proved to be unsatisfactory threading models, not many people can seem to agree on what would constititute a satisfactory threading model (or, possibly, models). What we really need is some anecdotal evidence from folks who are actually using threading in real-world situations (in *any* languages). What has worked in practice? What has worked well? What was painful? What was error-prone? And for which kinds of tasks? Most languages either implement concurrency in a way that's not very useful (CPython, CRuby) or implement it in a way that's slightly (Java/C/C++) to totally (perl 5) insane. Erlang is the only language I've worked with whose threads I really like, but sadly it's rather weak at a lot of other things. In general, I don't feel that a shared memory model is a good fit for a high level language. I'm very much a proponent of message passing. Unlike shared memory, it's actually easier to do the right thing than not. Implementing it correctly and efficiently is not easier than doing a shared memory system though in my experience (I'm busy implementing it on top of ithreads; yeah I'm masochist like that). And we also need to stand back a little further and ask: is threading the right approach at all? Do threads work in *any* language? Are there better metaphors? Perhaps we need to think more Perlishly and reframe the entire question. Not: What threading model do we need?, but: What kinds of non-sequential programming tasks do we want to make easy...and how would we like to be able to specify those tasks? I agree. I would prefer implicit over explicit concurrency wherever possible.
Re: threads?
On Tue, Oct 12, 2010 at 10:28 PM, B. Estrade estr...@gmail.com wrote: I agree. I would prefer implicit over explicit concurrency wherever possible. I know you're speaking about the Perl interface to concurrency, but you seem to contradict yourself because message passing is explicit whereas shared memory is implicit - two different models, both of which could be used together to implement a pretty flexible system. With implicit I mean stuff like concurrent hyperoperators and junctions. Shared memory systems are explicitly concurrent to me because you have to ether explicitly lock or explicitly do a transaction. It'd be a shame to not provide a way to both use threads directly or to fallback to some implicitly concurrent constructs. I agree
Re: Lessons to learn from ithreads (was: threads?)
On Wed, Oct 13, 2010 at 12:46 AM, Tim Bunce tim.bu...@pobox.com wrote: So I'd like to use this sub-thread to try to identify when lessons we can learn from ithreads. My initial thoughts are: - Don't clone a live interpreter. Start a new thread with a fresh interpreter. - Don't try to share mutable data or data structures. Use message passing and serialization. Actually, that sounds *exactly* like what I have been trying to implementing for perl 5 based on ithreads (threads::lite, it's still in a fairly early state though). My experience with it so far taught me that: * Serialization must be cheap for this to scale. For threads::lite this turns out to be the main performance bottleneck. Erlang gets away with this because it's purely functional and thus doesn't need to serialize between local threads, maybe we could do something similar with immutable objects. Here micro-optimizations are going to pay off. * Code sharing is actually quite nice. Loading Moose separately in a hundred threads is not. This is not trivial though, Perl being so dynamic. I suspect this is not possible without running into the same issues as ithreads does. * Creating a thread (/interpreter) should be as cheap as possible, both in CPU-time as in memory. Creating an ithread is relatively expensive, specially memorywise. You can't realistically create a very large number of them the way you can in Erlang. Leon (well actually I learned a lot more; like about non-deterministic unit tests and profilers that don't like threads, but that's an entirely different story)
Re: Suggested magic for a .. b
On Sun, Aug 1, 2010 at 11:39 PM, Martin D Kealey mar...@kurahaupo.gen.nz wrote: In any case I'd much rather prefer that the behaviour be lexically scoped, with either adverbs or pragmata, not with the action-at-a-distance that's caused by tagging something as fundamental as a String. In many cases the collation isn't known at compile-time, so adverbs would be necessary anyway. Pragma's can make things easier in many cases. Leon
Re: Suggested magic for a .. b
On Thu, Jul 29, 2010 at 9:51 PM, Aaron Sherman a...@ajs.com wrote: My only strongly held belief, here, is that you should not try to answer any of these questions for the default range operator on unadorned, context-less strings. For that case, you must do something that makes sense for all Unicode codepoints in nearly all contexts. I find that both of limited use and the only sane possibility at the same time :-| Leon
Re: Suggested magic for a .. b
On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan dar...@darrenduncan.net wrote: Some possible examples of customization: $foo ~~ $a..$b :QuuxNationality # just affects this one test I like that $bar = 'hello' :QuuxNationality # applies anywhere the Str value is used What if you compare a QuuxNationality Str with a FooNationality Str? That should blow up. Also it can lead to action at a distance. I don't think that's the way to go. Leon
Re: Suggested magic for a .. b
On Wed, Jul 28, 2010 at 11:29 PM, Aaron Sherman a...@ajs.com wrote: The more I look at this, the more I think .. and ... are reversed. .. has a very specific and narrow usage (comparing ranges) and ... is probably going to be the most broadly used operator in the language outside of quotes, commas and the basic, C-derived math and logic ops. Many (most?) loops will involve Most array initializers will involve Why are we not calling that ..? Just because we defined .. first, and it grandfathered its way in the door? Because it resembles the math op? These don't seem like good reasons. I was thinking the same. Switching them seems better from a huffmanization POV. Leon
Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
rich...@rusrating.ru wrote:
Would it make sense to define $*FS as the implied local file system, and
thus that a bare 'open' is sugar for
my $fh = $*FS.open('/path/to/directory/filename', :r);
This then means that there is an implicit
$*FS.connect();
that makes the local system available to the program.
I wonder whether this would also be a way of unifying the program interface
for difference Operating Systems, in that a program running on a *nix
machine would have $*FS of type IO::Filesystem::POSIX, while $*FS for a
Windows machine would have type IO::Filesystem::Windows, etc.
Then it would be possible, as Aaron has suggested to have
my $remote-fs = IO::Filesystem::Google.connect(%args);
my $fh = $remote-fs.open($path-or-url, :r);
and then treat $fh as specified elsewhere.
Morover, it would then be possible to do
$*FS = $remote-fs;
I would propose that this sort of flexibility would be useful for programs
that are embedded in other virtual environments, such as browser plugins, or
programs intended to run on thin clients that do not have their own
filesystems.
I like this idea. It's flexible and extendable but has sane defaults.
Leon
Re: The obligation of free stuff: Google Storage
On Thu, Jun 10, 2010 at 2:07 PM, Mark J. Reed markjr...@gmail.com wrote: But open is already overloaded in p5, with pipes etc. We don't want to repeat the mistakes of the past, and the fact that open(FH, $foo) could run an arbitrary shell command was arguably a mistake, but transparent access to storage where possible is the way to go. I think that 3 argument open fixed that issue for perl 5: with it you would have to be way more explicit about wanting to open. I think something similar would work for me in this case too, a flag like :remote. We can provide a way to limit the behavior when you want - a pragma, option to open(), or just sticking file:// in front of a value to force its interpretation as a plain pathname - but even then, who knows what Fuse filesystem might be mounted and doing strange things with your innocuous-looking file access? I'd rather have that flexibility directly supported in the language. For me that sounds like the wrong default, mostly because I'm worried about remote file inclusion vulnerabilities. Of course, different types of storage have different features; there's no completely unified interface. But to the extent that a cloud disk system or document database functions as a collection of data blobs accessed by a pathlike key, enabling the standard filesystem access pattern for it (in addition to whatever specific functionality it needs) makes sense, IMHO. I fully agree with that. Leon
Re: The obligation of free stuff: Google Storage
On Thu, Jun 10, 2010 at 9:15 AM, Richard Hainsworth
rich...@rusrating.ru wrote:
Ideally [at least, what I would like], managing a file on a remote resource
should be the same as managing one locally, eg.
my Amazon $fn = open($path-to-input-file-location/$file-name, :r) or die
$!;
for $fn.readlines { };
$fn.close;
my Google $fn = open($path-to-output-file-location/$file-name, :w) or die
$!;
for @lots-of-data - $item { $fn.say: $item };
$fn.close;
I agree it should be similar to normal FS interactoin to make matters
as intuitive as possible, but I horrified by the idea of overloading
open() that way. That's a PHP mistake I wouldn't like seeing repeated.
If you want open to do something that's not really opening a file, you
should be explicit about it.
Leon
Re: r30205 - docs/Perl6/Spec
On Fri, Apr 2, 2010 at 5:59 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
He is saying he can’t see how these differ from each other:
.doit(1,2,3): { $^a = $^b } # okay
+ .doit(1,2,3): { $^a = $^b } # okay
Or how these two differ from each other:
+ .doit(1,2,3):{ $^a = $^b } # okay
+ .doit(1,2,3):{ $^a = $^b } # okay
(Neither can I.)
Yeah, I only figured what he did mean about 10 second after sending
that email. Guess I shouldn't email before being fully awake in the
morning ;-).
Leon
Re: Ordering in \bbold{C}
Maybe it's just me, but I don't see the value of having some *arbitrary* predefined order for complex numbers. If people really want to order their complex numbers, let them do it themselves in whatever way they want. Leon On Mon, Mar 29, 2010 at 6:10 AM, Darren Duncan dar...@darrenduncan.net wrote: I was actually thinking, during the previous thread involving Complex numbers ... It may not have any practical use, but if one wanted to define an ordering for complex numbers that was deterministic and relatively unbiased, a way to do this would be based on what I'll call for now the spiral distance. Conceptually, you take an infinite length spiral line that starts at and is centered on the origin, where for each turn the current spot on the spiral increases an infinitesimal radius from the origin, or a distance approaching zero, in the calculus sense. Complex numbers closer to the origin on the spiral will be ordered earlier than those further from the spiral. Actually calculating this is a simple comparison of the radius and angle components of the two complex numbers in the polar coordinate system. If the radius value is different, then the one with the smaller radius is ordered before the one with the larger; if the two radius values are the same, then the one with the smaller angle is ordered first; if both are the same, then the two complex numbers are equal. The math is just as simple as a naive comparison that just compares the real component and then imaginary component in a cartesian coordinate system, but the result is much more reasonable I think. This whole principle of distance from origin method of ordering does also, I suspect, scale to any number of dimensions; the one-dimensional version is simply comparing first the absolute value of the two numbers, and then saying that either the positive or negative version orders first. -- Darren Duncan
Re: r30205 - docs/Perl6/Spec
A space between the colon and the opening brace ;-)
Leon
On Sat, Mar 27, 2010 at 2:01 AM, Geoffrey Broadwell ge...@broadwell.org wrote:
On Fri, 2010-03-26 at 08:38 +0100, pugs-comm...@feather.perl6.nl wrote:
.doit: { $^a = $^b } # okay
.doit(): { $^a = $^b } # okay
.doit(1,2,3): { $^a = $^b } # okay
+ .doit(1,2,3): { $^a = $^b } # okay
+ .doit:{ $^a = $^b } # okay
+ .doit():{ $^a = $^b } # okay
+ .doit(1,2,3):{ $^a = $^b } # okay
+ .doit(1,2,3):{ $^a = $^b } # okay
My eyes must be playing tricks on me -- I can't see the difference
between the last two lines in each of the above blocks. What am I
missing?
-'f
Re: Filename literals
Reading this discussion, I'm getting the feeling that filename literals are increasingly getting magical, something that I don't think is a good development. The only sane way to deal with filenames is treating them as opaque binary strings, making any more assumptions is bound to get you into trouble. I don't want to deal with Windows' strange restrictions on characters when I'm working on Linux. I don't want to deal with any other platform's particularities either. Portability should be positive, not negative IMNSHO. As for comparing paths: reimplementing logic that belongs to the filesystem sounds like really Bad Idea™ to me. Two paths can't be reliably compared without choosing to make some explicit assumptions, and I don't think Perl should make such choices for the programmer. Leon Timmermans
Re: Filename literals
On Fri, Aug 14, 2009 at 7:41 PM, David Greendavid.gr...@telus.net wrote: Well, we can encode a URI any way we like -- I was thinking of anything up to the next whitespace or semicolon, and internal semicolons, etc. being %-encoded. Semicolons are reserved characters in URIs: inappropriately percentage encoding semicolons would be in direct violation of rfc3986. Using them as delimiter would break many perfectly valid URIs. That's absolutely a no-go IMNSHO. Breaking up at whitespace should work, see appendix C of RFC 3986 for recommendations on that. Maybe it's more practical to permit only URIs with little to no punctuation to be unquoted, and quote anything else? Not that quoting is such a great hardship anyway Maybe, but if I can't use it half of the time it may as well be omitted. Quoting should be relatively easy, because URIs have a wide range of characters that can't be in them anyway. Leon
Re: slowness in grammar
If you want to write a fast parser for XML, preventing backtracking is going to be quite essential. I suspect the problem is your grammar, not the grammar engine itself. You could post it to perl6-users and ask for advice on it. Leon On Thu, Jun 4, 2009 at 7:25 AM, Richard Hainsworth rich...@rusrating.ru wrote: Is this a good place to come with code that runs into speed problems? I am writing a program in perl6 to read the xml file from a Sony book reader, list the books, and move books into collections (the Sony software to do this will only work on windoz and not on wine). I have a grammar that works with abbreviated test versions of the xml file, but it just hangs with the full version. Since I have a line my $parsed= sony_grammar(slurp media.xml); and the problem is in the parsing, I dont know how to insert trace statements to determine at what stage the problem is being generated. In addition, there is a great deal in the Synopses about code points and backtracking and the like, which I dont quite understand. However, it seems to me that an intelligent use of these possibilities could increase the efficiency of the parsing, if only I knew how. For example, only three of the tags in the file are of interest, and within them three of the attributes. So how do I tell the regex engine to skip processing if the tag is not of interest? Richard
Re: What is U4X?
On Thu, May 21, 2009 at 4:18 PM, John M. Dlugosz 2nb81l...@sneakemail.com wrote: Can someone post a link? http://svn.pugscode.org/pugs/docs/u4x/README Google is your friend ;-)
Re: Docstrings in Perl 6
2009/5/4 Damian Conway dam...@conway.org:
Each approach has advantages and disadvantages.
Feedback via this forum would be most welcome.
Most people seem to lean towards the pod comments, though I disagree
with it on a simple ground: aesthetics. Python docstrings aren't just
useful, they are reasonably pretty too, #={} isn't. In fact I'd say
it's pretty fugly. I think that a feature that we intend to be used
often should be more aesthetically pleasing, if only to promote its
use.
Leon
Re: .map/.reduce with larger arity
On Tue, Mar 10, 2009 at 12:09 AM, Larry Wall la...@wall.org wrote:
Yes, the only difference between Cfor and Cmap is that you can
only use Cfor at the start of a statement. But we're more liberal
about where statements are expected in Perl 6, so you can say things
like:
my @results = do for @list - $x {...};
my @results = (for @list - $x {...});
and either of those is equivalent to:
my @results = map - $x {...}, @list;
I also Officially Don't Care if you use map in a void context. :)
Larry
I would propose there to be one difference between for an map: map
should bind its arguments read-only, for should bind them read-write.
That would make at least one bad practice an error.
Leon
Re: AnyEvent
On Wed, Feb 25, 2009 at 5:56 AM, Timothy S. Nelson wayl...@wayland.id.au wrote: Am I right in guessing that the AnyEvent stuff should go in S17 ? I would suggest to rename that to Event (since unlike Perl 5 that name is still available in Perl 6). Leon
Re: Signals question for S16: IPC / IO / Signals
I think most forms of IPC should be addons, if only because they have inherent unportability. Stuff like sockets and pipes should be in obviously, signals maybe (they have lots of portability issues, but they may be too often used to just drop), but things like SysV IPC really shouldn't. Anything more high level should definitely not go in the core. Leon (my apologies to Timothy, who now gets this twice, I screwed up due to gmail having issues with this mailing list). On Mon, Feb 23, 2009 at 2:26 AM, Timothy S. Nelson wayl...@wayland.id.au wrote: I have a quick question here. S16 claims to be about IPC, IO, and Signals. So far, it's mostly about IO. My question is, is it intended that IPC and/or signals be part of the core, or should they be converted to addons like Form.pm? Thanks, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Signals question for S16: IPC / IO / Signals
On Tue, Feb 24, 2009 at 1:13 AM, Timothy S. Nelson wayl...@wayland.id.au wrote: On Mon, 23 Feb 2009, Leon Timmermans wrote: I think most forms of IPC should be addons, if only because they have inherent unportability. Stuff like sockets and pipes should be in obviously, signals maybe (they have lots of portability issues, but they may be too often used to just drop), but things like SysV IPC really shouldn't. Anything more high level should definitely not go in the core. Ok, I agree about the SysV IPC. Files and Sockets are in. As for the rest, I have another question -- should they be part of a Unix-only class? I don't understand your question; what do you mean with 'they' here? Anything not in the core doesn't have to be specced at all for now.
Re: Temporal revisited
On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky auta...@urth.org wrote: After some discussion I made a number of drastic revisions to S32-setting-library/Temporal.pod What I want to see in Perl 6 is a set of very minimal roles that can be used to provide a simply object from gmtime() and localtime(). These objects should not handle locales, proper Olson timezones, string parsing, user-defined formatting, or math. They're basically simply little data blobs with some overloading and a few handy methods. I imagine that a real classes which do math, handle leap seconds, formatting, and so on will _also_ do these roles, but this should be done out of core. I don't really know Perl 6 all that well, so I'd welcome review, in particular of my Perl 6-isms, and also just of the general concepts. Why should an Instant be a role, and not a concrete class? What would one instant do that another can't? Representing a specific moment in time sounds like a very concrete thing to me. Leon
Re: r25373 - docs/Perl6/Spec
+role Date {
+ has Calendar $.calendar;
+ has NumberName $.year;
+ has NumberName $.month;
+ has NumberName $.dayofmonth;
+ has NumberName $.dayofweek;
+ has NumberName $.dayofyear;
+ has NumberName $.dayofquarter;
+ has NumberName $.quarter;
+ has NumberName $.era; # 'Common', 'Christian', etc
+ has Str $.defaultformat;
Shouldn't these be methods instead of attributes?
Leon
Re: r25371 - docs/Perl6/Spec
On Wed, Feb 18, 2009 at 12:16 PM, Timothy S. Nelson wayl...@wayland.id.au wrote: On Wed, 18 Feb 2009, Leon Timmermans wrote: The only difference I could see was that shutdown allows changing the readability and writeability. While I agree that this functionality should be exposed, (see my next update), I think that in the general case, .close() plus the other stuff I've done should be sufficient. Maybe shutdown() should be exposed somewhere, though. You are missing one very important thing about shutdown: its effect is on the connection and thus global. It also affects other processes that share the same socket. close() OTOH is local. It only affects the file descriptor, and only in the current process. Leon
Re: r25328 - docs/Perl6/Spec
On Sat, Feb 14, 2009 at 6:38 AM, pugs-comm...@feather.perl6.nl wrote:
+=head2 IO::Openable
+
+This role implies that the object can be connected to, or listened on.
+
+=over 4
+
+=item open
+
+ method Bool open();
+
+Attempts to open the handle. Depending on the implementation, this could be
an open()
+call, a connect(), a listen(), or something similar.
+
+=back
+
I'm not sure if I really hate or love this. I'm not quite convinced if
the use of it anyway.
+=head2 IO::Socket
+
+role IO::Socket does IO::POSIX does IO::Openable does IO::Closeable {
+...
+}
+
+=over
+
+=item IO.accept
+
+=item IO.bind
+
+=item Socket.pair
+
+our List of IO method pair(Int $domain, Int $type, Int $protocol)
+
+A wrapper for socketpair(2), returns a pair of IO objects representing the
+reader and writer ends of the socket.
+
+ use Socket;
+ ($r, $w) = Socket.pair(AF_UNIX, SOCK_STREAM, PF_UNSPEC);
+
+
+=back
+
Why should this do POSIX? What about non-POSIX operating systems?
+=item syscall
+
That functions should be well hidden
+=item sysopen
+
I vote for sysopen (and all other sys functions) to be wiped out of existence.
+=head1 Classes
+
+=head2 IO::File
+
+This does file input and output.
+
+class IO::File does IO::POSIX does IO::Closeable does IO::Openable {
+...
+}
+
+=over
+
+=item init
+
+ method init(String $filename, $options?);
+ method init(Int $fd);
+
+ # Read
+ $fobj = new IO::File($filename);
+
+ # Write
+ $fobj = new IO::File($filename, :w);
+
+ # Read using file descriptor
+ $fobj = new IO::File($fd);
+
+Associate an IO object with an already-open file descriptor,
+presumably passed in from the parent process.
+
+=back
Why should this do POSIX? What about non-POSIX operating systems?
Why is that function called init, and not open? That's rather non-intuitive.
This should do IO::Seekable and (to be written) IO::Stattable.
+=head2 IO::FileSystem
+
+This reads directories, worries about ownership and permissions, and the
like.
+
+class IO::FileSystem does IO::POSIX does IO::Closeable does IO::Openable {
+...
+}
Why should this do POSIX? What about non-POSIX operating systems?
+=head2 IO::Socket::INET
+
+class IO::Socket::INET does IO::Socket {
+...
+}
+
+=over
+
+=item init
+
+ method Bool init($RemoteHost, $RemotePort, $LocalHost?, $LocalPort?);
+
+=item open($Listen?);
+
+If $Listen is 0, it does a connect(). If $Listen is 1, it does a connect()
and a
+listen(). If $Listen is 2, it does a listen(), but no connect().
+
I *really* hate that interface, and I don't see how it covers an
accepting socket.
IMO there should be two calls
method IO connect($RemoteHost, $RemotePort, *%options)
where *%options can contain things like the local address,
non-blockingness, etc...
method IO::Accepting listen($LocalHost, $LocalPort, *%options)
role IO::Accepting does IO::Socket {
IO accept();
}
-=head1 Input and Output
+=head2 IO::Pipe
-=over 4
+class IO::Pipe does IO::POSIX does IO::Closeable does IO::Openable {
+...
+}
Why should this do POSIX? What about non-POSIX operating systems?
Regards,
Leon Timmermans
Re: r25328 - docs/Perl6/Spec
On Sat, Feb 14, 2009 at 10:31 PM, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: I think the point here is that on POSIX systems that gets you ioctl() and fcntl(), and on non-POSIX systems either they don't exist or they throw runtime errors. Aside from my earlier suggestion that non-POSIX systems generally have similar functions for which we should consider a common rubric, I'm not sure if this (does IO::POSIX) is backwards or if my/our(?) understanding of does is backwards, or possibly tangential. IMO IO::POSIX should do exactly what it says it does: implement POSIX as closely as possible. Since we probably can't implement much of it on non-POSIX platforms, I don't think it should be part of our specification (though I do think it should be part of our implementation, because it is definitely useful). I think it would be a lot better to implement a more portable wrapper around the necessary functionality. Regards, Leon
Re: r25172 - docs/Perl6/Spec
On Tue, Feb 3, 2009 at 8:34 AM, Richard Hainsworth rich...@rusrating.ru wrote: I strongly believe the current S16 needs rewriting from scratch. This approach seems far more more perl6-ish. I tried to draft a new S16, but realised I simply dont have the knowledge (or the time to acquire the knowledge) necessary for even an initial draft. But in trying, these are some of the ideas I had. I fully agree. c) the file tests :r and :w are not adverbs. They are methods on File objects to determine the properties readability and writeability and return Booleans. Things which are different should be named differently. Also, in my (very limited) experience, testing readability and writeability are less frequent in use than opening for read and write, thus for Huffman reasons, they should be longer. May be .readable .writeable? I think what S16 currently proposes is just fine. d) The vast majority of S16 seems to be about functions that are essentially wrappers around unix calls. To be honest, I have never used most of them within a perl program. Yeah, many of them should be moved to POSIX::, and/or be replaced by something better. When originally developed, it was to fill a need directly related to managing unix systems. There are now better tools for these tasks, so perl6 does not need to address them in the core. I'm not sure what you mean with that. I don't think there is any reason why Perl 6 is inferior to some other tool for managing unix systems. If it is, we should fix that. The success of perl on the internet was due to the much deeper design values incorporated in perl and that these deeper insights were more adaptable to a different environment. There are now a variety of tools for handling the internet environment. Perl6 - I believe - is now addressing an even wider set of issues - a larger problem space. Leaving unix wrappers in the core specifications will tie it down and perhaps hinder its development. Suppose perl6 becomes the defacto language for an internet browser, IO would not even be related to files or an operating system.) We have pluggable preludes. We can neutralize that problem easily. g) Statbuf is mentioned in S03. It is not really dealt with in S16. It seems to me from the context in S03 that Stafbuf is a sort of 'eager' filehandle, in that the whole file is pulled into memory and then can be operated on. If this is the case, would it not be more appropriate for the eagerness to be defined as an adverb for 'open()' ? eg. my $filehandle .= open(name, :r, :e); Wouldn't this eliminate the need for Statbuf as a defined object type? No, it's just the caching result of stat(), that happens to remember what file/handle is was called on. It seems S03 and S16 disagree on the meaning of $filename ~~ :e though. According to S16 it means $filename.:e, according to S03 it means $filename.e. I think it was discussed some time ago and S16 is correct. h) Would it not be possible to write the IO specification in such a way as to make everything 'outside' the program a single category of IO? Thus files, http and ftp connections are all streams into containers and the same verb ( 'open()' ) with attendant adverbs (:w, :r) are used to establish them and the same set of tests (.readable, .writeable) used to verify the steams have the required properties at some point in the programe. All directories and urls would all be locations with the same methods to discover container objects (files, archives, databases) in them. There's nothing special about IO objects. Nothing is stopping anyone from writing their own objects implementing the IO roles (in fact, roles encourage doing just that). I don't understand what's the question, really. Though if you mean with open() that is should do what PHP's fopen does (open anything, from files to http connections and more): absolutely not. That's the kind of behavior that must be explicit, else we open up to a whole range of security problems. Regards, Leon Timmermans
Re: r25182 - docs/Perl6/Spec
On Wed, Feb 4, 2009 at 4:37 PM, pugs-comm...@feather.perl6.nl wrote: +=head2 IO + +The base role only tags that this is an IO object for more generic +purposes. It doesn't specify any methods or attributes. + Shouldn't IO::readable and IO::Writable do IO? + +=head2 IO::Closeable + I still think this should be in a more general namespace than IO. + +=item method IO dup() + Do we really want that? POSIX' dup does something different from what many will expect. In particular, the new file descriptors share the offset, which can result in some really confusing situations. Leon
Re: r25172 - docs/Perl6/Spec
On Mon, Feb 2, 2009 at 1:05 PM, pugs-comm...@feather.perl6.nl wrote: =item getc -our Bool method getc (IO $self: *...@list) +our Bool method getc (IO $self: Bool :async) getc returning a Bool??? -the latter case C$! is set). +the latter case C$! is set). The C:async flag lets the call +return an undefined value if no character is immediately available. IMHO it would be better to call that non-blocking IO instead of asynchronous IO, but I'm POSIX-biased. Regards, Leon Timmermans
Re: Converting a Perl 5 pseudo-continuation to Perl 6
When going OO, I'd say an augment()/inner() approach would be
cleanest. See
http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook/Basics/Recipe6.pod
for an example. I don't know how to express that in Perl 6 though.
Regards,
Leon
On Fri, Jan 2, 2009 at 2:08 AM, Steve Lukas lukas...@yahoo.com wrote:
Hello,
I'd vote for the OO-style.
My reason is that the major criteria should be the reader perspective.
It should be as clear as possible what's going on in the main code
even if the reader doesn't know the hottest p6 tricks!
What you are doing here is: two operations on the same thing (the pidfile).
So the code should point out that it works twice on the same thing.
I think it's best to have an object to show this
whereas returning the sub/closure feels a bit confusing.
Your right, this style is busy work, but it's not pointless.
I would suggest a locally visible class to bring out the
local, one time usage of that class. Btw. what is the best way to do so?
Kind regards
Stefan
--- On Thu, 1/1/09, Geoffrey Broadwell ge...@broadwell.org wrote:
From: Geoffrey Broadwell ge...@broadwell.org
Subject: Converting a Perl 5 pseudo-continuation to Perl 6
To: perl6-us...@perl.org, perl6-language@perl.org
Date: Thursday, January 1, 2009, 3:34 PM
In the below Perl 5 code, I refactored to pull the two halves of the PID
file handling out of init_server(), but to do so, I had to return a sub
from pid_file_handler() that acted as a continuation. The syntax
is a
bit ugly, though. Is there a cleaner way to this in Perl 6?
##
sub init_server {
my %options = @_;
# ...
# Do top (pre-daemonize) portion of PID file handling.
my $handler = pid_file_handler($options{pid_file});
# Detach from parent session and get to clean state.
become_daemon();
# Do bottom (post-daemonize) portion of PID file handling.
$handler-();
# ...
}
sub pid_file_handler {
# Do top half (pre-daemonize) PID file handling ...
my $filename = shift;
my $basename = lc $BRAND;
my $PID_FILE = $filename || $PID_FILE_DIR/$basename.pid;
my $pid_file = open_pid_file($PID_FILE);
# ... and return a continuation on the bottom half
(post-daemonize).
return sub {
$MASTER_PID = $$;
print $pid_file $$;
close $pid_file;
};
}
##
When I asked this question on #perl6, pmurias suggested using
gather/take syntax, but that didn't feel right to me either -- it's
contrived in a similar way to using a one-off closure.
pmichaud offered several possibilities (I've converted some of his
suggestions expressed as prose into code, so the errors there are mine):
1. Take advantage of Perl 6 syntax reduction to turn 'return sub {...}'
into 'return {...}' (or even just fall of the end with
'{...}', I
suppose). This is visually slightly better, but still leaves the
bottom half inside a block that merely exists to satisfy Perl, not
actually representing anything intrinsic about the problem.
2. Throw a resumable exception in the middle:
sub init_server {
# ...
pid_file_handler($options{pid_file});
become_daemon();
pid_file_handler();
# ...
}
sub pid_file_handler {
# ... top half ...
throw ResumableException;
# ... bottom half ...
}
He also suggested a variant syntax with an adverb on return:
sub pid_file_handler {
# ... top half ...
return :resumable;
# ... bottom half ...
}
I suggested a naked yield syntax:
sub pid_file_handler {
# ... top half ...
yield;
# ... bottom half ...
}
These all desugar to the same thing, of course.
3. Make become_daemon a part of pid_file_handler, or vice-versa.
I rejected both of these on the basis of separating different
things into different subs. The two tasks are only tangentially
related, and neither really seems like a subordinate op of the
other.
4. In order to keep the sub separate, but still not split the
pid_file_handler call, I came up with a variation of #3 in which
pid_file_handler takes a callback parameter:
sub init_server {
# ...
pid_file_handler($options{pid_file}, become_daemon);
# ...
}
sub pid_file_handler($pid_file, callback) {
# ... top half ...
callback();
# ... bottom half ...
}
That seems like a silly contortion to hide the problem, and
doesn't represent my intent well -- the pid file handler doesn't
need to send a message, it needs to yield control while waiting
for something else to happen.
5. Make a new PidHandler class and address the problem in OO fashion:
sub init_server {
# ...
my $pid_handler = PidHandler.new(file = $options{pid_file});
$pid_handler.top();
become_daemon();
$pid_handler.bottom();
#...
}
This is certainly workable, but again feels like a contrived
workaround in
Re: Converting a Perl 5 pseudo-continuation to Perl 6
I can't help wondering why does pid_file_handler need to be split up
in the first place? Why wouldn't it be possible to simply call
pid_file_handler after become_daemon?
Regards,
Leon Timmermans
On Thu, Jan 1, 2009 at 10:34 PM, Geoffrey Broadwell ge...@broadwell.org wrote:
In the below Perl 5 code, I refactored to pull the two halves of the PID
file handling out of init_server(), but to do so, I had to return a sub
from pid_file_handler() that acted as a continuation. The syntax is a
bit ugly, though. Is there a cleaner way to this in Perl 6?
##
sub init_server {
my %options = @_;
# ...
# Do top (pre-daemonize) portion of PID file handling.
my $handler = pid_file_handler($options{pid_file});
# Detach from parent session and get to clean state.
become_daemon();
# Do bottom (post-daemonize) portion of PID file handling.
$handler-();
# ...
}
sub pid_file_handler {
# Do top half (pre-daemonize) PID file handling ...
my $filename = shift;
my $basename = lc $BRAND;
my $PID_FILE = $filename || $PID_FILE_DIR/$basename.pid;
my $pid_file = open_pid_file($PID_FILE);
# ... and return a continuation on the bottom half (post-daemonize).
return sub {
$MASTER_PID = $$;
print $pid_file $$;
close $pid_file;
};
}
##
When I asked this question on #perl6, pmurias suggested using
gather/take syntax, but that didn't feel right to me either -- it's
contrived in a similar way to using a one-off closure.
pmichaud offered several possibilities (I've converted some of his
suggestions expressed as prose into code, so the errors there are mine):
1. Take advantage of Perl 6 syntax reduction to turn 'return sub {...}'
into 'return {...}' (or even just fall of the end with '{...}', I
suppose). This is visually slightly better, but still leaves the
bottom half inside a block that merely exists to satisfy Perl, not
actually representing anything intrinsic about the problem.
2. Throw a resumable exception in the middle:
sub init_server {
# ...
pid_file_handler($options{pid_file});
become_daemon();
pid_file_handler();
# ...
}
sub pid_file_handler {
# ... top half ...
throw ResumableException;
# ... bottom half ...
}
He also suggested a variant syntax with an adverb on return:
sub pid_file_handler {
# ... top half ...
return :resumable;
# ... bottom half ...
}
I suggested a naked yield syntax:
sub pid_file_handler {
# ... top half ...
yield;
# ... bottom half ...
}
These all desugar to the same thing, of course.
3. Make become_daemon a part of pid_file_handler, or vice-versa.
I rejected both of these on the basis of separating different
things into different subs. The two tasks are only tangentially
related, and neither really seems like a subordinate op of the
other.
4. In order to keep the sub separate, but still not split the
pid_file_handler call, I came up with a variation of #3 in which
pid_file_handler takes a callback parameter:
sub init_server {
# ...
pid_file_handler($options{pid_file}, become_daemon);
# ...
}
sub pid_file_handler($pid_file, callback) {
# ... top half ...
callback();
# ... bottom half ...
}
That seems like a silly contortion to hide the problem, and
doesn't represent my intent well -- the pid file handler doesn't
need to send a message, it needs to yield control while waiting
for something else to happen.
5. Make a new PidHandler class and address the problem in OO fashion:
sub init_server {
# ...
my $pid_handler = PidHandler.new(file = $options{pid_file});
$pid_handler.top();
become_daemon();
$pid_handler.bottom();
#...
}
This is certainly workable, but again feels like a contrived
workaround in the same way that gather/take and return {...} do.
Plus, writing a new class and using OO/method call syntax just to
allow a sub to be split seems like pointless busy work. Not
as bad in Perl 6 as in Perl 5, but still.
In the end, I think I like the 'naked yield' idea best of the ones we
have so far. Any comments or other ideas? [1]
-'f
[1] Other than that I've used the word 'contrived' too many times. :-)
Re: Working with files wish list
On Tue, Dec 16, 2008 at 7:04 AM, jason switzer jswit...@gmail.com wrote: I hadn't seen a Nameable role mentioned yet, so I wasn't able to understand any such concept. The list was not meant to be exhaustive. There are a lot more roles that have something to do with IO but were missing: Asynchronous IO, Datagram sockets, and more (specially when you add in platform specific stuff). The whole idea is that almost any operation you can do on one kind of handle can be done on some other kind too. There is a lot of overlap between seemingly unrelated types of handles. In this case, files and unix domain sockets are created and used in rather different ways, but both have a place in the filesystem, so it would be appropriate that they share the interface for retrieving that location. That is a good idea, but the idea is so general that anything can be nameable and thus the specificity of the role could quickly become lost. I was suggesting specific naming functionalities be added to the File role. If you want to abstract that, that's fine, but beware that something like Nameable can be too broad of a role (maybe just IONameable?). I agree Nameable isn't the best name. How about Locatable? Having said that, I suppose a generic Nameable role providing a human readable designation to a handle (as opposed to one for computers) would be useful too, if only for error messages. I haven't spent the time to understand mix-ins yet, but this does look like a feasible (clean) idea. However, how do you specify one/more filters? For example, say you want to :rw a file. How can you provide an input filter and an output filter (or multiples of either)? Can you layer filters if done with mix-ins? Stacking can be done: $fstab does WhitespaceTrim does TranslateKlingon; I'm not sure if this is the best way to approach the problem though. This is a power drill, a screwdriver will also do in many cases. If so, how do you specify direction? That would be a problem with this approach. You'd probably need separate roles for readers and writers. Regards, Leon Timmermans
Re: Working with files wish list
be the stringified .name attribute of the files. No need to opendir or readdir. Lazy evaluation could handle most situations, but where the Location could be constantly changing its contents, a $dir.refresh() method might suffice. I agree there should be a single function that combines opendir, readdir and closedir. Scalar readdir can be useful in some context, but in my experience it's the less common usage of it. From a programmers point of view lazy operation would be convenient, but from a resource management point of view that may be a bit complicated. f) In general on directories, I am sure a variety of solutions could be conceived. It seems to me that abstractly any form of directory could be thought of as a Location, which has some path defined for it (though the syntax of the path is OS dependent), and which might have children locations. At a minimum, a Location would need to provide information about whether new resources could be created or accessed (eg., read / write permissions). There are various paradigms for defining how to traverse networks. At some point, our language legislators will need to define one for perl6. If the name of the location node, which can be exposed to the user, eg., by printing it or showing it in a GUI to be clicked on, is separated from the OS/locale-dependent underlying_name (which may not be easily displayed on a standard GUI – suppose it is in ancient Buriyat), then identifying nodes and traversing a network of nodes could be made abstract enough to handle all sorts of environments. Perhaps, too a module for a specific environment, eg., Windows, would provide the syntatic sugar that makes specifying a location look like specifying a directory natively, eg. use IO::Windows; my Location $x .= new(:OSpathC:\\Documents\perldata\); whilst for linux it would be use IO::Linux; my Location $x .=new(:OSpath/home/perldata/); This started as short wish list and got far too long. Sorry I think a File::Spec-like approach would be better. Regards, Leon Timmermans
Re: Working with files wish list
On Mon, Dec 15, 2008 at 6:42 PM, jason switzer jswit...@gmail.com wrote:
It's lazy and kinda cheating, but for small simple tasks, it gets the job
done. I'm not up to speed with the IO spec, but a sort of auto-slurp
functionality would be nice. Something to the effect:
@data = :slurp(mydatafile.txt);
A slurp() function has been specced to slurp a file into a string, as
well as a lines() function that does the same into an array of lines.
I think File::Path::canonpath and File::Path::path would be
nice attributes to add to the File role.
You didn't get the point of my Roles idea. It should not be added to a
role File, but to the Role Nameable, which would be composed into
whatever implements file filehandles, but for example also into Unix
sockets. IMNSHO interfaces and implementation should be kept separate
to maintain a proper abstraction level.
I would imagine a filter role would be useful. If they're roles, it allows
people to build layers of functionality on them to do various different
kinds of filters, turn them on and off, etc. With filters as roles, I would
love to imagine something like this:
my File $fstab = new(:name/etc/fstab, :filternew WhitespaceTrim)
You can already easily mix it in using 'does':
$fstab = open('/etc/fstab', :r);
$fstab does WhitespaceTrim;
I don't think it's really necessary to include that into open(),
though it might be useful syntactic sugar.
Regards,
Leon Timmermans
Re: Resume from exception
On Mon, Dec 15, 2008 at 8:47 PM, Stephen Weeks t...@allalone.org wrote:
do {
die 'some text';
say 'after the exception';
CATCH {
say 'caught the exception';
...; # what goes here?
}
}
My proposal is to call .resume() on the exception object.
Thoughts?
The spec says Exceptions are not resumable in Perl 6 unless the
exception object does the Resumable role.. I don't think Str does
Resumable. In other words, you can't resume that.
Otherwise, I agree resume is a logical name.
Regards,
Leon
Re: Roles and IO?
On Fri, Dec 12, 2008 at 3:04 AM, Jon Lang datawea...@gmail.com wrote: One of the things about roles is that once you have composed a bunch of them into another role, they're considered to be composed into whatever that role is composed into. So does File would be equivalent to does Mappable does Pollable does Statable does Ownable (barring potential conflicts between Mappable, Pollable, Statable, and Ownable which File would presumably resolve). I assumed a new role makes a new interface. In other words, that a type that happens to do Pollable, Mappable, Statable and Ownable wouldn't automatically do File in that case. If I was wrong my abuse of subset wouldn't be necessary. Otherwise, maybe there should be a clean way to do that. Now I'm thinking of it, wouldn't something like our ::File = Mapable Pollable Statable Ownable; do the trick? On Fri, Dec 12, 2008 at 3:52 AM, Mark J. Reed markjr...@gmail.com wrote: As Jonathan said, I think composition makes more sense here... but what if you have an interface that expects an IO object and does nothing with it but pass it into some other interface? How does it declare that? It seems like there still needs to be a generic superrole that means some non-empty but unspecified subset of these roles - maybe Closable would work, but it's not real clear. Yeah, I wasn't clear on that, but I agree there should be some base role shared by all these roles, though I'm wondering if that should be shared by all handles or just IO handles. I see no reason why Closable should be limited to IO handles, but I do see a use for being able to indicate you're talking about an IO handle. I'd say it makes sense to define IO as Readable | Writable. On Fri, Dec 12, 2008 at 9:23 AM, Dmitry Karasik dmi...@karasik.eu.org wrote: Wouldn't the proposed solution raise an error if an unsupported role method is tried? It's not that the proposed solution is inappropriate, but the problem that I think you're trying to solve won't be solved by it. In the worst case scenario, you're right. However if you use the roles properly this shouldn't happen because you'd get an error much sooner. If your interface expects a Seekable and you pass it a pipe, it will immediately raise an error, instead of waiting until you try to use it. Regards, Leon
Roles and IO?
Hi all, I've been thinking about how the IO interface should be organized in perl6. It seems that part of S16 has received little attention so far. One main problem with filehandles is that are rather diverse. The only operation that all of them have in common is close. Reading versus writing is a obvious difference, there are many more differences. One can't seek a socket or a pipe, and likewise one can't accept on a file. A listening socket can't even be read or written to. At the same time, they all do have some parts in common with some other types of handles. Perl 5's solution is to use a fat interface, and raise an error if an unsupported action is tried. I think that approach is needlessly fragile. Another solution is to make a separate class for every variety of handle, but IMO that's a plain fugly solution that simply doesn't scale up very well. What I propose is using role composition for *everything*. Most importantly that includes the roles Readable and Writable, but also things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered (does Readable), Socket, Acceptable (does Pollable), and more. That may however make some interfaces is a bit wordy. I think that can be conveyed using a subset like this (though that may be abusing the feature). subset File of Mapable Pollable Statable Ownable; In this case, these calls: open($filename, :w); would return a Writable File, and Socket::connect($remote_host, $port, :typeinet); would return a Socket Buffered Pollable Writable Regards, Leon Timmermans
Re: Files, Directories, Resources, Operating Systems
On Mon, Dec 8, 2008 at 8:16 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: It looks like Python 3000 just tried that. People are not happy about it: http://utcc.utoronto.ca/~cks/space/blog/python/OsListdirProblem Yeeh, I also noted exactly that problem when reading the What's New In Python 3.0. What were they thinking?! Leon
Re: how to write literals of some Perl 6 types?
On Thu, Dec 4, 2008 at 6:34 PM, TSa [EMAIL PROTECTED] wrote: HaloO, And how about 'Num 1.0 === Complex(1,0) === Int 1'? Should all these be identical irrespective the fact that they come from three different type domains? How is that implemented? IMHO the spec on === is quite clear: two values are never equivalent unless they are of exactly the same type. IMHO, you shouldn't be using === but == anyway when doing that kind of numerical work. That one should DWIM. Regards, Leon Timmermans
Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 12:40 PM, Mark Overmeer [EMAIL PROTECTED] wrote:
Also, I get data from a CD which was written case-insensitive and then
copied to my Linux box. It would be nice to be able to say: treat this
directory case insensitive (even when the implementation is slow)
Shared with Windows default behavioral interface.
That is a task for the operating system, not Perl. You're trying to
solve the problem at the wrong end here IMHO.
For instance, you do not know in which character-set the filename is;
that is file-system dependent. So, we treat filenames as raw bytes.
On native file-system types (like ext3fs), character-set is not
file-system dependent but non-existent. It really is raw bytes.
This does cause dangers (a UTF-8 codepoint in the filename with a \x2F
('/') byte in it, for instance)
A \x2F always means a '/'. UTF-8 was designed to be backwards
compatible like that.
Regards,
Leon Timmermans
Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 5:15 PM, Mark Overmeer [EMAIL PROTECTED] wrote: Yes, you are right on this. ASCII does not suffer from UTF-8, so my example was flawed. The second 128 does cause problems. How can glob() sort filenames, for instance? That's a matter of collation, not (just) character set. TIMTOWTDI. There is no right way to do it as it depends on the circumstances, but a simple binary sort is not a bad default. Leon Timmermans
Re: Collapsing Junction states?
On Thu, Nov 13, 2008 at 2:24 PM, TSa [EMAIL PROTECTED] wrote: Do I understand your question right, that you want the return of == to be false because there is a one(1,0,1) junction? As Duncan points out junctions are immutable values and as such the % autothreads but the resulting values are assembled into a new junction according to the general rules, i.e. one(0,1). The number of elements in one(1,2,3) is not preserved. But of what use would one() if it were to use those semantics? It would be essentially the same as any(), and it would definitely not DWIM. Regards,
Re: Collapsing Junction states?
According to Synopsis 2, under Immutable types, a Junction is a Set with additional behaviors. This implies to me a Junction consists just of distinct unordered values. A Junction is not a Bag and it doesn't matter that we lose the fact that a value occurred more than once in the arguments of the Junction constructor. Whether values are considered identical or not and get eliminated depends on what their .WHERE returns. Whether a Perl 6 implementation internally reduces the constructor value list doesn't matter as long as the semantics of using the Junction are as if it had; so eg that reduction could be done lazily, just when the Junction is first used. -- Still that doesn't solve the problem of his code example. If my understanding of the synopses is correct, operations on junctions generate a new junction, so `one(1,2,3) % 2 == 1` will collapse to one(1 % 2 == 1, 2 % 2 == 1, 3 % 2 == 1), which is one(true, false, true). If it collapses, it will be one(true, false), and thus true, but if it doesn't collapse it will be false. Either I'm missing something, or the behavior of `one' needs to be specified more thoroughly. I think I agree with Patrick that collapse needs to be delayed there. Regards, Leon
