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
               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

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.


Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/

Reply via email to