New S29 draft up

2 views
Skip to first unread message

Rod Adams

unread,
Mar 16, 2005, 3:18:13 AM3/16/05
to Perl6 Language List

I just posted a fresh copy of S29 to:

http://www.rodadams.net/Perl/S29.pod
http://www.rodadams.net/Perl/S29.html

New:

All defined functions have been restructured into packages.

Perl6::Arrays, Perl6::Lists, and Perl6::Hashes are (mostly) written.

Some Math::Basic and Math::Trig functions added.

:'s have been added into signatures where they belong.

various other clean ups.


Comments welcome.

-- Rod Adams


Joe Gottman

unread,
Mar 16, 2005, 8:32:56 PM3/16/05
to Perl6 Language List

Isn't there also supposed to be an Arrays::kv? Also, I'm pretty sure
Larry said the Lists::reduce should go in the core.

Let me try to define them.

multi sub kv (Array @array : *@indices) returns List
Returns the indexes and associated values stored in @array, lazily and in
order by index. Optionally, only those of the slice defined by @indices.

multi sub reduce (Code $expression : *@values) returns List
{
my $res;
for @values -> $cur {
FIRST {$res = $cur; next;}
$res = &$expression($res, $cur);
}
$res;
}


Joe Gottman

Luke Palmer

unread,
Mar 16, 2005, 11:01:21 PM3/16/05
to Joe Gottman, Perl6 Language List
Joe Gottman writes:
> multi sub kv (Array @array : *@indices) returns List
> Returns the indexes and associated values stored in @array, lazily and in
> order by index. Optionally, only those of the slice defined by @indices.

This one is real easy:

multi sub kv (@array) returns List {
zip(1...; @array);
}

Array @array means an array of arrays. The *@indicies parameter seems
superflous, since you could just do:

for @array[1..10].kv -> $k, $v {...}

Luke

Rod Adams

unread,
Mar 17, 2005, 12:16:40 AM3/17/05
to Perl6 Language List
Luke Palmer wrote:

>Joe Gottman writes:
>
>
>>multi sub kv (Array @array : *@indices) returns List
>>Returns the indexes and associated values stored in @array, lazily and in
>>order by index. Optionally, only those of the slice defined by @indices.
>>
>>
>
>This one is real easy:
>
> multi sub kv (@array) returns List {
> zip(1...; @array);
> }
>
>

Doesn't C<zip> go until the longest input is exhausted, returning undef
at the end of the shorter ones?

multi sub kv (@array) returns List {

zip(0..@array.end ; @array);
}

Should work, though.


>Array @array means an array of arrays.
>

Grr. Another thing I knew better on and was getting wrong. If nothing
else, I'm getting used to thinking Perl 6 more and more by writing this
thing.

> The *@indicies parameter seems
>superflous, since you could just do:
>
> for @array[1..10].kv -> $k, $v {...}
>
>

Yea, but I saw Larry mention somewhere about supplying an optional list
of values to kv, etc. Forget exactly where, but I know I saw it. At
least, that was a reference to the Hash kv, where it makes sense, when
it's not painfully obvious that the keys mentioned already exist.

My thinking is that the kv/values/etc method of supplying a slice omits
elements that don't exist from the output, while the subscript slices
would generate undef. Also, I've taken a step and made it where it's now:

multi sub keys (@array : Any|Junction *@indextests) returns Int|List
multi sub kv (@array : Any|Junction *@indextests) returns Int|List
multi sub pairs (@array : Any|Junction *@indextests) returns Int|(List
of Pair)
multi sub values (@array : Any|Junction *@indextests) returns Int|List

Which "slices" based on C<$index ~~ any(@indextests)>, which seems a bit
more flexible.

Thanks to Joe for pointing out the missing functions. They've been added
locally and will be posted shortly. (Any others?)

-- Rod Adams


Juerd

unread,
Mar 17, 2005, 5:02:47 AM3/17/05
to Rod Adams, Perl6 Language List
Rod Adams skribis 2005-03-16 23:16 (-0600):

> Doesn't C<zip> go until the longest input is exhausted, returning undef
> at the end of the shorter ones?

No, as that'd break the most common idiom it introduced: use of an array
with 1..Inf, as in the example you're replying to, but also

for @foos ¥ 1... -> $foo, $i { ... }


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

Larry Wall

unread,
Mar 17, 2005, 12:05:52 PM3/17/05
to Perl6 Language List
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-16 23:16 (-0600):

: > Doesn't C<zip> go until the longest input is exhausted, returning undef
: > at the end of the shorter ones?

That's what has been specified.

: No, as that'd break the most common idiom it introduced: use of an array


: with 1..Inf, as in the example you're replying to, but also
:

: for @foos е 1... -> $foo, $i { ... }

Maybe we need a short-circuit zip:

for @foos ее 1... -> $foo, $i { ... }

Larry

Rod Adams

