The S29 Functions Project

[Rod Adams]

Barring objections, I'm going to attempt to compile a S29.

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.

When I've written up a given function from what I believe it will be,
I'll post the relevant section of pod to the list for comments/approval.

I will not be attempting to rewrite perlfunc. The target audience will
be someone familiar with Perl 5 and the other synopses. I will be
listing sub/method signatures, including variants found in the standard
type classes.

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.

The list of "pending" functions, by group, is:

=over 8

=item A/S14: Tied Variables

tie tied untie

=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

=item A/S??: OS Interaction

chroot exec getlogin /[get|set][pw|gr].*/ setpgrp setpriority system
times

=item A/S17: Threads

fork lock wait waitpid

=back

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.

=item multi sub atan2 (Num, Num) returns Num

Arctangent of Y/X (radians)

=item multi sub cos (?Num) returns Num

=item multi method Num::cos () returns Num

Cosine (radians). $_ if omited.

=item multi sub exp (?Num) returns Num

=item multi method Num::exp() returns Num

Exponent or inverse natural log. $_ if omited.

-- Rod Adams

[Larry Wall]

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

[Uri Guttman]

>>>>> "LW" == Larry Wall <la...@wall.org> writes:

LW> I can tell you that I want both selects to be dead, but again, I'll
LW> have to translate Perl 5 to something. But some of these things
LW> can probably be translated to things like

LW> Perl5DeprecatedEmulationDoNotUseEverEverAgain::select(MyHandle);

LW> Though we might just be able to resurrect the other select through
LW> the magic of MMD. Bitmaps of file descriptors just aren't the wave
LW> of the future though.

with parrot supporting real async i/o (file and network) and a core
event loop, we can allow those features to be exposed in perl6. this
means dropping 4 arg select is easy. in some rfc's of mine (i have to
look them up) i proposed some event stuff but as you state that hasn't
been addressed in any A's yet. this could be loaded from modules and be
written in parrot/perl6 so it doesn't be in the core lang but it still
would be useful to spec it out so that we have a good api that is easy
to use.

LW> Given the example of select above, I guess for things like the
LW> OS dependent calls, we also have the option of demoting them to a
LW> global module that you *can* import but can also get at through the
LW> package name. That is, the package is automatically there. Arguably,
LW> a lot of these should be in POSIX:: or some such. Maybe we want to
LW> hide abstractions like "POSIX" though in favor of sorting out the
LW> functionality some other way.

