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