unread,
Mar 17, 2005, 1:41:51 PM3/17/05
to Perl6 Language List
Larry Wall wrote:

>On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
>
>: No, as that'd break the most common idiom it introduced: use of an array
>: with 1..Inf, as in the example you're replying to, but also
>:

>: for @foos „ 1... -> $foo, $i { ... }


>
>Maybe we need a short-circuit zip:
>

> for @foos „„ 1... -> $foo, $i { ... }
>
>

Or maybe that idiom should be written as:

for @foos.kv -> $i, $foo { ... }

But that gets a bit shaky beyond the shortest case. For instance,
there's no easy way to simulate:

for 1... „ @foos „ @bars {...}

So I'll add a C<Bit +$shortest> to C<zip>, and leave it up to you to
determine what the operator form of it should be, if any.

for zip :shortest 1...; @foos; @bars {...}

-- Rod Adams

Juerd

unread,
Mar 17, 2005, 1:49:40 PM3/17/05
to Perl6 Language List
Larry Wall skribis 2005-03-17 9:05 (-0800):

> That's what has been specified.
> Maybe we need a short-circuit zip:
> for @foos ¥¥ 1... -> $foo, $i { ... }

Because ¥ is shorter than ¥¥, and because the 1... thing is probably
going to be used much, I think it should be the one that returns the
shorter list.

my @foo = 1..3;
my @bar = 1..5;

@foo ¥ @bar # =>> 1 1 2 2 3 3
@foo ¥¥ @bar # =>> 1 1 2 2 3 3 undef 4 undef 5

Aaron Sherman

unread,
Mar 17, 2005, 6:11:09 PM3/17/05
to Rod Adams, Perl6 Language List
On Wed, 2005-03-16 at 03:18, Rod Adams wrote:
> I just posted a fresh copy of S29 to:
>
> http://www.rodadams.net/Perl/S29.pod
> http://www.rodadams.net/Perl/S29.html

>From there:

=head2 Obsolete

=item chop

Chop removes the last character from a string. Is that no longer useful,
or has chomp simply replaced its most common usage?

chomp($x)

vs

substr($x,-1) = '';

Hrm... well, I guess it's not SO bad....

=item dbmopen, dbmclose

YAY! ;)

=item dump

With Parrot?

Yes, but it won't be the same, and it should probably come from a
module. I'm sure that's going to be required by several folks from
several different areas (e.g. for checkpointing and all of the uses that
come from that like process migration). It will also be 99% Parrot's
job.

=item srand

C<rand(:seed($x))>

Ah, no. C<rand(:seed($x))> will invoke rand, will it not? That's not
what srand does. srand puts you in a known state, and leaves you there.
Without srand, even if you're using the same PRNG, you can't plug in
someone else's seed, and then call the function that will use it, unless
you can rewind/unshift the PRNG.

That said, I'd very much like Perl 6 to provide (either through Parrot
or on its own) a default strong, non-blocking random number generator
out of the box (though ALSO a rand that's just a PRNG which does not
exhaust the system's entropy pool). It's very frustrating to not have a
reliable way to get at least passable random numbers. The way I do this
in Perl 5:

BEGIN{
eval "use Math::TrulyRandom";
if ($@) {
foreach my $file (qw(/dev/urandom /dev/random)) {
if (-r $file) {
no strict;
*truly_random_value = sub {
use bytes;
local *F;
open F, "<$file" or die "$file: $!";
my $b;
sysread(F,$b,4)==4 or die "$file: $!";
close F;
return unpack("I",$b);
};
last;
}
}
if (!defined \&truly_random_value) {
die "No Math::TrulyRandom and no /dev/(u)random\n$@";
}
}
}

I'd like to stop doing that ;-)

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback


Rod Adams

unread,
Mar 17, 2005, 7:06:22 PM3/17/05
to Perl6 Language List
Aaron Sherman wrote:

>On Wed, 2005-03-16 at 03:18, Rod Adams wrote:
>
>
>>I just posted a fresh copy of S29 to:
>>
>> http://www.rodadams.net/Perl/S29.pod
>> http://www.rodadams.net/Perl/S29.html
>>
>>
>
>>From there:
>
> =head2 Obsolete
>
> =item chop
>
>Chop removes the last character from a string. Is that no longer useful,
>or has chomp simply replaced its most common usage?
>
> chomp($x)
>
>vs
>
> substr($x,-1) = '';
>
>Hrm... well, I guess it's not SO bad....
>
>

And it can almost definitely be redefined as a curried form of C<substr>
if you really feel the need for it. I'll let you know after I write up
C<substr>.

> =item dump
>
> With Parrot?
>
>Yes, but it won't be the same, and it should probably come from a
>module. I'm sure that's going to be required by several folks from
>several different areas (e.g. for checkpointing and all of the uses that
>come from that like process migration). It will also be 99% Parrot's
>job.
>
>

One of the nifty things I'm getting into my head is that writing code
which talks directly to Parrot should be rather easy. Certainly far more
portable than XS ever was. And it's fully open to any module writer.

So while if Perl 5 wanted some capability to be standard in a
distribution, it pretty much had to make it a built in function.
However, esoteric things like C<dump>, which will most likely be a
wrapper for some Parrot utility, but serve no actual purpose to Perl as
a language, don't need to be built in at all.

> =item srand
>
> C<rand(:seed($x))>
>
>Ah, no. C<rand(:seed($x))> will invoke rand, will it not? That's not
>what srand does. srand puts you in a known state, and leaves you there.
>Without srand, even if you're using the same PRNG, you can't plug in
>someone else's seed, and then call the function that will use it, unless
>you can rewind/unshift the PRNG.
>
>

Okay, I'll add it back soon.

I'll listen to proposals about how to support better randoms. For now I
think C<rand> is a standard PRNG.

-- Rod Adams


Aaron Sherman

unread,
Mar 17, 2005, 8:19:53 PM3/17/05
to Rod Adams, Perl6 Language List
On Thu, 2005-03-17 at 18:06 -0600, Rod Adams wrote:

First off, thanks for the reply. Very nice work you're doing!

> I'll listen to proposals about how to support better randoms. For now I
> think C<rand> is a standard PRNG.

Yes, absolutely. If I gave a contrary impression, I did not mean to.

I think it's important for lots of historical reasons to have a
repeatable (and hopefully somewhat standard) PRNG. I was saying that it
would be a very nice thing if, come Perl 6, I did not have to write
hairy code that checks for a module, and fails over to home-baked, OS-
specific ways of getting "good" random data.

This is a SEPARATE need from the need for a repeatable, standard PRNG,
and should always operate off of the best source of entropy available to
the program. Right now, that's /dev/urandom (for non-blocking hybridized
entropy pool + PRNG) under most Unix variants and something like
Math::TrulyRandom's setjmp/longjmp hack elsewhere. Speaking of which,
there's a good reason to keep those two when you get to them ;-)