i am not sure if posix has an event api. but there is event.pm to look
at, as well as the libevent library (which wraps several different
kernel event api's). but they probably won't be compatible with parrot's
event core (which is designed by dan). anyhow this area needs to be
addressed from the api point of view and then it can be decided where it
resides, in a module (best bet IMO) or core language.

uri

--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

[Rod Adams]

Larry Wall wrote:

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

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.

>: =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 through
>the magic of MMD. Bitmaps of file descriptors just aren't the wave
>of the future though.
>
>

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

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

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

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

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

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

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

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

[Ashley Winters]

For documentary purposes, can we make that $radians?

multi sub cos (Num +$degrees) returns Num {
return cos :radians($degrees * PI / 180);
}

my Num $x = cos :degrees(270);

Ashley Winters

[Rod Adams]

Ashley Winters wrote:

>For documentary purposes, can we make that $radians?
>
>multi sub cos (Num +$degrees) returns Num {
> return cos :radians($degrees * PI / 180);
>}
>
>my Num $x = cos :degrees(270);
>

I have changed the trig functions it to have an optional "base"
argument. (I'm option to new names for this term.)

The problem I see with your proposal is that both versions have the same
MMD long name, which only looks at required parameters. We'd have to
have something like:

multi sub cos (Num ?$radians = $CALLER:_, Num +$degrees, Num
+$gradians) returns Num

And then internally dispatch on what is defined and undefined.

Personally I like

multi sub cos (Num ?$x = $CALLER::_, Num|Str +$base) returns Num

better. You can do:

our &cos<> := &cos<>.assuming:base('degrees');

to make cosine "degrees only" for your current package.

-- Rod Adams

[Mark A. Biggar]

Rod Adams wrote:

The Ada language uses a numeric parameter for Base with a default of
2*pi. So Base => 360.0 gives degrees, Base => 400.0 gives grads, Base
=> 1.0 gives bams, etc.

--
ma...@biggar.org
mark.a...@comcast.net

[Ashley Winters]

On Sun, 13 Mar 2005 23:42:41 -0600, Rod Adams <r...@rodadams.net> wrote:
> Ashley Winters wrote:
> >For documentary purposes, can we make that $radians?
> >
> >multi sub cos (Num +$degrees) returns Num {
> > return cos :radians($degrees * PI / 180);
> >}
> >
> >my Num $x = cos :degrees(270);
> >
> I have changed the trig functions it to have an optional "base"
> argument. (I'm option to new names for this term.)
>
> The problem I see with your proposal is that both versions have the same
> MMD long name, which only looks at required parameters. We'd have to
> have something like:
>
> multi sub cos (Num ?$radians = $CALLER:_, Num +$degrees, Num
> +$gradians) returns Num

This seems like a poor limitation in practice. I wasn't even proposing
having that degrees version be in the standard library -- I offered
that function as an example implementation to put in my own
degree-using programs..

Don't get me wrong, I like having degrees/gradians as an option in the
standard language, but how should I do what I proposed in other cases,
when the option isn't included in the standard implementation?

As for the duplicate long names, don't we have permissive
foot-shooting? We get "is default" as a tie-breaker in the end, no?

Hell, I seem to recall seeing example functions whose signatures vary
by a "where" or "when" or some such clause.

multi sub foo (Int $x where { $_ ~~ any(1..10) })
multi sub foo (Int $x where { $_ ~~ any(5..15) }) is default

Ashley

[Rod Adams]

Ashley Winters wrote:

>On Sun, 13 Mar 2005 23:42:41 -0600, Rod Adams <r...@rodadams.net> wrote:
>
>
>>Ashley Winters wrote:
>>
>>
>>>For documentary purposes, can we make that $radians?
>>>
>>>multi sub cos (Num +$degrees) returns Num {
>>> return cos :radians($degrees * PI / 180);
>>>}
>>>
>>>my Num $x = cos :degrees(270);
>>>
>>>
>>>
>>I have changed the trig functions it to have an optional "base"
>>argument. (I'm option to new names for this term.)
>>
>>The problem I see with your proposal is that both versions have the same
>>MMD long name, which only looks at required parameters. We'd have to
>>have something like:
>>
>> multi sub cos (Num ?$radians = $CALLER:_, Num +$degrees, Num
>>+$gradians) returns Num
>>
>>

>As for the duplicate long names, don't we have permissive

>foot-shooting? We get "is default" as a tie-breaker in the end, no?
>
>

In this case the foot shooting would be enabled by locally redefining
&cos<>. The problem with how you did it is that you were then calling
your new version inside itself. I believe the following would have worked:

multi sub cos (Num +$degrees) returns Num {

&*cos.($degrees * PI /180)
}

Since you're now calling the global version of cos.

Side Question: Should I putting *'s throughout S29's signatures, or
assume they are assumed?

>Hell, I seem to recall seeing example functions whose signatures vary
>by a "where" or "when" or some such clause.
>
>multi sub foo (Int $x where { $_ ~~ any(1..10) })
>multi sub foo (Int $x where { $_ ~~ any(5..15) }) is default
>
>

The trick here is that the where clause actually created a subtype of
Int, so the long names are something like

&foo<Int(where {$_ ~~ any(1..10)})>
&foo<Int(where {$_ ~~ any(5..15)})>

exactly how a where clause mutates the name of the type has not been
defined yet. hmm. Actually I think it's been defined as being an
anonymous subclass, so they might look like:

&foo<ANON-0x03F3>
&foo<ANON-0x042A>

Regardless, they are different types, and MMD can handle it.

It's been defined that Perl 6.0.0 does not dispatch on named parameters,
for better or for worse. If you don't like it, talk to Larry.

-- Rod Adams.

[Rod Adams]

Larry Wall wrote:

Let me see if I'm following this correctly.

What you're saying is that when you do:

my Foo $bar;
$bar.baz(...);

Perl performs the following searches for baz():

1) Foo and it's MMD table
2) Foo's isas and roles
3) Foo's AUTOMETH/AUTOLOAD
4) Foo's isas' and roles' AUTOMETH/AUTOLOAD
5) look in current scope for a &baz<Foo, ...>
6) AUTOSUB/AUTOLOAD &baz<Foo, ...>

