On Sun, Mar 13, 2005 at 01:15:52AM -0600, Rod Adams wrote:
: Barring objections, I'm going to attempt to compile a S29.
That's great. It's one of the many things I haven't been getting
around to doing...
: Plan of attack:
:
: I'm using a recent copy of Perl 5's perlfunc as a very rough template.
: At some point, I'll drudge through the A's and S's to look for functions
: new to Perl 6. I'll try not to make up too many new ones on my own, but
: I'll mark them as such.
A lot of new ones have been proposed on mailing lists that haven't made
it into A's and S's. Not all of the have been vetoed. :-)
: One thing I've already done is make a list of Perl 5 functions I cannot
: address until some future Apocalypse/Synopsis is generated on the topic.
: By far the bulk of this list falls on S16. Partly because IPC is a mess,
: and partly because I lumped all I/O in there.
At some point we're going to have to make a decision how many of these
automatically show up in ::* and how many have to be imported, and whether
there's some subset of the latter that can be auto-imported on demand,
and whether that's a good idea at all. It feels like a sop, and I'm not
sure how many sops we can afford in Perl 6 before things get soggy.
: The list of "pending" functions, by group, is:
:
: =over 8
:
: =item A/S14: Tied Variables
:
: tie tied untie
I'd love to do away with those entirely in favor of declaration traits,
but realistically I've got to figure out how to tranlate Perl 5 ties.
So at least we can hopefully restrict tying to variables that have
been declared tyable. Maybe even require "use tie" at the top to
allow further pessimization of the compiler.
: =item A/S16: IPC / IO / Signals
:
: -X accept alarm bind binmode chown close closedir connect eof fcntl
: fileno flock getc getpeername
: /[get|set][host|net|proto|serv|sock].*/ glob ioctl kill link listen
: lstat mkdir /msg.*/ open opendir pipe print printf read readdir readline
: readlink readpipe recv rename rewinddir rmdir seek seekdir select(both)
: /sem.*/ send setsockopt /shm.*/ shutdown socket socketpair stat symlink
: syscall sysopen sysread sysseek syswrite tell telldir truncate umask
: unlink utime
This will take a lot of negotiation, unless we stick with the PHPish
approach (and admittedly Perl5ish approach) of dumping them all into
the global namespace. At least they'd all be "3rd-class keywords"
by the Perl 5 definition, so that any user-defined sub would override
them.
I can tell you that I want both selects to be dead, but again, I'll
have to translate Perl 5 to something. But some of these things
can probably be translated to things like
Perl5DeprecatedEmulationDoNotUseEverEverAgain::select(MyHandle);
Though we might just be able to resurrect the other select through
the magic of MMD. Bitmaps of file descriptors just aren't the wave
of the future though.
Given the example of select above, I guess for things like the
OS dependent calls, we also have the option of demoting them to a
global module that you *can* import but can also get at through the
package name. That is, the package is automatically there. Arguably,
a lot of these should be in POSIX:: or some such. Maybe we want to
hide abstractions like "POSIX" though in favor of sorting out the
functionality some other way.
: =item A/S??: OS Interaction
:
: chroot exec getlogin /[get|set][pw|gr].*/ setpgrp setpriority system
: times
Again we have to decide how generic we want to be. Many of these things
are overt Unixisms, some of which are emulated elsewhere.
: =item A/S17: Threads
:
: fork lock wait waitpid
>From the Unix point of view I'd say those are processes rather than threads.
As for threads proper, I'm mostly just waiting for the Parrot folks
to provide an interface, and then we'll see how fancy we want to get
on top of that. I'm betting on a fairly thin interface.
: And now for a few simple functions to get things started:
:
:
: =item multi sub abs (?Num) returns Num
:
: =item multi method Num::abs () returns Num
:
: Absolute Value. $_ if omited.
Now we can just specify the default like this:
multi sub abs (?Num = $CALLER::_) returns Num
rather than risking the repeated misspelling of "omitted". :-)
: =item multi sub cos (?Num) returns Num
:
: =item multi method Num::cos () returns Num
It would be nice if we could just say the first implies the second.
I guess what that effectively means is that even if you take the
default, it's only the value that's optional, not the type. And,
in fact, you'd have to put the ? on the variable, not on the type,
so you might write those
=item multi sub cos (Num ?$n = $CALLER::_) returns Num
instead. Shall we settle on $x, $y, $z for standard Num args? In which
case that becomes
=item multi sub cos (Num ?$x = $CALLER::_) returns Num
Should integers args be $i, $j, $k? Hmm, shades of Fortran...
Anyway, thanks for giving this a start!
Larry
