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
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: 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 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
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, :type); would return a Socket & Buffered & Pollable & Writable Regards, Leon Timmermans
Re: Roles and IO?
On Fri, Dec 12, 2008 at 3:04 AM, Jon Lang 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 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 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
Re: Working with files wish list
mping is already in the language. It's very underspecified though.
> e) When dealing with files in directories in perl5 under linux, I need
>
> opendir(DIR,'./path/') or die "cant open ./path/\n";
>
> my @filelist = grep { /^.+\.txt/ } readdir(DIR);
>
> I would prefer something like
>
> my Location $dir .= new(:OSpath<'./data'>);
>
> and without any further code $dir contains an Array ($d...@elems) or Hash
> ($dir.%elems) (I dont know which, maybe both?) of File objects. If a Hash,
> then the keys would 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(:OSpath);
> whilst for linux it would be
> use IO::Linux;
> my Location $x .=new(:OSpath);
>
> 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 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, :filter)
>
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 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: Working with files wish list
On Tue, Dec 16, 2008 at 7:04 AM, jason switzer 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: 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 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: 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 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 wrote:
> From: Geoffrey Broadwell
> 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(
Re: r25172 - docs/Perl6/Spec
On Mon, Feb 2, 2009 at 1:05 PM, 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: r25172 - docs/Perl6/Spec
On Tue, Feb 3, 2009 at 8:34 AM, Richard Hainsworth 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(, :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, 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: r25328 - docs/Perl6/Spec
On Sat, Feb 14, 2009 at 6:38 AM, 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
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: 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
I'd like to note that FileDescriptors are not reserved unices. I know
Windows also has them (though they aren't commonly used), and quite
possibly others too.
Also, IO::Socket.close() is not an alternative for a shutdown()
method. They do subtly different things. IO::Socket should support
both IMHO.
Regards,
Leon
On Wed, Feb 18, 2009 at 4:30 AM, wrote:
> Author: wayland
> Date: 2009-02-18 04:30:33 +0100 (Wed, 18 Feb 2009)
> New Revision: 25371
>
> Modified:
> docs/Perl6/Spec/S16-io.pod
> Log:
> S16: Redid things in terms of trees, at least somewhat.
>
>
> Modified: docs/Perl6/Spec/S16-io.pod
> ===
> --- docs/Perl6/Spec/S16-io.pod 2009-02-17 21:05:38 UTC (rev 25370)
> +++ docs/Perl6/Spec/S16-io.pod 2009-02-18 03:30:33 UTC (rev 25371)
> @@ -204,21 +204,6 @@
> the $.locale, or the undefined value at end of file, or if there was
> an error (in the latter case C<$!> is set).
>
> -=item our List multi method lines (IO $handle:) is export;
> -
> -=item our List multi lines (Str $filename);
> -
> -Returns all the lines of a file as a (lazy) List regardless of context.
> -See also C.
> -
> -=item our Item multi method slurp (IO $handle: *%opts) is export;
> -
> -=item our Item multi slurp (Str $filename, *%opts);
> -
> -Slurps the entire file into a Str or Buf regardless of context.
> -(See also C.) Whether a Str or Buf is returned depends on
> -the options.
> -
> =back
>
> =head2 IO::Writeable::Encoded
> @@ -314,19 +299,6 @@
>
> =back
>
> -=head2 IO::FileDescriptor
> -
> -This role indicates that this object actually represents an open file
> -descriptor in the os level.
> -
> -=over
> -
> -=item method int fileno()
> -
> -File descriptors are always native integers, conforming to C89.
> -
> -=back
> -
> =head2 IO::Closeable
>
> This role indicates that this object can be closed.
> @@ -350,26 +322,17 @@
>
> =head2 IO::Socket
>
> -role IO::Socket {
> +role IO::Socket {
> + has %.options;
> ...
> }
>
> +Accessing the %.options would on Unix be done with getsockopt/setsockopt.
> +
> =over
>
> -=item socket
> +=item pair
>
> -=item IO.setsockopt
> -
> -=item IO.shutdown
> -
> -(should IO::Socket.close() call shutdown, instead of having a different
> name?)
> -
> -=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
> @@ -381,18 +344,89 @@
>
> =back
>
> -=head1 Filehandles, files, and directories
> +=head2 IO::Listening
>
> -=over 4
> +=item open
>
> -=item IO.fcntl
> + method open()
>
> -Available only as a handle method.
> + Does a bind() and a listen().
>
> -=item IO.ioctl
> +=item accept
>
> -Available only as a handle method.
> + method IO::Socket accept()
>
> +=head2 Tree Roles and Classes
> +
> +To support the filesystem, it is also useful to define some generic tree
> roles, which
> +could equally well be used for XML or LDAP as well as filesystem
> representation. However,
> +while the roles are generic, the comments and documentation in this section
> refers
> +specifically to filesystems.
> +
> +=head3 Tree::Name
> +
> + class Tree::Name {
> + has $.namespace;
> + has $.prefix;
> +
> + # Call this for stringifying
> + method fullname()
> + }
> +
> + fullname for XML does "$namespace:$prefix"
> +
> +=head3 Tree::Node
> +
> +This should be an ancestor role to filesystems, their elements, their
> attributes, and the
> +like.
> +
> + role Tree::Node does Array {
> + has Tree::Name $.name; # would usually be File or Directory on a
> filesystem
> + has $.ownerNode; # This is the IO::FileSystem
> + has $.rootNode; This is the root of the filesystem
> + has $.parent; # Another Tree::Node
> + has @.children handles ; # This is all the
> child notes
> + has $.path is ro; # Accessor does a getpath
> + has $.depth is ro; # depth from $ownerNode
> +
> + method infix:<===>(...)
> + method infix:<==>(...)
> + multi method *infix:(Tree::Node @nodes: Matcher $test);
> + multi method postfix:(Tree::Node @parents: Matcher $test);
> + method path(Str $.quitcriteria); # This allows the path call to quit
> eg. when it
> + # gets to the filesystem root, instead of the overall root
> + }
> +
> +Array operations on this are entirely capable of moving files and
> directories,
> +
> +=head3 Tree
> +
> + role Tree does Tree::Node {
> + has Tree::Node $root; # The root directory
> + has Tree::Node $cwn; # The current working directory (node)
> + }
> +
> +=head3 Tree::Element
> +
> + role Tree::Element does Tree::Node {
> + has %.attributes; # This is all the attributes, including Name
> + has Str $!defaultattributename;
> + method postcircumfix:<{ }>($selector, $node(s)); # Accesses stuff in
> %attributes
> + method pathe
Re: r25371 - docs/Perl6/Spec
On Wed, Feb 18, 2009 at 12:16 PM, Timothy S. Nelson 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: Temporal revisited
On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky 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: 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 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 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: AnyEvent
On Wed, Feb 25, 2009 at 5:56 AM, Timothy S. Nelson 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: .map/.reduce with larger arity
On Tue, Mar 10, 2009 at 12:09 AM, Larry Wall wrote:
>
> Yes, the only difference between C and C is that you can
> only use C 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: Docstrings in Perl 6
2009/5/4 Damian Conway :
>
> 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: 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: 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 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: Filename literals
On Fri, Aug 14, 2009 at 12:34 PM, David Green wrote: > Of course, this being P6, we can have some kind of "io" macro that parses > the single item after it: > > my $file1 = io file://some/dir/some%20file; # the > quick way I don't think that's a good idea. In general, parsing an URI isn't that easy, in particular determining the end is undefined AFAIK. In your example the semicolon should probably be considered part of the URI, even though that's obviously not what you intended. Using a strings or a quoting construct may be a bit more cumbersome, but at least it isn't ambiguous. Leon
Re: Filename literals
On Fri, Aug 14, 2009 at 7:41 PM, David Green 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: 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: 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 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: 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 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
On Fri, Apr 2, 2010 at 5:59 PM, Aristotle Pagaltzis 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: The obligation of free stuff: Google Storage
On Thu, Jun 10, 2010 at 9:15 AM, Richard Hainsworth
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: The obligation of free stuff: Google Storage
On Thu, Jun 10, 2010 at 2:07 PM, Mark J. Reed 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: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
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: Suggested magic for "a" .. "b"
On Wed, Jul 28, 2010 at 11:29 PM, Aaron Sherman 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: Suggested magic for "a" .. "b"
On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan 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 Thu, Jul 29, 2010 at 9:51 PM, Aaron Sherman 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 Sun, Aug 1, 2010 at 11:39 PM, Martin D Kealey 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: threads?
On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg 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 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 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 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: Lessons to learn from ithreads (was: threads?)
On Wed, Oct 13, 2010 at 1:13 PM, Tim Bunce 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 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: IO Multiplexing
On Fri, Nov 12, 2010 at 8:21 PM, Stefan O'Rear 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