In case 5, you'd then be creating a temporary (sub lexical?) method
that's a curried form of &baz<Foo, ...>, and then call it.

While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it. And can't it be implemented as a straightforward:

multi sub cos (Num ?$x = $CALLER::_, Num|Str +$base) returns Num

&Num::cos<> := &*cos<>.assuming:x($self)

hmm. Not sure about that currying there, since I'm trying to assume the
invocant.

The other problem with case 5 is that the long name would be &cos<>, not
&cos<Num>, since the first parameter is optional. So you'd have to
expand the search beyond just the long name, which can get expensive.

hmm. I'm not sure I'm seeing all the pieces here.

-- Rod Adams.

[Larry Wall]

On Mon, Mar 14, 2005 at 01:07:45AM -0600, Rod Adams wrote:
: It's been defined that Perl 6.0.0 does not dispatch on named parameters,

: for better or for worse. If you don't like it, talk to Larry.

That's a little bit of an overstatement. I've only said 6.0.0 doesn't
*have* to support MMD on named parameters. I haven't said it mustn't.
If the first implementation of Perl 6 figures out a decent way to
handle it efficiently, I'm all for it, provided it doesn't unduly
delay 6.0.0. At the time we made the decision, it wasn't clear to any
of us in the room how to do it efficiently, but it might be obvious
to someone else. Or maybe it's even okay to take a speed hit, as
long as we don't punish the innocent with the guilty.

And the long and the short of it is that it really depends on whether
someone is willing to work on implementing it. We hope to get there
someday, but it's not top priority for 6.0.0 unless someone decides to
make it top priority. There are a number of things we might negotiate
away to make it easier to get 6.0.0 out the door quicker, and this
is only one of them. My only stipulation is that we trim things
in such a way as to not make them impossible later. Which means,
in the case of named MMD, that it is required that you use a colon
to separate positional arguments from named arguments until named
MMD is implemented, because we don't want the meaning of signatures
to suddenly change. After named MMD is implemented we can remove
the colon.

There are really two different problems here--it's also an issue that
you can use named notation on position args. and I don't have as good
an idea for how to future proof against that changing its meaning,
other than telling people not to do it yet. *If* all the long names
for a particular short name use the same parameter naming scheme,
then we could probably do some kind of global optimization to know
that a particular named parameter always maps to a particular position.
But that's a big if.

It's certainly possible that the best way to future proof it is to
simply do it right in the first place, even if it's slow to begin with.
People can always write the positional form for speed when they need it.

Larry

[Thomas Sandlaß]

Rod Adams wrote:
> And then internally dispatch on what is defined and undefined.

Why all that burden if Perl 6 is getting a strong type system,
that can do the sub selection and compile in dynamic dispatch if
needed?

I imagine:

multi sub cos( Num +$angle ) returns Num where { -1.0 <= $_ <= 1.0 }

