Re: New S29 draft up
On Sat, Apr 02, 2005 at 11:27:09PM +0300, wolverian wrote: : On Mon, Mar 21, 2005 at 03:31:53PM +0100, Juerd wrote: : > In fact, won't things be much easier if shift and pop workend on strings : > as well as on arrays? Now that we have multis, this should be easy to : > do. : : How about defining String is Array? I don't know if I would like that, : but it's an idea. Unfortunately it'd have to be an Array of String, since most characters these days are not fixed width, even in UTF-16. There's no reason in principle we couldn't do that, but it'd be a lot of extra overhead for most strings, and you can always split to an array explicitly if you really need that. (Plus it would only encourage people coming from C to keep thinking in C.) That being said, we will have a way of taking an array of strings and treating it as a single string for pattern matching. But there's no guarantee that the array elements correspond to individual characters unless you made it that way yourself to begin with. Larry
Re: New S29 draft up
On Mon, Mar 21, 2005 at 03:31:53PM +0100, Juerd wrote: > In fact, won't things be much easier if shift and pop workend on strings > as well as on arrays? Now that we have multis, this should be easy to > do. How about defining String is Array? I don't know if I would like that, but it's an idea. > Juerd -- wolverian signature.asc Description: Digital signature
Re: New S29 draft up
HaloO Larry, you wrote: : class Str[ ::T does StringNumification ] : {...} And then, based only on what you've written there, we need to teach people all about classes, parameterized types, representational types, constraints, formal type parameters, and roles before they can begin to write the radix_to_dec() function they actually wanted... Sorry for that. I think in the end it boils down to specifying what role StringNumification does. I didn't manage to think of a better name. It basically contains unary + which is at the very heart of Perl 6, isn't it? I hope explaining roles is not much harder than explaining tied variables. Regards, -- TSa (Thomas Sandlaß)
Re: New S29 draft up
On Wed, Mar 23, 2005 at 07:33:43PM +0100, Thomas Sandlaß wrote: : Larry Wall wrote: : >So we should probably : >have a generalized radix_to_dec($radix,$input) function out there : >somewhere instead. : : Why not shift it onto the type system: : : my Int $i = $input as Str[$radix] as Int; : : A bit lengthy but quite clear. : And easy to extend e.g. to roman numerals: : : say "VII" as Str[Roman] as Int; # prints 7 I'm not sure most people want to think that way. In fact, I'm slightly sure most people don't. : Of course then we need : : class Str[ uint $radix where { $radix > 1 } ] : {...} : class Str[ ::T does StringNumification ] : {...} And then, based only on what you've written there, we need to teach people all about classes, parameterized types, representational types, constraints, formal type parameters, and roles before they can begin to write the radix_to_dec() function they actually wanted... Larry
Re: New S29 draft up
Larry Wall wrote: So we should probably have a generalized radix_to_dec($radix,$input) function out there somewhere instead. Why not shift it onto the type system: my Int $i = $input as Str[$radix] as Int; A bit lengthy but quite clear. And easy to extend e.g. to roman numerals: say "VII" as Str[Roman] as Int; # prints 7 Of course then we need class Str[ uint $radix where { $radix > 1 } ] {...} class Str[ ::T does StringNumification ] {...} But for literals and input values with a fixed radix, I kinda like the : notation. Yes, it's cool and very general! -- TSa (Thomas Sandlaß)
Re: New S29 draft up
On Wed, 2005-03-23 at 12:58, Larry Wall wrote: > :2<1000_> > :10<1_000_000> Two things: 1. Just a note that Pugs doesn't yet do _ in numbers, but should 2. I'd really like to see a warning on non-standard _ breaks, e.g; 1_00_000 should issue a warning. > Interestingly, that gives us a :16($x) operator for free. Is that a function? E.g. is this valid? $x += :16($y) ? > About the only thing it doesn't give us is > > :$radix<$input> $input.radix($radix) ? I'd suggest that this be a universal virtual method that strings get a definition for. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: New S29 draft up
On Wed, Mar 23, 2005 at 03:28:31PM +, Peter Haworth wrote: : On Mon, 21 Mar 2005 08:41:27 -0800, Larry Wall wrote: : > Okay, I've come around to liking it, but I think we have to say that : > 0x, 0d, 0o, 0b, and whatever else we come up with are just setting : > the default radix. If a string comes in with an explicit 0x, 0d, 0o, : > or 0b, we believe that in preference to the operator. : : Don't we trust the programmer more than the data? I want this code to : produce 4660, 22136, 2832, 3394; not 4660, 22136, 4, 42. : : for '1234','5678','0b10','0d42' { : say 0x $_; : } Er, yes. Sorry--I forgot b and d were valid hex, sigh. Fortunately, my extended brain caught it. :-) But maybe that means that the 0b and 0d notations are bad, and we shouldn't be trying to generalize the 0x pattern that way. We could keep 0x for old times sake, but generalize it some other way. With all the use we've made of my colon, we haven't actually used up : yet, so we could go with :16 :8<4711> :2<1000_> :10<1_000_000> :12<0123456789te> Interestingly, that gives us a :16($x) operator for free. Since the notation encompasses slices, it also gives us a method of distinguishing exponents from mantissas for notations where "e" is ambiguous: :16 About the only thing it doesn't give us is :$radix<$input> I suppose we could make Pairs interpret their right arg in numeric context to let $radix => $input do the general thing, but that's getting a little out there. Still, what other numeric interpretation might you want to give to a pair object? The main problem with commandeering pair notation for that is simply that it's not obvious, and for such a rare operation you should use something huffmanly obvious. So we should probably have a generalized radix_to_dec($radix,$input) function out there somewhere instead. But for literals and input values with a fixed radix, I kinda like the : notation. Larry
Re: New S29 draft up
On Mon, 21 Mar 2005 08:41:27 -0800, Larry Wall wrote: > Okay, I've come around to liking it, but I think we have to say that > 0x, 0d, 0o, 0b, and whatever else we come up with are just setting > the default radix. If a string comes in with an explicit 0x, 0d, 0o, > or 0b, we believe that in preference to the operator. Don't we trust the programmer more than the data? I want this code to produce 4660, 22136, 2832, 3394; not 4660, 22136, 4, 42. for '1234','5678','0b10','0d42' { say 0x $_; } -- Peter Haworth [EMAIL PROTECTED] "It's not a can of worms, it's a tank of shai-hulud." -- Jarkko Hietaniemi
Re: New S29 draft up
On Mon, Mar 21, 2005 at 03:31:53PM +0100, Juerd wrote: > [...] (The symmetry is slightly broken, though, because if you push > "foo" once, you have to pop three times to get it back. I don't think > this is a problem.)) That's not a new break to the symmetry of push and pop: @b = (1,2,3); push( @a, @b ); # needs 3 pops to get all of 1,2,3 back and in both the original array form and in the "treat a string as an array" form, you can retrieve a multi-element thing that was push'ed in a single operation by using a single invokation of splice. --
Re: New S29 draft up
On Sun, Mar 20, 2005 at 08:54:54PM -0600, Rod Adams wrote: Okay, I've come around to liking it, but I think we have to say that 0x, 0d, 0o, 0b, and whatever else we come up with are just setting the default radix. If a string comes in with an explicit 0x, 0d, 0o, or 0b, we believe that in preference to the operator. The operator just says what to assume in the absence of an explicit marker. Then we just tell people that ordinary str-to-num conversion happens to be identical to the 0d operator. Larry
Re: eval (was Re: New S29 draft up)
Paul Seamons skribis 2005-03-18 9:46 (-0700): > eval slurp "foo"; That requires foo to have an #line directive (or whatever its Perl 6 equivalent will be) in order to be useful when debugging. See also http://tnx.nl/include (I want Perl 6 to have this function that evals a file such that in it, lexical variables are visible). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: New S29 draft up
John Macdonald skribis 2005-03-18 12:00 (-0500): > I've had times when I wanted to be able to use chop at either > end of a string. In fact, won't things be much easier if shift and pop workend on strings as well as on arrays? Now that we have multis, this should be easy to do. (For symmetry, this'd also require push to be a synonym for ~= and unshift to be a synonym for s/^/.../. Two things I would certainly like having. (The symmetry is slightly broken, though, because if you push "foo" once, you have to pop three times to get it back. I don't think this is a problem.)) This kind of dwimmery already exists for reverse and would work well with split (regex or string) too. If slice is added to splice, substr can just be an alias for slice (or disappear), and slice can call splice if there's a 4th argument. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: eval (was Re: New S29 draft up)
Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strikes again. I've renamed C to C in S29. (new post soon) -- Rod Adams
Re: New S29 draft up
Luke Palmer wrote: Matt Diephouse writes: Juerd <[EMAIL PROTECTED]> wrote: Matt Diephouse skribis 2005-03-18 13:35 (-0500): Too bad sub names can't start with numbers: 0x $hex; # hex $hex But they can, if you call them prefix operators instead of subs. See also -e and alike operators, which start with a character that isn't even \w. In that case, I propose, if more radical action is not taken, that C<0x> and C<0o> become the new C and C (and a C<0b> for binary as well). Hmm. I like that idea. Quite a lot. Just like `if $x == 1 | 2`, this is one of those things that a newbie to programming would ask "why can't I do that?" For the record, this is the currently what I plan on doing in S29 unless I hear a strong objection or something better. -- Rod Adams
Re: New S29 draft up
Matt Diephouse writes: > Juerd <[EMAIL PROTECTED]> wrote: > > Matt Diephouse skribis 2005-03-18 13:35 (-0500): > > > Too bad sub names can't start with numbers: > > > 0x $hex; # hex $hex > > > > But they can, if you call them prefix operators instead of subs. See > > also -e and alike operators, which start with a character that isn't > > even \w. > > In that case, I propose, if more radical action is not taken, that > C<0x> and C<0o> become the new C and C (and a C<0b> for > binary as well). Hmm. I like that idea. Quite a lot. Just like `if $x == 1 | 2`, this is one of those things that a newbie to programming would ask "why can't I do that?" Luke
Re: New S29 draft up
Juerd <[EMAIL PROTECTED]> wrote: > Matt Diephouse skribis 2005-03-18 13:35 (-0500): > > Too bad sub names can't start with numbers: > > 0x $hex; # hex $hex > > But they can, if you call them prefix operators instead of subs. See > also -e and alike operators, which start with a character that isn't > even \w. In that case, I propose, if more radical action is not taken, that C<0x> and C<0o> become the new C and C (and a C<0b> for binary as well). This establishes a nice parallel with 0xFF and 0o17 that should be less confusing than C and C. say map { chr 0x($_) } split /(\w\w)/, "4a75737420416e6f74686572205065726c204861636b65722e"; -- matt diephouse http://matt.diephouse.com
Re: New S29 draft up
Matt Diephouse skribis 2005-03-18 13:35 (-0500): > > +"0x$_" # hex > > +"0o$_" # oct > > +"0b$_" # bin (does not exist in Perl 5) > Too bad sub names can't start with numbers: > 0x $hex; # hex $hex But they can, if you call them prefix operators instead of subs. See also -e and alike operators, which start with a character that isn't even \w. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: eval (was Re: New S29 draft up)
Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strikes again. ...unless read returns a Str but source("foo"). -=- James Mastros
Re: eval (was Re: New S29 draft up)
Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strikes again. Larry This reminds of me of an idea I floated a few months ago: http://www.codecomments.com/message238291.html. I don't see any reason (other than performance) why strings shouldn't be tagged with their source. For taint-checking, we might even want to record the trustworthyness of that source at the same time. If a string were analagous to an mmap of a file, then many other orthogonalities might become available.
Re: New S29 draft up
John Macdonald wrote: 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. Actually, I think this can be handled by the "new view" type casting Larry was rumbling about. Simply re-view your string as an "Array of Chars", (bytes/codepoints/graphemes) and then pop or shift. Let's see where that thread ends up first. -- Rod Adams
Re: New S29 draft up
On Fri, 18 Mar 2005 11:27:56 +0100, Juerd <[EMAIL PROTECTED]> wrote: > 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) Too bad sub names can't start with numbers: 0x $hex; # hex $hex 0x($hex); 0b $bin; 0o $oct; That would make sense to me. -- matt diephouse http://matt.diephouse.com
Re: New S29 draft up
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." :-) --
Re: New S29 draft up
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
Re: New S29 draft up
On Fri, Mar 18, 2005 at 08:21:07AM -0500, John Siracusa wrote: : 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... :) We've already killed it. Larry
Re: Bitops (was Re: New S29 draft up)
On Fri, Mar 18, 2005 at 05:01:50AM -0600, Rod Adams wrote: : 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. Yes, though there are two difficulties right there in the names: hardwiring the radix, and assuming they won't be used for fractional values. So they'd probably be curried from something more general. : 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. Yes, that should probably fail the bind. I was thinking something more on the lines of the old "is from(@array)" that we were using to feed arrays to rules, but since we can do that directly now, we don't need "is from", which is wrong anyway. "is mapped" or "is viewof" is closer. It's really a kind of tie if you think of it in Perl 5 terms. : But I think we can keep C, even spruce it up a little, and then : neglect to import it into *:: if we find something better. Very likely there is a P5:: space for all the emulations that p5-to-p6 will rely on when it is uncertain how to refactor. This could go there if we want to discourage people from using it for new stuff. Larry
Re: eval (was Re: New S29 draft up)
On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strikes again. Larry
Re: eval (was Re: New S29 draft up)
> eval read :file("foo") How about: eval slurp "foo"; Paul Seamons
Re: New S29 draft up
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. --
Re: eval (was Re: New S29 draft up)
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 <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: eval (was Re: New S29 draft up)
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. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: New S29 draft up
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
Re: New S29 draft up
> "MD" == Matt Diephouse <[EMAIL PROTECTED]> writes: MD> Uri Guttman <[EMAIL PROTECTED]> wrote: >> > "LW" == Larry Wall <[EMAIL PROTECTED]> 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. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: New S29 draft up
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ß)
Bitops (was Re: New S29 draft up)
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, even spruce it up a little, and then neglect to import it into *:: if we find something better. -- Rod Adams
eval (was Re: New S29 draft up)
Brent 'Dax' Royal-Gordon wrote: Larry Wall <[EMAIL PROTECTED]> wrote: : C I'll tackle at the same time as C. 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 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
Re: New S29 draft up
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. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Perl6 Rule library (was: New S29 draft up)
On Fri, 18 Mar 2005 00:20:57 -0500, Uri Guttman <[EMAIL PROTECTED]> wrote: > > "LW" == Larry Wall <[EMAIL PROTECTED]> 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
Re: New S29 draft up
Uri Guttman <[EMAIL PROTECTED]> wrote: > > "LW" == Larry Wall <[EMAIL PROTECTED]> 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
Re: New S29 draft up
Larry Wall <[EMAIL PROTECTED]> wrote: > : C I'll tackle at the same time as C. 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 <[EMAIL PROTECTED]> Perl and Parrot hacker "I used to have a life, but I liked mail-reading so much better."
Re: New S29 draft up
> "LW" == Larry Wall <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: New S29 draft up
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
Re: New S29 draft up
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 I'll tackle at the same time as C. 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
Re: New S29 draft up
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 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 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 I will apply to code refs. I'll have to think more about it later. C will be like C, but might get renamed to something like C<.meta.class> die do C is staying, and only getting revamped to take into account the P6 exception scheme. C is not a function, but is in S04. C is dead. C I'll tackle at the same time as C. 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.
Re: New S29 draft up
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 : [EMAIL PROTECTED]) returns List { multi sub join (Str $delimiter : [EMAIL PROTECTED]) returns List { multi sub map (Code $expression : [EMAIL PROTECTED]) returns List { multi sub reduce (Code $expression : [EMAIL PROTECTED]) 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
Re: New S29 draft up
Aaron Sherman wrote: On Thu, 2005-03-17 at 18:06 -0600, Rod Adams wrote: 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. 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
Re: New S29 draft up
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
Re: New S29 draft up
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 : [EMAIL PROTECTED]) returns List { multi sub join (Str $delimiter : [EMAIL PROTECTED]) returns List { multi sub map (Code $expression : [EMAIL PROTECTED]) returns List { multi sub reduce (Code $expression : [EMAIL PROTECTED]) 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
Re: New S29 draft up
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 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.
Re: New S29 draft up
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 if you really feel the need for it. I'll let you know after I write up C. =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, 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 Ah, no. C 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 is a standard PRNG. -- Rod Adams
Re: New S29 draft up
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 Ah, no. C 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 <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: New S29 draft up
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 Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: New S29 draft up
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 to C, 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
Re: New S29 draft up
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote: : Rod Adams skribis 2005-03-16 23:16 (-0600): : > Doesn't C 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
Re: New S29 draft up
Rod Adams skribis 2005-03-16 23:16 (-0600): > Doesn't C 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
Re: New S29 draft up
Luke Palmer wrote: Joe Gottman writes: multi sub kv (Array @array : [EMAIL PROTECTED]) 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 go until the longest input is exhausted, returning undef at the end of the shorter ones? multi sub kv (@array) returns List { zip([EMAIL PROTECTED] ; @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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]) returns Int|List multi sub kv (@array : Any|Junction [EMAIL PROTECTED]) returns Int|List multi sub pairs (@array : Any|Junction [EMAIL PROTECTED]) returns Int|(List of Pair) multi sub values (@array : Any|Junction [EMAIL PROTECTED]) 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
Re: New S29 draft up
Joe Gottman writes: > multi sub kv (Array @array : [EMAIL PROTECTED]) 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 [EMAIL PROTECTED] parameter seems superflous, since you could just do: for @array[1..10].kv -> $k, $v {...} Luke
RE: New S29 draft up
> -Original Message- > From: Rod Adams [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 16, 2005 3:18 AM > To: Perl6 Language List > Subject: New S29 draft up > > > 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. > 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 : [EMAIL PROTECTED]) 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 : [EMAIL PROTECTED]) returns List { my $res; for @values -> $cur { FIRST {$res = $cur; next;} $res = &$expression($res, $cur); } $res; } Joe Gottman
New S29 draft up
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