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
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, 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 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 :digit
yet, so we could go with
:16feedfaceddeadbeef
:84711
:21000_
:101_000_000
:120123456789te
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:
:16feedfaceddeadbeef 8
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 Wed, 2005-03-23 at 12:58, Larry Wall wrote: :21000_ :101_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 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
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
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)
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
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: 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
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: 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
C0x and C0o become the new Chex and Coct (and a C0b for
binary as well).
This establishes a nice parallel with 0xFF and 0o17 that should be
less confusing than Chex and Coct.
say map { chr 0x($_) } split /(\w\w)/,
4a75737420416e6f74686572205065726c204861636b65722e;
--
matt diephouse
http://matt.diephouse.com
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 C0x and C0o become the new Chex and Coct (and a C0b 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
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 C0x and C0o become the new Chex and Coct (and a C0b 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: 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 Cdo EXPR to Cevalfile in S29. (new post soon) -- 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
eval (was Re: New S29 draft up)
Brent 'Dax' Royal-Gordon wrote:
Larry Wall [EMAIL PROTECTED] wrote:
: Cdo filename I'll tackle at the same time as Ceval. 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.
Ceval 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
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 Cvec, even spruce it up a little, and then neglect to import it into *:: if we find something better. -- Rod Adams
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ß)
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: 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: 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: 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)
eval read :file(foo) How about: eval slurp foo; Paul Seamons
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 Cvec, 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: 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: 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 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, 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
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: 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: 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: New S29 draft up
Rod Adams skribis 2005-03-16 23:16 (-0600):
Doesn't Czip 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
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-16 23:16 (-0600):
: Doesn't Czip 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
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 CBit +$shortest to Czip, 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
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
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
Crand(:seed($x))
Ah, no. Crand(: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 [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
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 Csubstr if you really feel the need for it. I'll let you know after I write up Csubstr. =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 Cdump, 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 Crand(:seed($x)) Ah, no. Crand(: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 Crand is a standard PRNG. -- Rod Adams
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 Crand 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
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 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
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 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
}
Clength 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 Cas 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
Cprototype I will apply to code refs. I'll have to think more about it
later.
Cref will be like Cdefined, but might get renamed to something like
C.meta.class
die
do
Cdie is staying, and only getting revamped to take into account the P6
exception scheme.
Cdo block is not a function, but is in S04.
Cdo subroutine is dead.
Cdo filename I'll tackle at the same time as Ceval. 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
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. : Cdo filename I'll tackle at the same time as Ceval. 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
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
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
Larry Wall [EMAIL PROTECTED] wrote:
: Cdo filename I'll tackle at the same time as Ceval. 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
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
-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
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
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 Czip 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