One solution would be to adapt M::TR to Perl 6, and just pull it into
the core. I'm just saying that it's a wide-spread need among a vast
array of different applications (crypto, games, statistics, etc), and it
makes sense to "corize" it.


Aaron Sherman

unread,
Mar 17, 2005, 8:47:11 PM3/17/05
to Rod Adams, Perl6 Language List
On Wed, 2005-03-16 at 02:18 -0600, Rod Adams wrote:
> I just posted a fresh copy of S29 to:
>
> http://www.rodadams.net/Perl/S29.pod
> http://www.rodadams.net/Perl/S29.html

Couple more points from the docs (mostly to the list, but some to you,
Rod):

multi sub grep (Any|Junction $test : *@values) returns List {
multi sub join (Str $delimiter : *@values) returns List {
multi sub map (Code $expression : *@values) returns List {


multi sub reduce (Code $expression : *@values) returns List {

...

I presume that everything is being declared as multi because we wish
future subs to be able to insert special-cases for their own purposes.

The question then comes up: is there a reason that you would declare a
normal sub in library code... ever? Is plain "sub" no just a request for
mildly unusual optimization? If so, why not make it "nomulti" instead?

>From the list of TODO:

Methods on numeric values (should be defined as pseudo-methods on
unboxed numbers):

chr
hex
oct

index
lc
lcfirst
length
ord
quotemeta
rindex
split
study
substr
uc
ucfirst
unpack

pack
pos
sprintf
caller
defined
prototype
ref
die
do
eval
exit
sleep
bless
gmtime
localtime
time
undef
vec
want
caller


Aaron Sherman

unread,
Mar 17, 2005, 9:05:28 PM3/17/05
to Rod Adams, Perl6 Language List
On Thu, 2005-03-17 at 20:47 -0500, Aaron Sherman wrote:

> Methods on numeric values (should be defined as pseudo-methods on
> unboxed numbers):
>
> chr
> hex
> oct

Sigh... well, now I know what Ctrl-Return does in Evolution :-/

Ok, so what I was getting at was that the above three are methods on
numbers. The following are methods on strings:

> index
> lc
> lcfirst
> length
> ord
> quotemeta
> rindex
> split
> study
> substr
> uc
> ucfirst
> unpack

You might also provide a procedural alias, but:

multi sub lenth(: Str ?$string = $CALLER::_) returns Int {
$string.size; # I think it was called that
}

These are real procedurals:

> pack

Hopefully we'll have something more flexible and user-extensible... oh
and pie. We should have pie :)

> pos

Grrr.. I can't recall what Larry had said about this... I know he
mentioned it once on this list. Maybe that was the ruleish "pos"?

> sprintf

Ah blessed sprintf. Were we adopting a Pythonish implicit sprintf? I
forget. Would that impact the existence of explicit sprintf? Probably
not.

> caller

Larry has said this is a rather hairy TBD in the past, though it might
have been discussed since.

> defined

A universal (pseudo-)method?

> prototype
> ref

See defined.

> die
> do

Gone, I think.... no?

> eval
> exit
> sleep
> bless

A12

> gmtime
> localtime
> time
> undef

How will undef($x) and $x=undef compare in p6? Has that been covered? I
have a vague memory, but nothing swimming to the surface.

> vec

This is pack with issues :)

> want
> caller

dup

Rod Adams

unread,
Mar 17, 2005, 10:40:55 PM3/17/05
to Aaron Sherman, Perl6 Language List
Aaron Sherman wrote:

I would suggest wandering over to P6i and offering to write a Parrot
version of M::TR, and see if they agree to put it in a distro of theirs.
I have no idea what their policy is on getting packages into their
version of "core". But if it's there, then adding it to Perl should be
trivial, regardless of what Perl has in "core".

It's also not a Perlism, so all the other Parrot languages would likely
enjoy it as well.

One thing I see looking at M:TR on CPAN is that it appears to only work
on *nix machines. Making it cross platform would be a Good Thing.


As for setjmp/longjmp:

D:\Home\Perl>perldoc -f setjmp
No documentation for perl function `setjmp' found

D:\Home\Perl>perldoc -f longjmp
No documentation for perl function `longjmp' found

Sounds like they are using XS. (another reason to do it in Parrot).

-- Rod Adams


Rod Adams

unread,
Mar 17, 2005, 10:47:22 PM3/17/05
to Aaron Sherman, Perl6 Language List
Aaron Sherman wrote:

>On Wed, 2005-03-16 at 02:18 -0600, Rod Adams wrote:
>
>
>>I just posted a fresh copy of S29 to:
>>
>> http://www.rodadams.net/Perl/S29.pod
>> http://www.rodadams.net/Perl/S29.html
>>
>>
>
>Couple more points from the docs (mostly to the list, but some to you,
>Rod):
>
> multi sub grep (Any|Junction $test : *@values) returns List {
> multi sub join (Str $delimiter : *@values) returns List {
> multi sub map (Code $expression : *@values) returns List {
> multi sub reduce (Code $expression : *@values) returns List {
> ...
>
>I presume that everything is being declared as multi because we wish
>future subs to be able to insert special-cases for their own purposes.
>
>

Something like that. Also, it's looking now like several of the
functions will be getting multiple definitions out of the box.

>The question then comes up: is there a reason that you would declare a
>normal sub in library code... ever? Is plain "sub" no just a request for
>mildly unusual optimization? If so, why not make it "nomulti" instead?
>
>

To establish one single version of the function that will be called no
matter what. (within it's scope). A sub with a given name will mask any
multi of that name.

And they should be significantly faster to call.

-- Rod Adams


Rod Adams

unread,
Mar 17, 2005, 11:31:07 PM3/17/05
to Aaron Sherman, Perl6 Language List
Aaron Sherman wrote:

>On Thu, 2005-03-17 at 20:47 -0500, Aaron Sherman wrote:
>
>
>
>>Methods on numeric values (should be defined as pseudo-methods on
>>unboxed numbers):
>>
>> chr
>> hex
>>oct
>>
>>
>
>Sigh... well, now I know what Ctrl-Return does in Evolution :-/
>
>Ok, so what I was getting at was that the above three are methods on
>numbers.
>

True, but they are not math functions. They are Num <--> Str
conversions, and I haven't figured out where to put those yet.

>You might also provide a procedural alias, but:
>
> multi sub lenth(: Str ?$string = $CALLER::_) returns Int {
> $string.size; # I think it was called that
> }
>
>

C<length> will be gone once I get there. It's there as a placeholder to
remind me to write the replacements. (Reminds me to write array versions
of them as well).

>These are real procedurals:
>
>>pack
>>
>>
>
>Hopefully we'll have something more flexible and user-extensible...
>
>

Proposals for replacement/reform should go to the list. But until the
matter is changed there, I'm sticking with the Perl5 usage. Yea, it's a
pain in the rump, but it can be invaluable in certain scenarios.

Do read the S09 sections "Compact Structs" and "Compact Arrays" first,
however.

>
>
>>pos
>>
>>
>
>Grrr.. I can't recall what Larry had said about this... I know he
>mentioned it once on this list. Maybe that was the ruleish "pos"?
>
>

A/S05 talks about it some. It's a Str property/method, mainly used with
rule matches. I think it's going to return an String::Position object
which can translate between bytes/chars/codepoints/graphemes

>
>
>>sprintf
>>
>>
>
>Ah blessed sprintf. Were we adopting a Pythonish implicit sprintf? I
>forget. Would that impact the existence of explicit sprintf? Probably
>not.
>
>

It got renamed C<as> recently, and will be pervasive, and in many forms.

>>caller
>>
>>
>
>Larry has said this is a rather hairy TBD in the past, though it might
>have been discussed since.
>
>

The function side of it is easy. S06 says "The |caller| function returns
an object that describes a particular "higher" dynamic scope, from which
the current scope was called."

It's defining that object that gets a little interesting...

>>defined
>>
>>
>
>A universal (pseudo-)method?
>
>
Fairly universal, yes.

>>prototype
>>ref
>>
>>
C<prototype> I will apply to code refs. I'll have to think more about it
later.

C<ref> will be like C<defined>, but might get renamed to something like
C<.meta.class>

>>die
>>do
>>
>>
C<die> is staying, and only getting revamped to take into account the P6
exception scheme.

C<do block> is not a function, but is in S04.

C<do subroutine> is dead.

C<do filename> I'll tackle at the same time as C<eval>. It's likely
staying in some form. I use it from time to time when I'm patching
together several automation scripts. (Remember that Perl gets used for
the quick and dirty as well as the big and elegant.)


>>undef
>>
>>
>
>How will undef($x) and $x=undef compare in p6? Has that been covered? I
>have a vague memory, but nothing swimming to the surface.
>
>

I think they're the same, but I really don't know.

>>vec
>>
>>
>
>This is pack with issues :)
>
>

If nothing else, I plan on making a form that works on Int as well as
one that works on Str. I don't know how many times I've had to resort to
masks and shifts to do something vec should have done for me nicely.


Larry Wall

unread,
Mar 18, 2005, 12:06:59 AM3/18/05
to Perl6 Language List
On Thu, Mar 17, 2005 at 10:31:07PM -0600, Rod Adams wrote:
: Aaron Sherman wrote:
: >>Methods on numeric values (should be defined as pseudo-methods on
: >>unboxed numbers):
: >>
: >> chr
: >> hex
: >>oct
: >>
: >>
: >
: >Sigh... well, now I know what Ctrl-Return does in Evolution :-/
: >
: >Ok, so what I was getting at was that the above three are methods on
: >numbers.
: >
: True, but they are not math functions. They are Num <--> Str
: conversions, and I haven't figured out where to put those yet.

oct and hex are arguably misnamed, since most functions are named by
what they produce, not by what they take as input. I don't know what
the replacement should be, though. Maybe it's not worth fixing.

: C<do filename> I'll tackle at the same time as C<eval>. It's likely

: staying in some form. I use it from time to time when I'm patching
: together several automation scripts. (Remember that Perl gets used for
: the quick and dirty as well as the big and elegant.)

But probably huffmanized to something longer like "evalfile".

: >>undef


: >>
: >>
: >
: >How will undef($x) and $x=undef compare in p6? Has that been covered? I
: >have a vague memory, but nothing swimming to the surface.
: >
: >
: I think they're the same, but I really don't know.

Yes, they're muchly the same. I made some rumblings about undef being
smart about list context, though, so that @foo = undef ends up with
0 elements in @foo, and push(@foo, undef) doesn't get any more elements,
but if you run off the end, you still can get back the undef that was
put there. But we haven't worked all that out.

: >>vec


: >>
: >>
: >
: >This is pack with issues :)
: >
: >
: If nothing else, I plan on making a form that works on Int as well as
: one that works on Str. I don't know how many times I've had to resort to
: masks and shifts to do something vec should have done for me nicely.

I would love to kill vec in favor of declared arrays of tiny
integers, which could presumably be mapped onto other data types
like bytesstrings or integers. This is one of those areas where we
can make good use of the notion that a variable is a view onto some
other piece of data that may not even know it's being viewed strangely.

Larry

Larry Wall

unread,
Mar 18, 2005, 12:18:45 AM3/18/05
to Perl6 Language List
On Thu, Mar 17, 2005 at 06:11:09PM -0500, Aaron Sherman wrote:
: =head2 Obsolete

:
: =item chop
:
: Chop removes the last character from a string. Is that no longer useful,
: or has chomp simply replaced its most common usage?

I expect chop still has its uses. Also, since $/ is going away, the
meaning of chomp will probably change from chomping $/ to removing
whatever was marked as the terminator by the input layer (which
could even vary from line to line if the terminator was specified
as a pattern). But mostly people will just have the input layer
autochomp so they never see the delimiter. (The chomped delimiter
could maybe be attached to the line as a property in case you're
interested, if that's not too high an overhead.)

Autochomping is one of the motivations for switching from "while" to
"for" for the normal line input method, since "while" might think a
blank line is false, while "for" only cares whether the next value
is defined.

Larry

Uri Guttman

unread,
Mar 18, 2005, 12:20:57 AM3/18/05
to Perl6 Language List
>>>>> "LW" == Larry Wall <la...@wall.org> writes:

LW> oct and hex are arguably misnamed, since most functions are named by
LW> what they produce, not by what they take as input. I don't know what
LW> the replacement should be, though. Maybe it's not worth fixing.

from_oct, from_hex which state what they do? or a more general
from_base( 16, $hex )? and that could be curried into from_hex().

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

Matt Diephouse

unread,
Mar 18, 2005, 2:34:57 AM3/18/05
to Uri Guttman, Perl6 Language List
Uri Guttman <u...@stemsystems.com> wrote:
> >>>>> "LW" == Larry Wall <la...@wall.org> writes:
> LW> oct and hex are arguably misnamed, since most functions are named by
> LW> what they produce, not by what they take as input. I don't know what
> LW> the replacement should be, though. Maybe it's not worth fixing.
>
> from_oct, from_hex which state what they do? or a more general
> from_base( 16, $hex )? and that could be curried into from_hex().

0xFF.dec()
$num.dec()
$num.hex()
$num.base($n)

?

I believe that some of these can already be handled by C<.as()>.

I would like for this to be addressed. This is one item that has
always confused me about Perl 5.

--
matt diephouse
http://matt.diephouse.com

Brent 'Dax' Royal-Gordon

unread,
Mar 18, 2005, 2:26:17 AM3/18/05
to Perl6 Language List
Larry Wall <la...@wall.org> wrote:
> : C<do filename> I'll tackle at the same time as C<eval>. It's likely
> : staying in some form. I use it from time to time when I'm patching
> : together several automation scripts. (Remember that Perl gets used for
> : the quick and dirty as well as the big and elegant.)
>
> But probably huffmanized to something longer like "evalfile".

eval :file("somefile.pl6");
eval :string('{$^x + ' ~ $y ~ '}');

eval :file("otherfile.pl"), :lang('perl5');
eval :string("lamda x: x + $y"), :lang('python');

Since as long as we're huffmanizing, eval STRING deserves to be longer
than do STRING.

--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

"I used to have a life, but I liked mail-reading so much better."

Ashley Winters

unread,
Mar 18, 2005, 3:00:57 AM3/18/05
to Perl6 Language List
On Fri, 18 Mar 2005 00:20:57 -0500, Uri Guttman <u...@stemsystems.com> wrote:
> >>>>> "LW" == Larry Wall <la...@wall.org> writes:
>
> LW> oct and hex are arguably misnamed, since most functions are named by
> LW> what they produce, not by what they take as input. I don't know what
> LW> the replacement should be, though. Maybe it's not worth fixing.
>
> from_oct, from_hex which state what they do? or a more general
> from_base( 16, $hex )? and that could be curried into from_hex().

Isn't that actually part of the Standard Perl6 Rule Library?

class Perl6::Rules {
our @HexDigits = 0..9, 'a'..'f';
our @OctDigits = 0..7;
our @DecimalDigits = 0..9;
rule ParseNumber(@digits) returns Int
{ :i [0x]? [$digit := <@digits> { $0 *= @digits.elems; $0 +=
@digits.indexof($digit) }]+ }
&ParseHex := &ParseNumber.assuming :digits(@HexDigits);
}

with &*hex being some sort of alias to Perl6::Rules::ParseHex?

Umm... can you call a rule as a function?

rule foo { .* }

$x = foo("I am the very model of a modern irregular expression");

Or do I not want to know the answer to that?

Ashley Winters

Juerd

unread,
Mar 18, 2005, 5:27:56 AM3/18/05
to Perl6 Language List
Larry Wall skribis 2005-03-17 21:06 (-0800):

> oct and hex are arguably misnamed, since most functions are named by
> what they produce, not by what they take as input. I don't know what
> the replacement should be, though. Maybe it's not worth fixing.

+"0x$_" # hex
+"0o$_" # oct
+"0b$_" # bin (does not exist in Perl 5)

This does require that strings numify the same way literals do, but I
think that's a sane approach anyhow. Now that leading 0 no longer means
the number is octal, I can't think of a good reason to keep the contrast
between literal strings numified during compile time and variable
strings during runtime.

Rod Adams

unread,
Mar 18, 2005, 5:42:04 AM3/18/05
to Perl6 Language List
Brent 'Dax' Royal-Gordon wrote:

>Larry Wall <la...@wall.org> wrote:
>
>
>>: C<do filename> I'll tackle at the same time as C<eval>. It's likely
>>: staying in some form. I use it from time to time when I'm patching
>>: together several automation scripts. (Remember that Perl gets used for
>>: the quick and dirty as well as the big and elegant.)
>>
>>But probably huffmanized to something longer like "evalfile".
>>
>>
>
> eval :file("somefile.pl6");
> eval :string('{$^x + ' ~ $y ~ '}');
>
> eval :file("otherfile.pl"), :lang('perl5');
> eval :string("lamda x: x + $y"), :lang('python');
>
>Since as long as we're huffmanizing, eval STRING deserves to be longer
>than do STRING.
>

Hmm. maybe we just need a function that loads an entire file and returns
a string of it, then feeds that to eval.

C<eval> taking code for other languages.... That's evil. I like it :-)

btw, has some syntax been created for "punt this over to Parrot, in
language X"?

eval q:to:0 /EOB/ :lang('PIR');
...
EOB

eval $=DATA :lang('python');

eval loadfile 'foo.pl' :lang('ponie');

Making them strings eases the task of parsing. The constant heredoc and
pod-block forms definitely seem like something that could be addressed
at compile time.

-- Rod Adams


Rod Adams

unread,
Mar 18, 2005, 6:01:50 AM3/18/05
to Perl6 Language List
Larry Wall wrote:

>On Thu, Mar 17, 2005 at 10:31:07PM -0600, Rod Adams wrote:
>: Aaron Sherman wrote:
>: >>Methods on numeric values (should be defined as pseudo-methods on
>: >>unboxed numbers):
>: >>
>: >> chr
>: >> hex
>: >>oct
>: >>
>: >>
>: >
>: >Sigh... well, now I know what Ctrl-Return does in Evolution :-/
>: >
>: >Ok, so what I was getting at was that the above three are methods on
>: >numbers.
>: >
>: True, but they are not math functions. They are Num <--> Str
>: conversions, and I haven't figured out where to put those yet.
>
>oct and hex are arguably misnamed, since most functions are named by
>what they produce, not by what they take as input. I don't know what
>the replacement should be, though. Maybe it's not worth fixing.
>
>

I'll try to come up with something decent, if no one beats me to it.
Sadly, the C style hex2int, oct2int might be the least confusing, but
heinously ugly.

>: >>vec
>: >>
>: >>
>: >
>: >This is pack with issues :)
>: >
>: >
>: If nothing else, I plan on making a form that works on Int as well as
>: one that works on Str. I don't know how many times I've had to resort to
>: masks and shifts to do something vec should have done for me nicely.
>
>I would love to kill vec in favor of declared arrays of tiny
>integers, which could presumably be mapped onto other data types
>like bytesstrings or integers. This is one of those areas where we
>can make good use of the notion that a variable is a view onto some
>other piece of data that may not even know it's being viewed strangely.
>
>

Could some form of C<:=> do this?

my uint4 @nibbles;
my str $ascii;

@nibbles := $ascii;

$ascii = 'Perl Hacker';
say @nibbles[4];

Would probably need some other bind operator, for the sake of type checking.
Maybe resurrect the C/C++ union construct. hmm. I don't know.

But I think we can keep C<vec>, even spruce it up a little, and then
neglect to import it into *:: if we find something better.

-- Rod Adams


Thomas Sandlaß

unread,
Mar 18, 2005, 6:56:01 AM3/18/05
to Perl6 Language List
Juerd wrote:
> +"0x$_" # hex
> +"0o$_" # oct
> +"0b$_" # bin (does not exist in Perl 5)
>
> This does require that strings numify the same way literals do, but I
> think that's a sane approach anyhow. Now that leading 0 no longer means
> the number is octal, I can't think of a good reason to keep the contrast
> between literal strings numified during compile time and variable
> strings during runtime.

I would think that blending the strong pattern matching of Perl6 with
its strong typing makes for a nice subtype system on strings. So we
could have Str[hex], Str[oct] and Str[bin] that can be build from Num
and Int by means of 'as Str[::base]' where ::base chooses the correspondig
pattern to constrain incoming strings and the format for numbers. Or these
are subclasses of Str.

An example:

my Str[hex] $hex = "abc";
say $hex as Int; # prints 2748

$hex = 17;
say $hex; # prints 0x10


Regards
--
TSa (Thomas Sandlaß)


Uri Guttman

unread,
Mar 18, 2005, 7:39:28 AM3/18/05
to ma...@diephouse.com, Perl6 Language List
>>>>> "MD" == Matt Diephouse <mdd...@gmail.com> writes:

MD> Uri Guttman <u...@stemsystems.com> wrote:
>> >>>>> "LW" == Larry Wall <la...@wall.org> writes:
LW> oct and hex are arguably misnamed, since most functions are named by
LW> what they produce, not by what they take as input. I don't know what
LW> the replacement should be, though. Maybe it's not worth fixing.
>>
>> from_oct, from_hex which state what they do? or a more general
>> from_base( 16, $hex )? and that could be curried into from_hex().

MD> 0xFF.dec()
MD> $num.dec()
MD> $num.hex()
MD> $num.base($n)

MD> ?

MD> I believe that some of these can already be handled by C<.as()>.

MD> I would like for this to be addressed. This is one item that has
MD> always confused me about Perl 5.

wrong direction. p5's hex and oct parse strings into numbers. .as
converts numbers to string format. larry's point was that the p5 names
were misleading as they didn't return what their names implied they
did. my suggestions were to add 'from' to make that conversion explicit.

John Siracusa

unread,
Mar 18, 2005, 8:21:07 AM3/18/05
to Perl 6 Language
On 3/18/05 12:18 AM, Larry Wall wrote:
> Autochomping is one of the motivations for switching from "while" to
> "for" for the normal line input method, since "while" might think a
> blank line is false, while "for" only cares whether the next value
> is defined.

Speaking of which (ha), does that mean we can ditch the hack that internally
auto-translates this:

while($file = readdir(...)) { ... }

into this:

while(defined($file = readdir(...)) { ... }

in Perl 5? Because that'd be nice... :)

-John


Aaron Sherman

unread,
Mar 18, 2005, 10:37:47 AM3/18/05
to Rod Adams, Perl6 Language List
On Fri, 2005-03-18 at 10:28, Aaron Sherman wrote:

> On Fri, 2005-03-18 at 05:42, Rod Adams wrote:
>
> > Hmm. maybe we just need a function that loads an entire file and returns
> > a string of it, then feeds that to eval.
>
> Well, I wasn't getting into the IO stuff, but since you said it, this
> crosses a line with many related IO operations. I would call that
> function "read".
[...]
> Thus:
>
> eval read :file("foo");

Oh, and

$fh1.read undef, :into($fh2); # sendfile maybe
$fh.read undef, :intofile("foo"); # copy via sendfile

is a nice little toy too (that is, read an undefined number of
somethings into $fh2 or file "foo" from $fh1). sendfile(2) can be used
if the IO layers of $fh1 and $f2 match, but I think it can always be
used in the second case. Much of the dirty work may be handled by
Parrot, which I think supports sendfile already.

This also nicely obsoletes File::Copy and IO::SendFile, thus reducing
the number of modules to be ported ;-)

Aaron Sherman

unread,
Mar 18, 2005, 10:28:18 AM3/18/05
to Rod Adams, Perl6 Language List
On Fri, 2005-03-18 at 05:42, Rod Adams wrote:

> Hmm. maybe we just need a function that loads an entire file and returns
> a string of it, then feeds that to eval.

Well, I wasn't getting into the IO stuff, but since you said it, this


crosses a line with many related IO operations. I would call that
function "read".

Given no parameters the read method on a filehandle (or procedural read
function, given a filehandle) is a convenient "getrecord", so given:

read :file("foo")

you have your "read a whole file" (assuming that the default
record-separator for such an operation would be undef).

Thus:

eval read :file("foo");

There you have it.

John Macdonald

unread,
Mar 18, 2005, 12:00:32 PM3/18/05
to Perl6 Language List
On Thu, Mar 17, 2005 at 09:18:45PM -0800, Larry Wall wrote:
> On Thu, Mar 17, 2005 at 06:11:09PM -0500, Aaron Sherman wrote:
> : Chop removes the last character from a string. Is that no longer useful,
> : or has chomp simply replaced its most common usage?
>
> I expect chop still has its uses.

I've had times when I wanted to be able to use chop at either
end of a string.

(I long ago suggested a "chip" operator to chop from the front of
a string. Using chip and chop on a string is much like using
shift and pop on an array.)

Generally when I do this I am not only deleting the character
from the string, but also moving it to another scaler to use;
so substr isn't a simple replacement because you'd have to
use it twice. For chip, I use (perl5):

# $ch = chip $str;
$str =~ s/(.)//;
$ch = $1;

# can be written as:
($ch) = ($str =~ s/(.)//);

If chop is removed, a similar s/// can replace it.

With the advent of rules and grammars in p6, there will likely
be less need for chip/chop type operations so this huffman
extended use of subtr instead of chip/chop would be ok.

--

Paul Seamons

unread,
Mar 18, 2005, 11:46:02 AM3/18/05
to perl6-l...@perl.org
> eval read :file("foo")

How about:

eval slurp "foo";

Paul Seamons

Larry Wall

unread,
Mar 18, 2005, 12:24:43 PM3/18/05
to Perl6 Language List
On Fri, Mar 18, 2005 at 12:00:32PM -0500, John Macdonald wrote:
: Generally when I do this I am not only deleting the character

: from the string, but also moving it to another scaler to use;
: so substr isn't a simple replacement because you'd have to
: use it twice.

Well, not lately. There's

$chopped = substr($line, -1, 1, "");

But I think chip/chop will likely be in * just for handiness. And if
chomp is chomping and returning the terminator as determined by the
line input layer, then chimp would have to return the actual line and
leave just the terminator. :-)

Larry

John Macdonald

unread,
Mar 18, 2005, 1:44:28 PM3/18/05
to Perl6 Language List
On Fri, Mar 18, 2005 at 09:24:43AM -0800, Larry Wall wrote:
> [...] And if

> chomp is chomping and returning the terminator as determined by the
> line input layer, then chimp would have to return the actual line and
> leave just the terminator. :-)

With the mnemonic "Don't monkey around with my terminator." :-)

--

Larry Wall

unread,
Mar 18, 2005, 12:20:15 PM3/18/05
to Perl 6 Language

We've already killed it.

Larry

Larry Wall

unread,
Mar 18, 2005, 12:09:30 PM3/18/05