class Radians is Num
{

}
class Degrees is Num
{
postfix:<°> ( Num $x ) { return $x * PI / 180 }

multi sub cos( Degrees +$angle ) returns Num where { -1.0 <= $_ <= 1.0 }
{
return cos( $angle * PI / 180 );
}
}

Note that cos(30°) calls &cos<Num> while &cos<Degrees> is used for
cases like:

Degrees $angle = 30.0;

if cos $angle > 2.0 { print "HaloO typechecker!" }

And I still wonder if the ones without '°' on their keyboard could
directly call 'cos<Degrees> $angle'.

Regards,
--
TSa (Thomas Sandlaß)

[Juerd]

Patrick R. Michaud skribis 2005-03-14 8:10 (-0600):
> I ran into this problem while creating a mini-list of S29 functions
> (which Rod's work supercedes, I suspect, and I'm very glad he's taking
> this on). What are some guidelines we could use in deciding
> which functions are automatically in ::* ? Or is this just a case
> where we need to use past experience and best guesses as our guide?

As much as I dislike it for CGI.pm, because it's slow and bloated, its
idea of :standard is very useful.

So my vote goes to putting almost nothing in ::, but having a simple
pragma or module to import a certain group of "standard" functions.
Without this pragma, methods should still work, IMO.

use Standard;

use standard;

use v6 :standard;

It would just do things like &::open ::= &IO::open, where the target is
the calling namespace only.

-e should imply this.

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

[Patrick R. Michaud]

On Sun, Mar 13, 2005 at 06:03:20PM -0800, Larry Wall wrote:
> : 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.

I ran into this problem while creating a mini-list of S29 functions

(which Rod's work supercedes, I suspect, and I'm very glad he's taking
this on). What are some guidelines we could use in deciding
which functions are automatically in ::* ? Or is this just a case
where we need to use past experience and best guesses as our guide?

Pm

[Luke Palmer]

Thomas Sandlaß writes:
> Rod Adams wrote:
> >And then internally dispatch on what is defined and undefined.
>
> Why all that burden if Perl 6 is getting a strong type system,
> that can do the sub selection and compile in dynamic dispatch if
> needed?
>
> I imagine:
>
> multi sub cos( Num +$angle ) returns Num where { -1.0 <= $_ <= 1.0 }

Lose the + on $angle. + indicates a named-only parameter. You want
this to be positional.

> class Radians is Num
> {
>
> }
> class Degrees is Num
> {
> postfix:<°> ( Num $x ) { return $x * PI / 180 }

You probably shouldn't define this inside the Desgrees class. And you
should probably tell me whether it's a sub, a method, a macro, a
submethod, or a small puppy.

> multi sub cos( Degrees +$angle ) returns Num where { -1.0 <= $_ <= 1.0 }
> {
> return cos( $angle * PI / 180 );
> }

I think that's defining Degrees::cos to be a multi, to be differentiated
from other Degrees::cos'es. But that may be right.

I'd just make it a method.

method cos($angle:) returns Num where { -1 <= $_ < 1 } {
cos($angle * PI / 180);
}

> }
>
> Note that cos(30°) calls &cos<Num> while &cos<Degrees> is used for
> cases like:
>
> Degrees $angle = 30.0;
>
> if cos $angle > 2.0 { print "HaloO typechecker!" }

That's certainly an interesting way to do it.

> And I still wonder if the ones without '°' on their keyboard could
> directly call 'cos<Degrees> $angle'.

&cos<Degrees>($angle) or Degrees::cos($angle), depending on whether you
defined it your way or my way. Uh oh, I thought we were going to make
single-invocant multis and methods the same everywhere...

Luke

[Larry Wall]

On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote:
: I ran into this problem while creating a mini-list of S29 functions

: (which Rod's work supercedes, I suspect, and I'm very glad he's taking
: this on). What are some guidelines we could use in deciding
: which functions are automatically in ::* ? Or is this just a case
: where we need to use past experience and best guesses as our guide?

