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 o
Author: wayland
Date: 2009-02-18 07:29:03 +0100 (Wed, 18 Feb 2009)
New Revision: 25375
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
Fixed operator overloading calls.
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-i
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 a
Author: wayland
Date: 2009-02-18 07:14:51 +0100 (Wed, 18 Feb 2009)
New Revision: 25374
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
Bits and pieces, but mostly trying to clean up the list of unfiled functions.
Modified: docs/Perl6/Spec/S16-io.pod
===
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
tim
On 2009 Feb 16, at 22:44, Timothy S. Nelson wrote:
So you can have a stream handle which does IO::Writeable, but will
throw an error on any attempt to write? Anyway, you've answered my
question in the other e-mail.
Not sure what you're getting at, but the obvious example is a
writeable h
Hi all. I'd like to suggest a slight reorganisation within the specs.
The first thing I've observed is that, in defining the IO stuff, and
adding in the Tree and DateTime stuff, is that we're getting a lot of non-IO
stuff in there.
I'm aware that the numbering and ordering of the s
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.
htt
Author: wayland
Date: 2009-02-18 06:09:25 +0100 (Wed, 18 Feb 2009)
New Revision: 25373
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
S16: Started adding some DateTime stuff, but stopped pending some questions to
the mailing
list.
Modified: docs/Perl6/Spec/S16-io.pod
==
Something that may possibly be relevant to this discussion as an object lesson
...
In the near future, probably next week, I'm going to re-implement the guts of my
Set::Relation module (for Perl 5, on CPAN now), from an eagerly evaluated
sometimes mutable or immutable object, to a often-lazily
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
===
-
On Tue, 17 Feb 2009, TSa wrote:
> I fully agree that immutability is not a property of types in a signature.
> But a signature should have a purity lock :(Int $i is pure) that snapshots
> an object state
[...]
> Note that this purity lock doesn't lock the outer object. It is only
> affecting the i
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,
TSa wrote:
Daniel Ruoso wrote:
The problem is that you can't really know wether a value is immutable or
not, we presume a literal 1 to be immutable, but even if you
receive :(Int $i), it doesn't mean $i is immutable, because that
signature only checks if $i ~~ Int, which actually results in
$i.d
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/Pi
Daniel Ruoso wrote:
Maybe I'm thinking sideways again, but I haven't thought of "open" as
being a method of any IO object, because usually "open" is the thing
that gets you an IO Object.
I'd expect the plain "open" to be really a sub (maybe a "is export"
method in the generic IO role), that doe
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 strik
HaloO,
Daniel Ruoso wrote:
The problem is that you can't really know wether a value is immutable or
not, we presume a literal 1 to be immutable, but even if you
receive :(Int $i), it doesn't mean $i is immutable, because that
signature only checks if $i ~~ Int, which actually results in
$i.does(
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 thi
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) {...}
daniel
Em Seg, 2009-02-16 às 21:21 -0800, Darren Duncan escreveu:
> marking it as consisting of just immutable values, and in the
> routines case marking it as having no side effects
The problem is that you can't really know wether a value is immutable or
not, we presume a literal 1 to be immutable, but
I didn't realise this hadn't gone to the list. Enjoy, all :).
-- Forwarded message --
Date: Tue, 17 Feb 2009 14:34:07 +1100 (EST)
From: Timothy S. Nelson
To: Leon Timmermans
Subject: Re: r25328 - docs/Perl6/Spec
On Mon, 16 Feb 2009, Leon Timmermans wrote:
On Mon, Feb
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
Author: wayland
Date: 2009-02-17 12:26:51 +0100 (Tue, 17 Feb 2009)
New Revision: 25367
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
S16: Made some improvements based on
http://www.mail-archive.com/perl6-language@perl.org/msg28566.html
(Thanks to Mark Overmeer for the link)
Modified: docs/Perl6
Author: wayland
Date: 2009-02-17 11:06:57 +0100 (Tue, 17 Feb 2009)
New Revision: 25364
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
S16: Added cwd to FileSystem
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.po
Jon Lang wrote:
I'm not saying that it needs to decide whether or not you have a
halting problem; I'm saying that if there's any possibility that you
_might_ have one, you should stop looking. Let's take it as a given
that things such as exceptions, threads, and co-routines make the
automated es
* Timothy S. Nelson (wayl...@wayland.id.au) [090217 08:13]:
> Should the functionality of File::Spec and Cwd be integrated into
> the IO modules? I'm not advocating the interface, but the functionality
> might be useful.
We had a very long discussion about this subject on this list, last
Novemb
Should the functionality of File::Spec and Cwd be integrated into the
IO modules? I'm not advocating the interface, but the functionality might be
useful.
Thanks,
-
| Name: Tim Nelson | Because the C
28 matches
Mail list logo
