Larry Wall wrote:
Well, if as people remember them if they could tell me the name, and a link to somewhere in the thread on nntp.perl.org, I'll process those as well. Scanning through the ~20k p6l messages for new functions is a heavier scope than I'm willing to consider for a while.On Sun, Mar 13, 2005 at 01:15:52AM -0600, Rod Adams wrote:
: 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. :-)
: =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'll wait for you to figure out the Right Thing and document it in S16.
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);
Would something like
my &print<> := &FileHandle::print<>.assuming:fh($fh);
do the trick? (repeat for printf and a couple others)
Though we might just be able to resurrect the other select throughI definitely want the functionality of the second select() somewhere in Perl. But I'll always have an "use IO::Socket;" in those files, so maybe it goes there. Getting something friendlier than bitmaps of fd's would be nice. What interface is Parrot exporting here?
the magic of MMD. Bitmaps of file descriptors just aren't the wave
of the future though.
: =item A/S??: OS InteractionI like the idea of pre-loaded, non-imported (by default) packages. That would let people use an occasional C<OS::Unix::passwd::getpwuid()> without mucking up the language, and if they are doing some serious passwd hacking, they can C<use OS::Unix::passwd;> to import them.
: : 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.
If we can agree on package names for them, and which funcs go in which, I'll add them to S29, in separate sections. Or at least I'll document which packages have that property, and let the package be documented elsewhere.
: =item A/S17: ThreadsYes, I know that fork, wait, etc all relate to processes, not threads (except "lock", which is for threads). But the two are related. I've resolved the issue by renaming the section to "Threads and Multiprocessing". One could justifiably put several forms of "open()" in here. IMO, that nonsense should stop.
: : 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". :-)
After posting, I had changed it to:
=item abs
multi sub abs (num $x ) returns num multi sub abs (Num ?$x = $CALLER::_ ) returns Num multi method Num::abs ( ) returns Num
Absolute Value.
B<Question>: Do we need all the num vs Num variants for performance? If not, which one should we keep?
I'll try to remember to feed it to a spell checker periodically. :)
I've processed the math oriented functions (will post soon), and used $x and $y (didn't need $z) for general Numbers. Had planned on using $s, $t, ... for strings. I'm open to any other default scheme. If nothing's established when I need one for a certain type, I'll just come up with something. They won't be too outlandish.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
I realized that with the ability to call a function with all parameters via name, that I would have to include all the names of variables instead of just the shortcut for type only that I was attempting (which was a side effect of using perlfunc as a template, which only listed types).
-- Rod Adams
