Re: IO, Trees, and Time/Date
* Timothy S. Nelson (wayl...@wayland.id.au) [090218 03:08]: > On Tue, 17 Feb 2009, Richard Hainsworth wrote: > >Moreover, if perl6 distinguishes between a location and a file, then the > >spec can distinguish between a .children() method that provides a list of > >child locations (viz., sub-directories) and .files(), which provides a > >list of the contents of the location. > > Keep in mind that files and directories are also not the only things > in a filesystem. There are links, devices, pipes, and others to worry > about. Which is why I prefer my solution. A directory contains "entries" (not children). A $directory->list() could return these children. Unless you ask for the type, mtime, or such (hidden stat) it should stay abstract for reasons of performance. On the other hand, you are also not allowed to cache the knowledge without regular verification, because facts may change. The designed interface should focus on what you want to do with the OS, on (as abstract as possible) actions. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: IO, Trees, and Time/Date
Timothy S. Nelson wrote:
On Tue, 17 Feb 2009, Richard Hainsworth wrote:
Timothy S. Nelson wrote:
be specifying our files; it's prettier than File::Spec :), and
unified.
Anyway, HTH,
I like all the default suggestions.
Not sure whether this means you completely agree with me, or
completely disagree.
Like == agree
Like !=== agree
It seems to me that a path, whether within a file system or across
the internet, leads to a location. A location is a container for
files. A file is a container for data.
Given the strong typing paradigm of Perl6, it seems to me that the
specification should distinguish between files and locations.
I think you're confusing the inside and the outside of files. For
me, the inside of a file is everything you can do to it when you've
done an open (eg. read and write). The outside of a file is the other
stuff (stat, chown, etc).
Interesting. But how is inside/outside different from container/contents ?
Methods on a container are different to methods on the content.
My idea is that a location is a container, file is also a container, but
of another sort.
I was thinking that by identifying locations as specific types of
containers, it would be possible to create an abstraction for perl6
specification that is less OS sensitive.
Let me give you an example. Say I wanted to specify a path to a
particular XML element, starting from the root of a filesystem. Say
also, for argument's sake, that when the search path came to a file
ending in .xml, it would, if there were children requested, read the
file and dig through the tree. Then I could do something like this:
/home/wayland/xml/foo.xml/html/head/title/text()
Also there is the case of archived directories and files, eg.
/home/richard/archive/version2.zip/foo/text.txt
Version2.zip is considered by the OS as a file.
Note that the directory called "xml" doesn't contain the file
called "foo.xml". Instead, it contains a filesystem entry called
"foo.xml". This filesystem entry in turn points to the contents
(which I look at with an XML path).
In other words, note the distinction between the *contents* of the
file, and the entry in the file system that refers to it. Which is
the file? Colloquially, both, but I'd argue that technically, the file
is the *contents*, not the filesystem entry.
Well, even here, and all define conceptual
containers within the marked up datastream. But the datastream is
defined as a string of octets, and in this example, the initial string
with something like
has been ignored in your example. So it is not the perl6 core that is
allowing path definition to an html fragment.
For example, it is sensible to have a .files() method for a
directory, but it is not sensible for such a method to exist for a
file. Meanwhile, print/say/putc are not sensible for a
directory/location.
So I was not entirely right in saying .files has no meaning for a file,
if the file is a zip archive. But both can be considered locations, even
though for unix/windows a zip file is considered a file.
But isnt that a feature of the OS?
I'd argue that we want three things here, if we go down this path:
IO::Dir.files()
IO::FileNode.lines()
IO::File.printf()
No I dont think so. There is a difference between a source of data and
data.
For example, suppose we set up a connection to a database that generates
multiple lines
and we associate (I am guessing about the syntax here) the data base
response with a filehandle
my $fh = $database.connect('select "Month","Name", "Capital",
"Total_Assets" from "Banks" where id "month" > "20071201" ');
for =$fh -> @record {...};
The data stream is in lines, but the source is not a file. Yet
supposing, the same data had been saved to a file and $fh had been
associated with the file as a source. As far as the code in the for loop
is concerned, it is the same data stream.
But the data stream generated from querying a location where a number of
files are located in a filestore is different from the datastream from
file.
However, it seems to me that maybe the .files() method is heading
in the direction of PHPs 1001 string functions. It might be better
like this:
$dir = new IO::Dir("/home/wayland");
@files = grep { -f } @$dir;
But this is exactly what I think should be avoided. -f implies that the
location $dir contains things other than files. But that is an artifact
of the OS and should be hidden within the implementation of perl, or
made available by a OS-specific package.
When I started learning perl (I used Windows platform at that time) I
was confronted with a bewildering array of functionality. Some was part
of perl and I could use, nearly all the IO functions were specific to
Unix, and I never ever used. But I spent a considerable amount of time
working out what was and wasnt useful to me at the time.
I know @$dir is bad perl6, but I hope you'll take the idea, in
that, when we t
r25380 - docs/Perl6/Spec
Author: wayland
Date: 2009-02-18 11:04:41 +0100 (Wed, 18 Feb 2009)
New Revision: 25380
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
Fixed .new() methods to have correct name (instead of .init(), like I had)
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-02-18 09:35:48 UTC (rev 25379)
+++ docs/Perl6/Spec/S16-io.pod 2009-02-18 10:04:41 UTC (rev 25380)
@@ -535,7 +535,7 @@
multi method infix:{'<=>'}(DateTime $self, DateTime $other);
multi method infix:{'<=>'}(DateTime $self, Duration $other);
- method init();
+ method new(Str $String);
method truncate(Str $to);
method last(Str $type, Str $of);
method toString($format?);
@@ -546,9 +546,9 @@
=over
-=item init
+=item new
- method init(Str $String) # parser defaults to 'strptime' or something similar
+ method new(Str $String) # parser defaults to 'strptime' or something similar
| (Str $parser, Str $String) # $parser = 'strptime'
| (Str $parser, Int $Epoch) # $parser = 'epoch'
| (Str $parser, Str $Timezone?) # $parser = 'today' [unless strptime
does this]
@@ -594,10 +594,10 @@
=over
-=item init
+=item new
- method init(Str $filename, $options?);
- method init(Int $fd);
+ method new(Str $filename, $options?);
+ method new(Int $fd);
# Read
$fobj = new IO::File($filename);
@@ -811,15 +811,15 @@
Test whether the specified filename is the same file as this file. On a Unix
system,
this would presumably be done by comparing inode numbers or something.
-=item init
+=item new
-This is called automatically on object creation; I'm unsure if init is the
right name.
+This is called automatically on object creation.
-multi method init(@pathelements); # new IO::FSNode('home', 'wayland')
-multi method init(String $type, String $path) # new IO::FSNode('Unix',
'/home/wayland');
-multi method init(String $path) # new IO::FSNode('/home/wayland');
+multi method new(@pathelements); # new IO::FSNode('home', 'wayland')
+multi method new(String $type, String $path) # new IO::FSNode('Unix',
'/home/wayland');
+multi method new(String $path) # new IO::FSNode('/home/wayland');
-This last throws an error if "use portable" is used.
+This last throws an error if "use portable" pragma is used.
=back
@@ -914,9 +914,9 @@
=item has $.LocalPort
-=item init
+=item new
- method Bool init(
+ method Bool new(
$RemoteHost, $RemotePort,
$LocalHost?, $LocalPort?,
$Blocking?,
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: IO, Trees, and Time/Date
Em Ter, 2009-02-17 às 22:38 +1100, Timothy S. Nelson escreveu: > My third thought is that it would be very useful also to have > date/time objects that integrate well with eg. ctime, mtime, and the like; > I'd > start with Time::Piece as a model. > http://search.cpan.org/dist/Time-Piece/Piece.pm er... Could I suggest using DateTime instead of Time-Piece, it seems to have a far more complete design and implementation... daniel
Re: r25371 - docs/Perl6/Spec
On Wed, 18 Feb 2009, Leon Timmermans wrote: 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. Will be fixed in next update. Also, IO::Socket.close() is not an alternative for a shutdown() method. They do subtly different things. IO::Socket should support both IMHO. 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. - | 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-
r25382 - docs/Perl6/Spec
Author: wayland
Date: 2009-02-18 12:16:00 +0100 (Wed, 18 Feb 2009)
New Revision: 25382
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
Fixed some things people were complaining about.
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-02-18 11:11:32 UTC (rev 25381)
+++ docs/Perl6/Spec/S16-io.pod 2009-02-18 11:16:00 UTC (rev 25382)
@@ -54,6 +54,16 @@
This role provides unbuffered read access to the data stream.
+role IO::Readable {
+ has $.isReadable;
+
+ method Int read($buf is rw, Int $length)
+}
+
+When the $.isReadable is set, it tries to change the readability of the
filehandle. This
+is not always possible, but can be done in a number of cases. IO::Socket can
remove
+readability by calling shutdown(), for example.
+
=over
=item method Int read($buf is rw, Int $length)
@@ -68,17 +78,22 @@
you're going to need to encode it later, or use "getc" or other
IO::Readable::Encoded methods.
-=item method Bool is_readable()
-
-Indicates whether socket is actually opened for reading. Closed sockets
-return false.
-
=back
=head2 IO::Writeable
This role provides unbuffered write access to the data stream.
+role IO::Writeable {
+ has $.isWriteable;
+
+ method Int write($buf, Int $length)
+}
+
+When the $.isWriteable is set, it tries to change the writeability of the
filehandle.
+This is not always possible, but can be done in a number of cases. IO::Socket
can remove
+writeability by calling shutdown(), for example.
+
=over
=item method Int write($buf, Int $length)
@@ -92,11 +107,6 @@
encoded data, you should decode it first, or use "print" or other
IO::Writeable::Encoded methods.
-=item method Bool is_writeable()
-
-Indicates whether socket is actually opened for writing. Closed sockets
-return false.
-
=back
=head2 IO::Seekable
@@ -356,6 +366,19 @@
method IO::Socket accept()
+=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 Tree Roles and Classes
To support the filesystem, it is also useful to define some generic tree
roles, which
@@ -535,7 +558,7 @@
multi method infix:{'<=>'}(DateTime $self, DateTime $other);
multi method infix:{'<=>'}(DateTime $self, Duration $other);
- method new(Str $String);
+ method new(:$String);
method truncate(Str $to);
method last(Str $type, Str $of);
method toString($format?);
@@ -548,7 +571,7 @@
=item new
- method new(Str $String) # parser defaults to 'strptime' or something similar
+ method new(Str :$String) # parser defaults to 'strptime' or something similar
| (Str $parser, Str $String) # $parser = 'strptime'
| (Str $parser, Int $Epoch) # $parser = 'epoch'
| (Str $parser, Str $Timezone?) # $parser = 'today' [unless strptime
does this]
@@ -596,8 +619,8 @@
=item new
- method new(Str $filename, $options?);
- method new(Int $fd);
+ method new(Str :$filename, $options?);
+ method new(Int :$fd);
# Read
$fobj = new IO::File($filename);
@@ -815,12 +838,18 @@
This is called automatically on object creation.
-multi method new(@pathelements); # new IO::FSNode('home', 'wayland')
-multi method new(String $type, String $path) # new IO::FSNode('Unix',
'/home/wayland');
-multi method new(String $path) # new IO::FSNode('/home/wayland');
+multi method new(Array of Str :@pathelements);
+multi method new(String :$type, String :$path);
+multi method new(String :$path);
This last throws an error if "use portable" pragma is used.
+Examples:
+
+ $fsnode = new IO::FSNode(pathelements => ['home', 'wayland']);
+ $fsnode = new IO::FSNode(type => 'Unix', path => '/home/wayland');
+ $fsnode = new IO::FSNode(path => '/home/wayland');
+
=back
=head2 IO::FSNodeACL
@@ -916,11 +945,11 @@
=item new
- method Bool new(
- $RemoteHost, $RemotePort,
- $LocalHost?, $LocalPort?,
- $Blocking?,
- $NoOpen?
+ method IO::Socket::TCP new(
+ :$RemoteHost, :$RemotePort,
+ :$LocalHost, :$LocalPort,
+ :$Blocking,
+ :$NoOpen
);
The creation of the object will also open the connection, unless NoOpen is
specified.
@@ -1010,19 +1039,6 @@
=head2 Unix
-=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::FSNode::Unix
=item chown
@@ -1170,7 +1186,7 @@
=item IO.shutdown()
-Gone, see IO::Socket.close()
+Gone, see IO::Socket.close(), $IO::Readable.isReadable, and
$IO::Writeable.isWriteable
=item socketpair
Re: IO, Trees, and Time/Date
Actually, it seems to me that we do agree fundamentally, although using
different terminology.
And like I said in an earlier email, I do like/agree with the way you
are taking the Spec.
Also, it seems to me a re-ordering of the material in the Specs would
make more sense.
On our disagreement:
Timothy S. Nelson wrote:
On Wed, 18 Feb 2009, Richard Hainsworth wrote:
$dir = new IO::Dir("/home/wayland");
@files = grep { -f } @$dir;
But this is exactly what I think should be avoided. -f implies that
the location $dir contains things other than files. But that is an
artifact of the OS and should be hidden within the implementation of
perl, or made available by a OS-specific package.
I suspect this is where our disagreement comes in. I don't agree
that it's an artifact of the OS. Can you give me an example of an OS
that doesn't work that way?
OK and when I wrote this I knew I was half-wrong.
Its just that in my view of a directory as a location container, my idea
was that the methods available on the container would yield different
sorts of contents. Hence,
my $dir .= new IO::Dir($path); # Note the .= is perl6 for the mutating
method new, not a = as in perl5
my @files = $dir.files; # I think this is correct in that here the array
is not typed.
my @subdirectories = $dir.children;
#But if File is a type, then I am not sure what the correct syntax would
be. Perhaps
my @files of IO::File <== $dir.files; # lazily evaluated
my @subdirectories of IO::Dir <== $dir.children;
I dont think your @$dir is correct because you have an object $dir, not
a pointer to an array, which is implied in perl5 by the '@$' syntax.
For what you want, I would think, you need
@files = grep { :f } $dir.contents; # note the adverbial form, which is
mentioned in one of the other specs.
By analogy there would be
@subdirectories = grep { :d } $dir.contents;
And here, as above in my example, although we have explicitly declare
dir as a IO::Dir object, we have not declared the directories in
@subdirectories as IO::Dir, which they are too.
However, in so far as our disagreement is concerned, it seems to be one
of style rather than substance.
I would prefer methods on objects that yield the various types of
content, you would prefer adverbial tests to be used on all contents.
Mind you, I think in one of the other Synopses, I read that the
adverbial form actually translates into a method, so both are equivalent.
None, I agree. But even things on the Internet can have container
attributes. That would be eg. HTTP headers. Maybe not *everything*
has attributes on the container, but it seems to me that almost
anything I can think of does.
I'll be interested to see where this heads next :).
Me too :)
So, for starters:
Can we abstract enough so that there is no difference between a database
producing data and a file producing data?
Given that a file containing archive data or xml/html data is both a
source of data, but also a container / location. Consequently, if File
and Directory are types, then if a file does contain data then the
filehandle associated with it can be coerced into the Directory type?
Just as Int can be coerced into Num.
What needs to be abstracted so that a perl6 program can know that a
Writeable may not be able to accept data (eg., because the file system
is full)?
How about connections eg., to internet sites, that were working, but
have broken during software operation.
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: IO, Trees, and Time/Date
On Wed, Feb 18, 2009 at 6:36 AM, Richard Hainsworth wrote: > What needs to be abstracted so that a perl6 program can know that a > Writeable may not be able to accept data (eg., because the file system is > full)? I don't understand the question. To be a Writable, an object must have a mechanism for accepting data. That mechanism may fail for any of a large number of reasons (out of space, no permission, etc...), but that's orthogonal to the fact that it's a Writable. A Readable is not the same thing as "a Writable you can't actually write to right now". Side question: are HTTP URI's Writable? If so, I imagine that translates into a PUT. Is there any benefit in abstracting out the functionality of POST in a way that maps to other resource types? -- Mark J. Reed
Re: IO, Trees, and Time/Date
On Wed, 18 Feb 2009, Mark J. Reed wrote: On Wed, Feb 18, 2009 at 6:36 AM, Richard Hainsworth wrote: What needs to be abstracted so that a perl6 program can know that a Writeable may not be able to accept data (eg., because the file system is full)? I don't understand the question. To be a Writable, an object must have a mechanism for accepting data. That mechanism may fail for any of a large number of reasons (out of space, no permission, etc...), but that's orthogonal to the fact that it's a Writable. A Readable is not the same thing as "a Writable you can't actually write to right now". I've added an isWriteable to the IO::Writeable filehandle, which should hopefully cover what Richard is after. Side question: are HTTP URI's Writable? If so, I imagine that translates into a PUT. Is there any benefit in abstracting out the functionality of POST in a way that maps to other resource types? Hmm. Interesting question. My reason for getting into S16 in the first place was that I was interested in implementing some protocols. The generic mechanisms that I think would be generally useful for protocols are: - A grammar language, for the grammar of the protocol - An event loop (see Perl 5 module "POE") - A finite state machine (see POE again) What I've been wondering about is how a grammar of the protocol would interact with something that generates the protocol. I see the HTTP POST command as an instance of the more general "Command with data"-type setup, such as also occurs with SMTP's "data" command, although I think the two are slightly different. Anyway, I see the S16 method called "prompt" to be a step in the right direction, although it doesn't seem to be attached to an appropriate class/role yet, and also probably couldn't deal with the HTTP POST command. These are just some random thoughts that occurred to me; maybe they'll spark something in someone's mind. :) - | 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: r25371 - docs/Perl6/Spec
On Wed, 18 Feb 2009, Leon Timmermans wrote: 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. Ok. I agree that's significant. But, while I agree that the difference is significant in *effect*, and is an essential part of the difference between files and sockets, I thought the purpose of having a somewhat abstract interface was to paper over differences like these. Fundamentally, a recv() is a different call than a read(), but yet they're similar enough in interface that it doesn't make a lot of difference from a Perl point of view. Would a note in the documentation suffice to distinguish between them? :) - | 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: IO, Trees, and Time/Date
On Wed, 18 Feb 2009, Richard Hainsworth wrote:
For what you want, I would think, you need
@files = grep { :f } $dir.contents; # note the adverbial form, which is
mentioned in one of the other specs.
Yup, thanks.
By analogy there would be
@subdirectories = grep { :d } $dir.contents;
And here, as above in my example, although we have explicitly declare dir as
a IO::Dir object, we have not declared the directories in @subdirectories as
IO::Dir, which they are too.
However, in so far as our disagreement is concerned, it seems to be one of
style rather than substance.
I would prefer methods on objects that yield the various types of content,
you would prefer adverbial tests to be used on all contents.
Mind you, I think in one of the other Synopses, I read that the adverbial
form actually translates into a method, so both are equivalent.
Hmm. That's not something I can find, but if you see it anywhere, let
me know.
None, I agree. But even things on the Internet can have container
attributes. That would be eg. HTTP headers. Maybe not *everything* has
attributes on the container, but it seems to me that almost anything I can
think of does.
I'll be interested to see where this heads next :).
Me too :)
So, for starters:
Can we abstract enough so that there is no difference between a database
producing data and a file producing data?
If by "database", you mean "query results", probably, if
input_field_separator is defined on the file.
Given that a file containing archive data or xml/html data is both a source
of data, but also a container / location. Consequently, if File and Directory
are types, then if a file does contain data then the filehandle associated
with it can be coerced into the Directory type? Just as Int can be coerced
into Num.
In the case of archives, I'd argue "yes".
In the case of XML, I'd argue no, but it should be possible to coerce
it into another Tree::Node type. Since both directories and XML would both
implement the Tree::Node role, they'd have a fair number of common operations.
What needs to be abstracted so that a perl6 program can know that a Writeable
may not be able to accept data (eg., because the file system is full)?
See other e-mail in this thread :).
How about connections eg., to internet sites, that were working, but have
broken during software operation.
That should hopefully change the isReadable/isWriteable, but if not,
then read/write calls can throw an exception.
:)
-
| 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: Spec reorganisation
Hi, Timothy S. Nelson wrote: > I'm not suggesting here that we specify the interfaces to all the > modules listed in the Camel book, or anything like that. Instead, I'm > suggesting that the S32 space be used for documenting the objects that we > don't seem to be able to get away from. Aye. Synopsis -> Api documentation is a good transition. > - The IO, Tree, and DateTime stuff being drafted in S16 Speaking of Tree, let me quote from IRC: 09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now squatted by an internal class in Perl 6, which is not general enough to reprenest an arbitrary tree data structure. I fully agree with that. If it's not the most general tree, don't name it Tree. > After looking through the Phlanx project (which lists 100 or so top > perl modules), and the list in the Camel book, I can only see one or two > other > things we might eventually need, and these can be worried about later. > > Anyway, my suggestion is that a folder called S32-standard-modules be > created in the Spec directory, I'd just call that 'lib/', in good old Perl tradition. > and that within this folder, the following > files be created from the specified sources: > - Tree.pod -- S16 > - DateTime.pod -- S16 (needs lots of work) > - IO.pod -- S16 > - Most of the stuff from the S29 "Function Packages", in separate files > > This would leave S29 free to be solely a list of the functions that > do not need to have a package specified when called, and can in most cases > simply specify what standard library functions they call. > > It would also leave S16-IO free to deal with things that are not > specific to the object(s). like time(), bare say/print being a compile time error etc. I really like the idea, but I'd go one step further: In addition to the API documentation you could also just implement the thing. Especially the DateTime stuff doesn't need any fancy feature that rakudo doesn't do yet (afaict), so it would be nice not only to spec it, but also to provide a pure Perl 6 implementation that can later be shared among compilers. Perl 6 is full of stuff that's specced but not implemented, and I'd like to see that gap closed as much as possible. Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Spec reorganisation
Sorry, this was supposed to go to the mailing list. On Wed, 18 Feb 2009, Timothy S. Nelson wrote: After looking through the Phlanx project (which lists 100 or so top perl modules), and the list in the Camel book, I can only see one or two other things we might eventually need, and these can be worried about later. Anyway, my suggestion is that a folder called S32-standard-modules be created in the Spec directory, I'd just call that 'lib/', in good old Perl tradition. Hmm. But isn't lib/ for actual code? As a follow-up to my own message, I'm now suggesting (after some IRC discussion) that it maybe should be called S32-setting-library. Perl 6 is full of stuff that's specced but not implemented, and I'd like to see that gap closed as much as possible. Agreed. My main problem is that I don't know any Parrot :). But as long as things can be written in Perl6, I'm happy to work at them. ...and as a follow-up to this, I ran into someone on IRC who *does* want to do this if it requires Parrot, as something to help them learn PIR. :) - | 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- - | 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: Spec reorganisation
...and this was too. On Wed, 18 Feb 2009, Moritz Lenz wrote: Hi, Timothy S. Nelson wrote: I'm not suggesting here that we specify the interfaces to all the modules listed in the Camel book, or anything like that. Instead, I'm suggesting that the S32 space be used for documenting the objects that we don't seem to be able to get away from. Aye. Synopsis -> Api documentation is a good transition. - The IO, Tree, and DateTime stuff being drafted in S16 Speaking of Tree, let me quote from IRC: 09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now squatted by an internal class in Perl 6, which is not general enough to reprenest an arbitrary tree data structure. I fully agree with that. If it's not the most general tree, don't name it Tree. Hmm. I'm wanting the API for this tree structure to be able to represent arbitrary general trees. I'm limited by the fact that the main trees I'm familiar with are filesystems and XML, and a little with LDAP. Can you give examples of types of tree that aren't representable with what I'm doing? After looking through the Phlanx project (which lists 100 or so top perl modules), and the list in the Camel book, I can only see one or two other things we might eventually need, and these can be worried about later. Anyway, my suggestion is that a folder called S32-standard-modules be created in the Spec directory, I'd just call that 'lib/', in good old Perl tradition. Hmm. But isn't lib/ for actual code? and that within this folder, the following files be created from the specified sources: - Tree.pod -- S16 - DateTime.pod -- S16 (needs lots of work) - IO.pod -- S16 - Most of the stuff from the S29 "Function Packages", in separate files This would leave S29 free to be solely a list of the functions that do not need to have a package specified when called, and can in most cases simply specify what standard library functions they call. It would also leave S16-IO free to deal with things that are not specific to the object(s). like time(), bare say/print being a compile time error etc. ...and somewhere to hash out IPC and sockets, unless they look like turning into libraries too :). I really like the idea, but I'd go one step further: In addition to the API documentation you could also just implement the thing. Especially the DateTime stuff doesn't need any fancy feature that rakudo doesn't do yet (afaict), so it would be nice not only to spec it, but also to provide a pure Perl 6 implementation that can later be shared among compilers. Agreed, but since this is a chance for a real redesign, and I don't claim to understand any of these areas very well, I figure I'd better try to get the interface right before I start implementing :). Perl 6 is full of stuff that's specced but not implemented, and I'd like to see that gap closed as much as possible. Agreed. My main problem is that I don't know any Parrot :). But as long as things can be written in Perl6, I'm happy to work at them. - | 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- - | 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-
Parrot 0.9.1 "Final Countdown" released!
o/~ We're leaving together, but still its farewell o/~ o/~ And maybe we'll come back, To earth, who can tell? o/~ o/~ I guess there is no one to blame We're leaving ground Will things ever be the same again? o/~ o/~ It's the Final Countdown... The Final Countdown o/~ --Europe, "The Final Countdown" On behalf of the Parrot team, I'm proud to announce Parrot 0.9.1 "Final Countdown." Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.9.1 is available via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.9.1 News: - Implementation + Support for portable 'Inf', 'NaN' and -0.0 + pbc_disassemble prints constants in constants table + New experimental BigNum implementation + Pair is now a dynamic loadable PMC + Various function name sanification + New implementation of Strings component + Replace various PMC value union access code by VTABLE method invocations + Replace various PMC value unions by ATTRibutes + Removed SArray PMC. Use FixedPMCArray instead. - Documentation + Book - updates to Chapter 2 (getting started) - updates to Chapter 3 (PIR basics) - updates to Chapter 4 (PIR subroutines) - updates to Chapter 10 (HLLs) - updates to Chapter 12 (opcodes) + Function documentation + Pod documentation style modernized; no longer Perl 5 style. + PMC has an additional acronym: Poly Morphic Container + The DOD (Dead Object Detection) acronym is no longer used; use 'GC' to refer to the Garbage Collector component. - Compilers + IMCC - :named flag can now take string registers as argument - A single '=cut' directive is now ignored (without initial Pod directive) - :vtable subs now have proper access to 'self' pseudo variable - Languages + add new 'Pod' documentation parser + Pipp (PHP implementation): - Pipp is now at http://github.com/bschmalhofer/pipp - support for 'print', 'dirname', 'implode', 'str_replace', - various grammar fixes + ECMAScript + add 'quit', 'readline' builtins + fix 'Boolean' type and 'print' builtin + Lua - left the nest and is now at http://github.com/fperrad/lua/ + Rakudo - left the nest and is now at http://github.com/rakudo/rakudo/ - build instructions can be found at http://tinyurl.com/rakudo + lazy-k - left the nest and is now at http://github.com/bschmalhofer/lazy-k.git + unlambda - left the nest and is now at http://github.com/bschmalhofer/unlambda/ + WMLScript - left the nest and is now at http://github.com/fperrad/wmlscript.git + removed Zcode implementation - Tools + pmc2C - ATTRs are now inherited automatically in subclassing PMCs - Deprecations + Parrot_readbc, Parrot_loadbc renamed to Parrot_pbc_read, Parrot_pbc_load. + .HLL_map directive in favour of 'hll_map' method on Parrot interpreter + Data::Escape library - Tools + pbc_disassemble options added + pbc_dump renamed from pdump - Miscellaneous + Parrot is now Copyright Parrot Foundation + Parrot's SVN repository is now hosted at https://svn.parrot.org + Various code cleanups, consting, 64-bit incompatibilities and other bug fixes Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 17 March 2009. Enjoy!
Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)
TSa wrote:
> HaloO,
>
> Daniel Ruoso wrote:
>> Em Ter, 2009-02-17 às 09:19 -0300, Daniel Ruoso escreveu:
>>> multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {...}
>>
>> As masak++ and moritz++ pointed out, this should be written
>>
>> multi infix:<+> (int $i where 2, int $j where 2) {...}
>
> Hmm, both these forms strike me as odd because the where clause
> should return a boolean and thus has to be written 'where { $_ == 2}'.
A where clause without a block does a smartmatch, so $i where 2 is the
same as $i where { $i ~~ 2 }.
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: IO, Trees, and Time/Date
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
> I'll try and design an API that does what DateTime does, but:
> 1. Uses more variables, of which I expect the getters and setters to be
> overridden.
Please let's NOT have setters on "time" objects. They're a source of subtle
bugs in such client code AND having mutable objects means you can't use them
in otherwise pure code. (See the separate thread on immutability and
purity.)
Rather, let's have immutable time "values", and methods which return other
"values" where various computations (*1) have been applied. Provide
constructors which take the Y/M/D/h/m/s/dst_now/dst_rule tuple.
And please let's not have any implied "default" timezone. That's not to say
it has to be difficult or cumbersome, just explicit, perhaps something like
one of these:
my &localtime = DateTime::Gregorian.localize( :host_default );
my &localtime = DateTime::Gregorian.localize( :user_env );
my &localtime = DateTime::Gregorian.localize(
:http_client(%http_client_headers) );
my &localtime = DateTime::Gregorian.localize( :db_server($odbc_handle) );
my &gmtime= DateTime::Gregorian.localize( :utc );
my &swatch= DateTime::Gregorian.localize( :tz('Europe/Geneva'), :no_dst );
-Martin
*1: Operations on localtime objects involve differences, offsets and
baselines, expressed in a range of units.
The core units are seconds, minutes and days which are almost-but-not-quite
exact multiples of each other (consider leap seconds (*2) and daylight
saving). It is up to the client code to choose whether to treat an "hour"
offset as exactly 1/24 day or as exactly 60 minutes. If you want a
sunrise-based local time then that's a different library entirely.
In the Gregorian and Julian calendars a "year" is an exact multiple of a
"month", which is not an exact multiple of any core unit.
A true astronomical calendar will take a "lunar month" to be ~2.551E6
seconds and a "solar year" to be ~3.1557E7 seconds; a tabular calendar will
need them to be yet more separate offset types, and a separate library.
*2: Or not, if you're on a POSIX host, in which case you sometimes get a
peculiar "second" that takes twice as long as most, while a "minute" is
always and precisely 60 "seconds".
Re: IO, Trees, and Time/Date
On Wed, 18 Feb 2009, Timothy S. Nelson wrote: Agreed, and that's kinda what I'm doing. But I still think there's room for improvement. I'll try and design an API that does what DateTime does, but: 1. Uses more variables, of which I expect the getters and setters to be overridden. What does that mean? 2. Documents in terms of operator overloading I'm assuming that Perl 6 will make overloading saner. In Perl 5, it's a nasty hack. 3. Depends a lot more on CLDR formats Yes! 4. Doesn't have multiple functions that perform exactly the same thing Also yes. I copied this from Time::Piece, for reasons that probably made sense at the time. 5. As a consequence of all of the above, has a lot fewer functions (while still providing all the same functionality). Also good. I've actually started on some DateTime stuff for Perl 6, sort of. One thing I'd like to do is have Date, Time, and DateTime classes. There's a lot of people who _only_ need dates, and having to deal with time (and therefore time zones and other madness) is a useless conceptual burden. I was also hoping to separate out leap second handling so that it was a layer on top of a simple TAI-based underpinning. But really, I'd hate to see any of this be core. Date and time modules will need to be released regularly to keep up with things like locale updates, time zone changes, leap second announcements, etc. It wasn't clear to me whether you were proposing putting this yet-to-be-named thing core, of course. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
r25403 - in docs/Perl6/Spec: . S32-setting-library
Author: wayland
Date: 2009-02-19 05:08:23 +0100 (Thu, 19 Feb 2009)
New Revision: 25403
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S29-functions.pod
docs/Perl6/Spec/S32-setting-library/Any.pod
docs/Perl6/Spec/S32-setting-library/Containers.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
docs/Perl6/Spec/S32-setting-library/Numeric.pod
docs/Perl6/Spec/S32-setting-library/Scalar.pod
docs/Perl6/Spec/S32-setting-library/String.pod
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
S16/S32: Moved Temporal and Tree stuff from S16 to S32
S29: Added myself, because of last update
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-02-19 03:46:06 UTC (rev 25402)
+++ docs/Perl6/Spec/S16-io.pod 2009-02-19 04:08:23 UTC (rev 25403)
@@ -13,8 +13,8 @@
Tim Nelson
Daniel Ruoso
Date: 12 Sep 2006
- Last Modified: 14 Feb 2009
- Version: 19
+ Last Modified: 19 Feb 2009
+ Version: 20
This is a draft document. Many of these functions will work as in Perl
5, except we're trying to rationalize everything into roles. For
@@ -379,237 +379,8 @@
=back
-=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 entire tree
- has $.parent; # linked with @parents[0] (see below)
- has @.parents; # Tree::Node array
- 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)
- has Bool $can_multiple_parent; # Nodes can have multiple parents
- has Bool $can_link; # Unix links, Windows shortcuts, etc
- }
-
-=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 pathelement();
- }
-
-=head3 Tree::Attribute
-
- role Tree::Attribute does Tree::Node {
- has $.value;
-
-method pathelement();
- }
-
-=head2 Time and Date roles
-
-=head3 Date
-
-You probably want to use the DateTime object instead.
-
-role Date {
- has Calendar $.calendar; # Gregorian, Secular, Julian, etc
- 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;
-
- method toString($format);
- method isLeapYear();
-
- multi method DateTime infix:<+>(Date $self, Time $other);
- multi method DateTime infix:<+>(Date $self, Duration $other);
-
- multi method infix:{'<=>'}(Date $self, Date $other);
- multi method infix:{'<=>'}(Date $self, Duration $other);
-
- method get(Str $type, Str $of);
- method last(Str $type, Str $of);
-}
-
-Example:
-
-$date = new Date('2002/01/01');
-$date.month.name(); # January
-$date.month.name('short'); # Jan
-$date.get('day', of => 'year');
-
-$date = new Date('2002/01/01');
-$date.convertcalendar('Chinese');
-$date.year.name(); # Snake
-
-A fair bit of initialisation of the NumberNames for day of the week and month
will need to
-be done.
-
-$format will naturally need to allow for eras.
-
-=over
-
-=item
-
- method toString($format = '/MM
Re: IO, Trees, and Time/Date
On Wed, 18 Feb 2009, Dave Rolsky wrote:
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
Agreed, and that's kinda what I'm doing. But I still think there's
room for improvement. I'll try and design an API that does what DateTime
does, but:
1. Uses more variables, of which I expect the getters and setters to be
overridden.
What does that mean?
s/variables/attributes/ in what I said. Basically, I'm proposing
something like:
roleInstant { # Someone suggested Instant instead of DateTime
has $hour;
has $epoch;
...
}
Then we could do this:
$tobj = new Instant(...);
$tobj.epoch = 123456789;
$thishour = $tobj.hour;
...and when we read the hour, it will automatically convert from the
epoch.
2. Documents in terms of operator overloading
I'm assuming that Perl 6 will make overloading saner. In Perl 5, it's a nasty
hack.
That's the plan.
5. As a consequence of all of the above, has a lot fewer functions
(while still providing all the same functionality).
Also good.
I've actually started on some DateTime stuff for Perl 6, sort of.
Great! That's a relief to me :).
One thing I'd like to do is have Date, Time, and DateTime classes. There's a
lot of people who _only_ need dates, and having to deal with time (and
therefore time zones and other madness) is a useless conceptual burden.
I've specced that, but was about to kill it until you recommended it
:).
I was also hoping to separate out leap second handling so that it was a layer
on top of a simple TAI-based underpinning.
I'll leave leap seconds to you :).
But really, I'd hate to see any of this be core. Date and time modules will
need to be released regularly to keep up with things like locale updates,
time zone changes, leap second announcements, etc.
Yeah, I can see the problems. My plan is to make some simple roles
that could be composed into the real DateTime objects later on.
It wasn't clear to me whether you were proposing putting this yet-to-be-named
thing core, of course.
After discussion on IRC, I'd say a simple one in core, just enough to
do what the other core modules need, and leave the heavy lifting to CPAN.
:)
-
| 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: Spec reorganisation
Timothy (>), Moritz (>>):
>> Speaking of Tree, let me quote from IRC:
>>
>> 09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now
>> squatted by an internal class in Perl 6, which is not
>> general
>> enough to reprenest an arbitrary tree data structure.
>>
>> I fully agree with that. If it's not the most general tree, don't name
>> it Tree.
>
>Hmm. I'm wanting the API for this tree structure to be able to
> represent arbitrary general trees. I'm limited by the fact that the main
> trees I'm familiar with are filesystems and XML, and a little with LDAP.
> Can you give examples of types of tree that aren't representable with what
> I'm doing?
I'll give it a shot. As previously seen in S16:
role Tree does Tree::Node {
has Tree::Node $root; # The root directory
has Tree::Node $cwn; # The current working directory (node)
has Bool $can_multiple_parent; # Nodes can have multiple parents
has Bool $can_link; # Unix links, Windows shortcuts, etc
}
A tree is a graph without cycles. The concept of a "root" is very
common in computer representations, but in no way necessary for a
general tree. In fact, in phylogenetics, it's business as usual to
handle unrooted trees. This makes the $root attribute meaningless in
at least some cases.
The $cwn is meaningless in most tree implementations I can think of.
As to $can_multiple_parent, a structure which allows nodes with
multiple parents is not a tree, it's a directed graph. Whether
symlinks are allowed is (1) fairly filesystem-specific, and (2) not
very pertinent to the tree object itself.
What's left is, in effect, this:
role Tree does Tree::Node {
}
While an empty role _does_ indeed have potential, and could be made to
work with most tree implementations out there, it's also a bit of a
shame to pretend to provide four attributes with Tree, neither of
which is actually an attribute of a general graph-theoretical tree.
Just sayin'.
Another thing I found myself saying yesterday was that "designing a
language also involves knowing when not to decide things for the
programmer." I wish there was a way to say this, while also
emphasizing my appreciation for the many good changes to S16. Files
and I/O are obviously areas where the bikeshedding tendency grows
extra strong, so I'm glad someone actually goes in and does things to
the spec.
But I do believe that creating a general tree role of the above kind
would be unfortunate in at least two ways: it'd limit the possible
implementations of trees (while not giving much back in terms of an
advantage), and it'd use up the perfectly good name "Tree". I'd say
keep it simple, keep directory structures and XML DOM trees separate,
and don't let Perl second-guess what you want to implement.
// Carl
r25405 - docs/Perl6/Spec/S32-setting-library
Author: wayland
Date: 2009-02-19 08:47:26 +0100 (Thu, 19 Feb 2009)
New Revision: 25405
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
Improved Temporal (previously DateTime) stuff a bit
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-02-19 07:45:07 UTC
(rev 25404)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-02-19 07:47:26 UTC
(rev 25405)
@@ -66,35 +66,25 @@
=head1 Roles
-=head2 Time and Date roles
+=head2 Temporal::Date
-=head3 Date
+You probably want to use the Temporal::Instant object instead.
-You probably want to use the DateTime object instead.
+role Temporal::Date {
+ has Int $.year;
+ has Int $.month;
+ has Int $.day; # Day of month
+ has Int $.dayofweek;
+ has Int $.era; # BC, AD, etc, depending on locale
+ has Str $.defaultformat; # A CLDR-formatted string, for use with
toString();
-role Date {
- has Calendar $.calendar; # Gregorian, Secular, Julian, etc
- 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;
+ method toString($format => $.defaultformat);
- method toString($format);
- method isLeapYear();
+ multi method Temporal::Instant infix:<+>(Temporal::Date $self,
Temporal::Time $other);
+ multi method Temporal::Instant infix:<+>(Temporal::Date $self,
Temporal::Duration $other);
- multi method DateTime infix:<+>(Date $self, Time $other);
- multi method DateTime infix:<+>(Date $self, Duration $other);
-
- multi method infix:{'<=>'}(Date $self, Date $other);
- multi method infix:{'<=>'}(Date $self, Duration $other);
-
- method get(Str $type, Str $of);
- method last(Str $type, Str $of);
+ multi method infix:{'<=>'}(Temporal::Date $self, Temporal::Date $other);
+ multi method infix:{'<=>'}(Temporal::Date $self, Temporal::Duration
$other);
}
Example:
@@ -102,15 +92,7 @@
$date = new Date('2002/01/01');
$date.month.name(); # January
$date.month.name('short'); # Jan
-$date.get('day', of => 'year');
-$date = new Date('2002/01/01');
-$date.convertcalendar('Chinese');
-$date.year.name(); # Snake
-
-A fair bit of initialisation of the NumberNames for day of the week and month
will need to
-be done.
-
$format will naturally need to allow for eras.
=over
@@ -123,60 +105,57 @@
=back
-=head3 Time
+=head2 Temporal::Time
-You probably want to use the DateTime object instead.
+You probably want to use the Temporal::Instant object instead.
-role Time {
+role Temporal::Time {
has $.hour;
has $.minute;
has $.second;
method toString($format?);
# This can't be right; how do we specify this
- multi method infix:{'<=>'}(Time $self, Time $other);
- multi method infix:{'<=>'}(Time $self, Duration $other);
+ multi method infix:{'<=>'}(Temporal::Time $self, Temporal::Time $other);
+ multi method infix:{'<=>'}(Temporal::Time $self, Temporal::Duration
$other);
}
When created, recognises "today" as a possibility.
-=head1 Classes
-
-=head2 Time and Date classes
-
-=head3 NumberName
-
- class NumberName {
+role Temporal::Timezone {
has $.number;
- method name($format?) {
- ...
- }
- }
-
-=head3 Timezone
-
-role Timezone {
- has $.number;
-
method name($format);
method is_dst();
}
-=head3 DateTime
+role Temporal::Subsecond {
+ has $.nanosecond;
+}
-class DateTime does Date does Time does Timezone {
+=head1 Classes
+
+=head2 Temporal::Timezone
+
+=head2 Temporal::Instant
+
+class Temporal::Instant
+ does Temporal::Date
+ does Temporal::Time
+ does Temporal::Timezone
+ does Temporal::Subsecond
+{
has $.locale;
has $.parser;
has $.formatter; # Only for output formats
- multi method DateTime infix:<+>(DateTime $self, Duration $other);
+ multi method Temporal::Instant infix:<+>(Temporal::Instant $self,
Duration $other);
- multi method infix:<->(DateTime $self, Duration $other);
- multi method infix:<->(DateTime $self, Duration $other);
+ multi method infix:<->(Temporal::Instant $self, Duration $other);
+ multi method infix:<->(Temporal::Instant $self, Duration $other);
- multi method infix:{'<=>'}(DateTime $self, DateTime $other);
- multi method infix:{'<=>'}(DateTime $self, Duration $other);
+ multi method infix:{'<=>'}(Temporal::Instant $self, Temporal::Instant
$other);
+ multi method infix:{'<=>'}(Temporal::Instant $self
Re: r25402 - in docs/Perl6/Spec: . S32-setting-library
pugs-comm...@feather.perl6.nl wrote: Author: wayland Date: 2009-02-19 04:46:06 +0100 (Thu, 19 Feb 2009) New Revision: 25402 Added: docs/Perl6/Spec/S32-setting-library/ docs/Perl6/Spec/S32-setting-library/Any.pod docs/Perl6/Spec/S32-setting-library/Containers.pod docs/Perl6/Spec/S32-setting-library/IO.pod docs/Perl6/Spec/S32-setting-library/Numeric.pod docs/Perl6/Spec/S32-setting-library/Scalar.pod docs/Perl6/Spec/S32-setting-library/String.pod docs/Perl6/Spec/S32-setting-library/Temporal.pod Modified: docs/Perl6/Spec/S16-io.pod docs/Perl6/Spec/S29-functions.pod Log: S16: Added a few attributes to trees S29: Moved a lot of stuff out to S32 S32: Created this from S29 -- will incorporate S16 stuff soon This, and r25403, is definitely off to a good start with these revisions. That split-reorganization was valuable and necessary, just since the contents are so large and covered a wide range of topics. I'm glad you agreed with my suggested broad namespace 'Temporal', and the other namespaces under setting-library are good too in general. Presumably the other enhancements we discussed like using the 'Instant' name will follow soon. Thank you. -- Darren Duncan
