Re: Temporal and purity (was: Re: IO, Trees, and Time/Date)
Dates starting at midnight is fine, but I agree that a Date shouldn't automatically coerce into midnight on that date. If it's going to autocoerce at all, I'd recommend noon instead, but better to force the programmer to pick what they mean. On Fri, Feb 20, 2009 at 2:32 AM, David Green david.gr...@telus.net wrote: On 2009-Feb-19, at 4:39 pm, Martin Kealey wrote: 2. Date isa Instant works sensibly: anywhere that expects an Instant, you can give it a Date. (Assuming we all agree that dates start at midnight, but then we *are* talking specifically Gregorian dates.) I don't like dates just starting at midnight because I've run into too many awkward cases where $time $date doesn't do what you mean because it assumes 0:00:00 when you meant 23:59:59. I'd rather have dates becomes time-ranges. Or perhaps don't make them coercible and require an explicit conversion via $date.morning or $date.evening or something. (Maybe require $time ∩ $date or $time ⊂ $date?) -David -- Mark J. Reed markjr...@gmail.com
Temporal and purity (was: Re: IO, Trees, and Time/Date)
Just to clear up ahead of time, the consensus both here and on IRC
seemed to be that in the core, we put a basic Temporal::Instant object that
about powerful enough to deal with:
- localtime/gmtime functionality
- ctime, mtime, etc, in stat()
- nanoseconds or whatever needed for (I think) alarm() and things
There is bucketloads of other functionality that could be implemented,
and I've included a few of what I consider to be the most important (ie. make
it work with operators), but we hope to leave most other stuff to CPAN. Even
the naming of months, etc, can be left to CPAN. I've got a few hooks in there
to deal with things that CPAN will want, but hopefully that's all.
On Thu, 19 Feb 2009, Martin D Kealey wrote:
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.
I followed the bits about the computations, and I think I see what
you're saying about the constructor, but I don't know what you mean by
'immutable time values'. Could you expand on this a bit?
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 );
Actually, I admit I'd love to get rid of gmtime and localtime
altogether, while keeping the functionality. It seems to me that each is
really a constructor with a different default timezone. Likewise I'd like to
get rid of the time() function.
I snipped the comments about the complexity of calculations. I figure
that for most purposes, people don't want the complexity, and as long as CPAN
can supply something that implements the same role, I'm happy to leave it to
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: Temporal and purity (was: Re: IO, Trees, and Time/Date)
On Fri, 20 Feb 2009, Timothy S. Nelson wrote: On Thu, 19 Feb 2009, Martin D Kealey wrote: 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. I followed the bits about the computations, and I think I see what you're saying about the constructor, but I don't know what you mean by 'immutable time values'. Could you expand on this a bit? We want an Instant class whose objects have value semantics rather than container semantics. Because: 1. It makes them usable in pure code 2. Date isa Instant works sensibly: anywhere that expects an Instant, you can give it a Date. (Assuming we all agree that dates start at midnight, but then we *are* talking specifically Gregorian dates.) (If you have container objects, that can't work, and neither can the reverse, tempting though it is. So tempting in fact that it's part of the Java language definition. Uggh!) 3. Having separate writable attributes is offering someone a cannon with which to shoot their own foot off, as far as having buggy code goes. (Strictly, this doesn't preclude having a container object where you set the epoch-second, or set the year, month, day, hour, minute and second all at once, but even if they're not in the design to begin with, sometime someone naïve is going to add them. 4. Let's face it, they're pretty small objects. They're on a par with a Num, and should get similar treatment. -Martin
Re: Temporal and purity (was: Re: IO, Trees, and Time/Date)
On 2009-Feb-19, at 4:39 pm, Martin Kealey wrote: 2. Date isa Instant works sensibly: anywhere that expects an Instant, you can give it a Date. (Assuming we all agree that dates start at midnight, but then we *are* talking specifically Gregorian dates.) I don't like dates just starting at midnight because I've run into too many awkward cases where $time $date doesn't do what you mean because it assumes 0:00:00 when you meant 23:59:59. I'd rather have dates becomes time-ranges. Or perhaps don't make them coercible and require an explicit conversion via $date.morning or $date.evening or something. (Maybe require $time ∩ $date or $time ⊂ $date?) -David
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:
snipbe 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.
snip
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, html head and title 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
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
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
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: 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:
snip
$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.
snip
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: IO, Trees, and Time/Date
On Wed, Feb 18, 2009 at 6:36 AM, Richard Hainsworth rich...@rusrating.ru 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 markjr...@gmail.com
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 rich...@rusrating.ru 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: 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.
snip
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: 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) */
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-
IO, Trees, and Time/Date
Hi all. I know we usually run on forgiveness instead of permission, but I'm suggesting a big change (or extension, anyway), so I wanted to run the ideas by you all before I put the effort in. If I don't get feedback, I'll just make the changes. The first thing I wanted to suggest was that in S16, the OS-specific stuff be split out into separate roles. I suspect this is mostly non-controversial, so I'll do that unless someone complains. My second thought is that we need to specify tree objects (see http://www.mail-archive.com/perl6-language@perl.org/msg28579.html ). I'll put them in S16 unless someone complains. 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 My final question is, since people are now getting somewhat familiar with the file: URI scheme (ie. file:/home/wayland/Notes.txt or file:/C/Documents and Settings/wayland/Notes.txt or whatever), I'm wondering if this isn't how we should be specifying our files; it's prettier than File::Spec :), and unified. Anyway, HTH, - | 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
Timothy S. Nelson wrote: Hi all. I know we usually run on forgiveness instead of permission, but I'm suggesting a big change (or extension, anyway), so I wanted to run the ideas by you all before I put the effort in. If I don't get feedback, I'll just make the changes. The first thing I wanted to suggest was that in S16, the OS-specific stuff be split out into separate roles. I suspect this is mostly non-controversial, so I'll do that unless someone complains. My second thought is that we need to specify tree objects (see http://www.mail-archive.com/perl6-language@perl.org/msg28579.html ). I'll put them in S16 unless someone complains. 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 My final question is, since people are now getting somewhat familiar with the file: URI scheme (ie. file:/home/wayland/Notes.txt or file:/C/Documents and Settings/wayland/Notes.txt or whatever), I'm wondering if this isn't how we should be specifying our files; it's prettier than File::Spec :), and unified. Anyway, HTH, I like all the default suggestions. 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. It seems to me that unix blurs the difference between a file and a directory (at least readdir returns both file and directory names and the programer then needs a test to distinguish them), but that does not mean they are not conceptually different. 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. 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. Regards, Richard
Re: IO, Trees, and Time/Date
On Tue, 2009-02-17 at 22:38 +1100, Timothy S. Nelson wrote: 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 Conceptually, I agree. But there are places that Time::Piece assumes time is a sane thing, and it just isn't. Date::Time has a less DWIM interface, but is much more correct in the face of general human nuttiness on this topic (especially with regard to durations and timezones). I'd prefer to generally follow Date::Time, with DWIM features cherry picked from Time::Piece as long as they don't result in wrong behavior. (As an aside: It's the 21st century -- the default stringification of time objects should be easily parseable and sortable, not the insanity produced by Perl 5's 'scalar localtime'. ISO or SQL timestamp format please.) -'f
Re: IO, Trees, and Time/Date
On Tue, 17 Feb 2009, Richard Hainsworth wrote:
Timothy S. Nelson wrote:
Hi all. I know we usually run on forgiveness instead of permission,
but I'm suggesting a big change (or extension, anyway), so I wanted to run
the ideas by you all before I put the effort in. If I don't get feedback,
I'll just make the changes.
The first thing I wanted to suggest was that in S16, the OS-specific
stuff be split out into separate roles. I suspect this is mostly
non-controversial, so I'll do that unless someone complains.
My second thought is that we need to specify tree objects (see
http://www.mail-archive.com/perl6-language@perl.org/msg28579.html ). I'll
put them in S16 unless someone complains.
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
My final question is, since people are now getting somewhat familiar
with the file: URI scheme (ie. file:/home/wayland/Notes.txt or
file:/C/Documents and Settings/wayland/Notes.txt or whatever), I'm
wondering if this isn't how we should 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.
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.
It seems to me that unix blurs the difference between a file and a directory
(at least readdir returns both file and directory names and the programer
then needs a test to distinguish them), but that does not mean they are not
conceptually different.
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).
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()
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.
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.
I'd argue that we want three things here, if we go down this path:
IO::Dir.files()
IO::FileNode.lines()
IO::File.printf()
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;
I know @$dir is bad perl6, but I hope you'll take the idea, in that,
when we treat $dir as an array, we get a return of all children, whether files
or directories, and then use -f to distinguish between them. Btw, the
object creation line above could be done differently -- don't anyone get hung
up on that.
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.
:)
-
| 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 Tue, 17 Feb 2009, Geoffrey Broadwell wrote: On Tue, 2009-02-17 at 22:38 +1100, Timothy S. Nelson wrote: 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 Conceptually, I agree. But there are places that Time::Piece assumes time is a sane thing, and it just isn't. Date::Time has a less DWIM interface, but is much more correct in the face of general human nuttiness on this topic (especially with regard to durations and timezones). I'd prefer to generally follow Date::Time, with DWIM features cherry picked from Time::Piece as long as they don't result in wrong behavior. 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. 2. Documents in terms of operator overloading 3. Depends a lot more on CLDR formats 4. Doesn't have multiple functions that perform exactly the same thing 5. As a consequence of all of the above, has a lot fewer functions (while still providing all the same functionality). (As an aside: It's the 21st century -- the default stringification of time objects should be easily parseable and sortable, not the insanity produced by Perl 5's 'scalar localtime'. ISO or SQL timestamp format please.) Fine by me. - | 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
Timothy S. Nelson wrote: Conceptually, I agree. But there are places that Time::Piece assumes time is a sane thing, and it just isn't. Date::Time has a less DWIM interface, but is much more correct in the face of general human nuttiness on this topic (especially with regard to durations and timezones). I'd prefer to generally follow Date::Time, with DWIM features cherry picked from Time::Piece as long as they don't result in wrong behavior. 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. 2.Documents in terms of operator overloading 3.Depends a lot more on CLDR formats 4.Doesn't have multiple functions that perform exactly the same thing 5.As a consequence of all of the above, has a lot fewer functions (while still providing all the same functionality). Talking about dates and times, I have some suggestions. First of all, I don't think that most DateTime stuff belongs in IO. The class definitions to represent a date or time or duration etc value, as well as operators to convert date formats etc or add/subtract etc dates are strictly internal, same as number or string operations. Only the routines to fetch the current system time and the like belong in IO, or routines concerning file timestamps etc. Second of all, I think a more generic term than DateTime should be used to name an object that represents an instant in time; for example I suggest calling it Instant. The name Instant fits in a lot better in the company of other generic sounding temporal data types like Duration etc. Then, you can say that things like DateTime, Date, Time, etc are subtypes of Instant. See also http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Ext/Temporal.pod where I've specced out such matters, and that illustrates something I recommend for you. My Instant types very closely resemble both the Perl DateTime library as well as the SQL temporal types, which are actually very similar, though I've generalized it a bit. This spec explicitly does not support time zones (it has UTC or floating, that's it) and it doesn't include conversions with strings, but it has the foundation on which such could be built. And yours doesn't have to be the same of course. -- Darren Duncan
Re: IO, Trees, and Time/Date
On Tue, 17 Feb 2009, Darren Duncan wrote: Talking about dates and times, I have some suggestions. First of all, I don't think that most DateTime stuff belongs in IO. The class definitions to represent a date or time or duration etc value, as well as operators to convert date formats etc or add/subtract etc dates are strictly internal, same as number or string operations. Only the routines to fetch the current system time and the like belong in IO, or routines concerning file timestamps etc. I agree they don't belong in that part of the spec; I've just written another e-mail about that (Spec reorganisation). Second of all, I think a more generic term than DateTime should be used to name an object that represents an instant in time; for example I suggest calling it Instant. The name Instant fits in a lot better in the company of other generic sounding temporal data types like Duration etc. Then, you can say that things like DateTime, Date, Time, etc are subtypes of Instant. Love the name; I'll do the rename as soon as the Spec reorganisation is sorted out. It also means that we can use DateTime to refer to Instant+Duration+... :). See also http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Ext/Temporal.pod where I've specced out such matters, and that illustrates something I recommend for you. My Instant types very closely resemble both the Perl DateTime library as well as the SQL temporal types, which are actually very similar, though I've generalized it a bit. This spec explicitly does not support time zones (it has UTC or floating, that's it) and it doesn't include conversions with strings, but it has the foundation on which such could be built. And yours doesn't have to be the same of course. I'll look into it :). 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: IO, Trees, and Time/Date
Timothy S. Nelson wrote: On Tue, 17 Feb 2009, Darren Duncan wrote: Second of all, I think a more generic term than DateTime should be used to name an object that represents an instant in time; for example I suggest calling it Instant. The name Instant fits in a lot better in the company of other generic sounding temporal data types like Duration etc. Then, you can say that things like DateTime, Date, Time, etc are subtypes of Instant. Love the name; I'll do the rename as soon as the Spec reorganisation is sorted out. Great to hear. It took me a bit of effort back in September to come up with it. And by the way, potentially another good word would have been Moment except that this word is often used by physics people to mean either of several different things than an instant in time. Instant didn't seem to have that problem of there being possibly confused other uses. It also means that we can use DateTime to refer to Instant+Duration+... :). You could. Or why not use Temporal if you want a broader category or namespace? That's the most generic term I can think of that accurately applies and that it would be easy for people to understand at a moment's glance. (It is also a lot easier to think up in the first place than Instant but was too broad for the latter's use.) And using single word names for things where they fit is a lot more elegant I think, and is also in keeping with the Perl way of built-ins tending to all have single word names. Save Date and Time for more specific things rather than more general things. Also, calling something DateTime smells, like it was a fall-back because it was difficult to come up with a single word. It smells like having a numeric type and calling it WholeFraction rather than Number or Rational. Thank you. -- Darren Duncan