You have the irritating habit of asking good questions I don't have
an easy answer for. Please don't stop.

Thinking about it a bit, it really comes down to an issue of
pragmatics in the linguistic sense. The question is, if you glance
at any particular function foo(), does it immediately pop into your
head that this is probably a cultural meme, or does it sort of lazily
evaluate to the possibility of a cultural meme. So by this main
criterion, abs() is almost certainly the absolute value meme (unless
you're at the gym), while dump() doesn't really mean much to people
because it's too heavily overloaded.

There are going to be several secondary criteria that modify the main
criterion:

* Sometimes we want to force a particular meme into the foreground.
By the main criterion lock() isn't specific enough to be a keyword,
but we can choose to force it to mean one thing. The fact that all
such functions are the equivalent of Perl 5's 3rd-class keywords
makes this easier, since the user can still override the meaning of
lock() if they want to. (Or abs() for that matter.)

* Another confounding factor is that memes tend to come in bundles,
and you'd kind of like to keep the bundles together. So my earlier
question really amounted to whether POSIX was really a valid
bundle of memes. (Probably not.) On the other hand, the trig
functions might well be a valid bundle, and we might want to
keep them all together either in * or Trig.

* On the other hand, maybe some meme bundles deserve to be split up
into two bundles by the main criterion, with one bundle going into *
and the other into Trig (or whatever). Arguably sin and cos are
instantly recognizable, but the lesser known trig functions are
more debatable. But these are all fuzzy boundaries, and people
will see the boundaries in different places.

* We're really talking about a three-way distinction here. In the
middle we have the functions that are imported by default when
you say "use Trig" rather than "use Trig :all". There are some
folks who would argue well-formed modules should never export any
names by default, so that "use Trig" *only* makes sure that the
Trig module is available, and you'd have to say "use Trig :default"
or some such to get the default set. But that's just giving
the middle memes a different collective name.

* We do in fact have mechanisms for overriding any core feature,
and we don't want Perl to turn into a language where you have
to import a bunch of essential stuff at the top, it basically
argues that in case of doubt, we should throw it into the core.
We'll also have MMD to sort things out, so as long as things are
well-typed, we shouldn't fall into a PHP function-name hell.

* Backward compatibility with Perl 5 decisions certainly influences
what Perl 5 programmers will expect, but not necessarily newcomers
to Perl. We'll have to decide how to balance those where Perl 5
got it "a little wrong".

The upshot of all this is that, as you suspected, this is something
we'll just have to work out as a community. What we can do right
now is tell people not to be surprised when we move things around,
and that we'll feel free to move things around until 6.0.0 is about to
go golden. But maybe we could try to set some slushiness milestones
on the road to hell freezing over...

Larry

[Thomas Sandlaß]

Luke Palmer wrote:
> &cos<Degrees>($angle) or Degrees::cos($angle), depending on whether you
> defined it your way or my way. Uh oh, I thought we were going to make
> single-invocant multis and methods the same everywhere...

Sorry for messing up the syntax in my example code. What I wanted to achieve
is to get a multi cos that has the same namespace as the rest of the "standard"
functions.

BTW, I'm unsure how packages, modules and classes roles interact with
the type system and MMD. In particualr what can be put into the type slot
of declarations/definitions:

my SomeThing $x;

Can SomeThing be a package? Ans if yes, what does it mean?
--
TSa (Thomas Sandlaß)

[Larry Wall]

On Mon, Mar 14, 2005 at 06:00:11PM +0100, Thomas Sandlaß wrote:
: BTW, I'm unsure how packages, modules and classes roles interact with

: the type system and MMD. In particualr what can be put into the type slot
: of declarations/definitions:
:
: my SomeThing $x;
:
: Can SomeThing be a package? Ans if yes, what does it mean?

Maybe it means that $x contains a Perl 5 style object, if not an
actual Perl 5 object.

Larry

[Rod Adams]

Larry Wall wrote:

>On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote:
>: I ran into this problem while creating a mini-list of S29 functions
>: (which Rod's work supercedes, I suspect, and I'm very glad he's taking
>: this on). What are some guidelines we could use in deciding
>: which functions are automatically in ::* ? Or is this just a case
>: where we need to use past experience and best guesses as our guide?
>

>[snip]

>
>The upshot of all this is that, as you suspected, this is something
>we'll just have to work out as a community. What we can do right
>now is tell people not to be surprised when we move things around,
>and that we'll feel free to move things around until 6.0.0 is about to
>go golden. But maybe we could try to set some slushiness milestones
>on the road to hell freezing over...
>

What I'm thinking of doing is creating a soft rule of:
You can't declare a function into ::*. You have to create it
elsewhere, and bind it in.

Therefore, as I go through S29, I'll assign all functions to some
module. I'll be using the P5/CPAN hierarchy as a strong guideline.

We can then discuss what gets bound into ::*, and when, at some later
point in time.

-- Rod Adams

[Larry Wall]

On Mon, Mar 14, 2005 at 12:16:13PM -0600, Rod Adams wrote:
: Therefore, as I go through S29, I'll assign all functions to some

: module. I'll be using the P5/CPAN hierarchy as a strong guideline.
:
: We can then discuss what gets bound into ::*, and when, at some later
: point in time.

That's an excellent idea. We can encourage people to write the qualified
name if they want to be future-proof past the 6.0.0 boundary.

Larry

[Rod Adams]

Leopold Toetsch wrote:

>Rod Adams <r...@rodadams.net> wrote:
>
>
>>While that's a nice feature to have in general, I feel better about
>>going ahead and predefining that the builtins are already members of
>>Num, Str, Array, Hash for the shear performance and documentation values
>>of it.
>>
>>
>

>That's exactly the plan, when it comes to Parrot. I'd like to have a lot
>of function-like opcodes factored out into classes/*.pmc as methods.
>
>Given:
>
> pmclass P6Num extends Float { # the P6Num isa("Float")
> ...
> }
>
> pmclass Float {
>
> METHOD cos() { ... } # return cosine of Float SELF
>
>the method call in PIR can be written as:
>
> d = x."cos"() # normal method call
> d = Float."cos"(x) # class method, argument shifted down
> d = P6Num."cos"(x) # same
> d = cos x # PIR opcode syntax [1]
> cos d, x # PASM opcode syntax [1]
>
>There'll be a table of such builtins with name, namespace, signature, so
>that the current opcodes can be transparently replaced by methods.
>
>
This looks like it's taking

multi method Num::cos (Num|Str +$base) returns Num

and generating

multi sub cos (Num $x, Num|Str +$base) returns Num

Which I believe is the opposite direction of what Larry was doing, and
doesn't seem to address the $_ issue.

Part of me wants get rid of all the C< ?$x = $CALLER::_ >'s and tell
people if they want to use $_, they need to say C< .cos >. Then the
other part of me turns around and beats up the part that thought that.

The other issue in my head is

multi sub split (Rule $r, Str $s, Num +$limit) returns List of Str

I would want the following to be implied from it:

multi method Rule::split (Str $s, Num +$limit) returns List of Str
multi method Str::split (Rule $r, Num +$limit) returns List of Str

So what I'm thinking of for a solution is to have a

my Foo $bar;
$bar.baz;

call that gets past all the Foo AUTOMETHs is to then scan all the subs
in scope named baz, find the one with a required parameter of type most
compatible to Foo, ties being broken by appearing earlier on the
parameter list, and use that parameter as the invocant.

-- Rod Adams

[Rod Adams]

Leopold Toetsch wrote:

>No. The above "lowlevel" C<cos> isn't aware of C<base> nor of C<$_> and
>nothing is autogenerated in Parrot. The C<cos> is something like:
>
> class __parrot_core::Float {
> multi sub cos(Float x) returns Float ...
> }
>
>This is presumably inherited by C<class P6Num> (the Parrot PMC) and
>bound to:
>
> multi sub *cos(Num $x) returns Num
>
>at the Perl6 level.
>
>
That's all fine for the Parrot side of things, AFAICT.

But it doesn't answer my question about how Perl is going to
autogenerate methods, as alluded to in A/S12, and Larry's previous post.

For now, I'm assuming that I can define just the base multi sub, without
all the associated multi methods

-- Rod Adams

[Nicholas Clark]

On Mon, Mar 14, 2005 at 08:59:32AM -0800, Larry Wall wrote:
> On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote:
> : I ran into this problem while creating a mini-list of S29 functions
> : (which Rod's work supercedes, I suspect, and I'm very glad he's taking
> : this on). What are some guidelines we could use in deciding
> : which functions are automatically in ::* ? Or is this just a case
> : where we need to use past experience and best guesses as our guide?

> * Another confounding factor is that memes tend to come in bundles,

> and you'd kind of like to keep the bundles together. So my earlier
> question really amounted to whether POSIX was really a valid
> bundle of memes. (Probably not.) On the other hand, the trig
> functions might well be a valid bundle, and we might want to
> keep them all together either in * or Trig.

To me it seems that a there are some groups of core builtins in Perl 5
that group conceptually quite well, and it's sensible to remove en mass,
which are the builtins that aren't really useful in Perl 5 without loading
an extension module. So all the socket related builtins aren't much use
without the constants exported by Socket; and the System V IPC builtins
aren't much use without the IPC::SysV, so they could quite easily be
exported by that instead.

But then it gets less obvious what other groups from the top of perlfunc.pod
might manage a discrete exit from ::* without anyone noticing. So, no, I
don't have an answer :-)

Nicholas Clark

[Rod Adams]

I've put the following note at the top of S29.pod (in an update I haven't
posted yet).

In Perl 6, all builtin functions belong to a named package. Not all
functions are guaranteed to be imported into the global package
C<::*>. In addition, the list of functions imported into C<::*> will be
subject to change with each release of Perl. Authors wishing to
"Future Proof" their code should either specifically import the
functions they will be using, or always refer to the functions by their
full name.

-- Rod Adams

[Larry Wall]

On Tue, Mar 15, 2005 at 02:25:01PM -0600, Rod Adams wrote:
: In Perl 6, all builtin functions belong to a named package. Not all

: functions are guaranteed to be imported into the global package
: C<::*>. In addition, the list of functions imported into C<::*> will be
: subject to change with each release of Perl. Authors wishing to
: "Future Proof" their code should either specifically import the
: functions they will be using, or always refer to the functions by their
: full name.

Hmm, what I said was supposed to be policy for just the development
release of 6.0.0. However, it's not that far off from the general
case if you add something along the lines of:

After 6.0.0 comes out, global aliases will not be removed lightly,
and will never be removed at all without having gone through a
deprecation cycle of at least a year. In any event, you can specify
that you want the interface for a particular version of Perl, and
that can be emulated by later versions of Perl to the extent that
security updates allow.

Interestingly, that last sentence means that different modules can
have different views of * space. But really, that just falls out
of ordinary module versioning, if you can warp your brain around to
thinking of * as an ordinary versioned module. The long name of *
just happens to include the Perl version number, and could presumably
even include different "authors" if we ever fork Perl.

Larry

[Rod Adams]

Larry Wall wrote:

"Add something along the lines of" was interpreted as "clip and paste into S29.pod".

I wasn't meaning to imply that bindings would be changed willy-nilly in production, but I can see how that could be inferred from what I wrote. My main intention was that it *could* change over time.

These whole paragraphs can be reworded later, possibly at the same time we sit down and figure out the policy of what gets imported into *:: when.

-- Rod Adams