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
* 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
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
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
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
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
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
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
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
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
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(
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
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
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
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, 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,
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
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
===
-
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 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
==
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
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 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
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
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
===
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: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
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
28 matches
Mail list logo
