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: return of copies vs references
I suppose, generally ignore most of my last comments as they seem to be ill-informed. There's just one thing I need to know that will make everything clear: Does 'return' always impose a scalar context on its arguments? Has this been decided for sure, or is it still under debate? If it does, then I know how to do everything I want based on info in the Synopsis and Larry's last comments, otherwise I still could find out what I want to know easily enough. -- Darren Duncan
ENDING OF: Re: return of copies vs references
I was just informed by IRC that 'return' propagates the context of the caller. If that's the case, then we can just drop this discussion, problems solved. Sorry for wasting your time. -- Darren Duncan At 12:07 AM -0800 3/18/05, Darren Duncan wrote: I suppose, generally ignore most of my last comments as they seem to be ill-informed. There's just one thing I need to know that will make everything clear: Does 'return' always impose a scalar context on its arguments? Has this been decided for sure, or is it still under debate? If it does, then I know how to do everything I want based on info in the Synopsis and Larry's last comments, otherwise I still could find out what I want to know easily enough. -- Darren Duncan
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 11:46:52PM +0200, Yuval Kogman wrote:
I think this should mean $_, and if the user really really really
wants to do .foo on the invocant, then why not just say:
method bar ($_:) {
.foo;
}
Because $_ can change.
method bar ($_:) {
.foo;
map { .baz } 1..10; # whoops
}
This keeps $_ unambiguosly the 'it', while 'this' is more specific.
I'm not proposing changing what $_ means, I'm proposing changing what .method
means. Instead of $_.method make it mean $invocant.method. Sooo I'm not
really sure where all that extra stuff about $_ was going, true as it may be.
Perhaps i'm sort of forcing this distinction.
However, I wouldn't be too happy with having to do this, though:
method data {
map { $OUTER::_.process($_) } .things;
}
or having to name the invocant every time I want to map {}.
Right. I believe the times one will want to do a method call on $_ when it
is *not* the invocant will be greatly outnumbered by the times when you
want to do a method call on the invocant. Thus adding ambiguity to .method
is not worth it.
Lastly, what is wrong with
$.method?
As I understand it, $invocant.method and $.method are different. The first
is a public attribute the second is a method call, no? And while all
attributes have an associated method (as I understand, ie. foreach $.foo,
$invocant.foo should always be the same) the reverse is not true.
Foreach $invocant.foo there need not be a $.foo.
If this assumption is incorrect then my argument does collapse.
Re: .method == $self.method or $_.method?
This drifed off list but I don't think that was intentional.
- Forwarded message from Yuval Kogman [EMAIL PROTECTED] -
From: Yuval Kogman [EMAIL PROTECTED]
Date: Fri, 18 Mar 2005 01:12:42 +0200
To: Michael G Schwern [EMAIL PROTECTED]
Subject: Re: .method == $self.method or $_.method?
User-Agent: Mutt/1.5.6i
On Thu, Mar 17, 2005 at 14:42:06 -0800, Michael G Schwern wrote:
Because $_ can change.
method bar ($_:) {
.foo;
map { .baz } 1..10; # whoops
}
I don't see it as a whoops. It's either or, and the user gets to
choose.
I read that as:
method bar ($self:) { for ($self) {
...
}}
BTW, given:
method bar {
# what's $self named in here?
# do you need to name it for it to be accessible?
}
S12 does not specify, as far as I can tell.
Perhaps the desired behavior could be: If the invocant is not
specified it is the default, i.e
method bar {
}
is really
method bar ($_:) {
}
and the user assumes responsibility for not resetting $_ if they
would like to keep it.
As I understand it, $invocant.method and $.method are different. The first
is a public attribute the second is a method call, no? And while all
attributes have an associated method (as I understand, ie. foreach $.foo,
$invocant.foo should always be the same) the reverse is not true.
Foreach $invocant.foo there need not be a $.foo.
I think you are right... But here is an idea:
The only conflict I see with the reverse not being true is if you
would like to avoid calling the is rw accessor when you want to set
the attribute from within the class.
This assumes that $.attribute = ... from within an accessor means
the attribute itself, as a special case, and that all accessors are
rw when their caller is eq ::?CLASS.
Again, the problem is that an accessor that is rw and does funny
stuff to it's attribute could not be avoided when a sibling method
wants to just fudge the attribute.
On second thought, this problem seems bigger now. Opinions?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me beats up some cheese: neeyah!
- End forwarded message -
--
Re: .method == $self.method or $_.method?
[ Sorry if my replies to this thread have seemed a little disjoint. I just realized I'd unsubscribed myself from p6l last year when I started a $job$ and never resubscribed. So I'd only been seeing fragments of the conversation. Catching up from the archives... ] Larry's idea of making $_ == $self in methods seems to swing the pendulum the other way. Now its a shame to have to make everything explicit inside map, grep, and short for loops etc... And yes, what about given? My immediate reaction to o.method and c.method was a little bit of the heebie-jeebies but then I remembered hey, I wrote CLASS.pm so I could do CLASS-method and its exactly the same thing, a constant function which returns the name of the class. Then c.method doesn't seem so weird. And if you want to be crazy I suppose you can define your own c() and o() functions. :) Its shorter than $self.method and it solves the $_ ambiguity problem so that's good. Its a shame to lose the even shorter .method for an extremely common task but I'm not going to quibble to much over a single character. What it doesn't solve is the $.method vs .method issue. They look similar but one works on the invocant and one works on $_. Still a trap.
Re: .method == $self.method or $_.method?
Err, wait, I don't think we are discussing whether $_ is to be outlawed
in map {}. I think the proposal is for .method always mean $invocant.method
and make it illegal when there is no invocants in sight, mush as $.attr
would be illegal without an invocant. To use $_.foo, write $_.foo.
Luke is discussing flow-on effects, just as larry was with his 'o' and 'c'.
if ( .process is $_.process ) {
either {
Specify an explicit invocant --- Larry
} or {
Specify an explicit topical variable --- Luke's musing
}
} else {
Call methods on $_ using $_.method --- My preference still :)
}
The only thing that worries me about The OC idea (how curious that a
feature is so easily named after a TV show) is that he is talking about
them being functions. I don't know enough about interals, but would that
get optimised to something faster, or do we suffer a second function
call every time we want to call a method?
I also have some worries about there being three different ways to call
a simple invocant method.
.method
$_.method (except in map/grep)
o.method
It has a faintly similar smell to the workaround-hell mod_perl 2 got
into... I'm all for TMTOWDTI, but surely the language should be elegant
enough that something as simple as calling a not-special-in-any-way
method doesn't need to have three different ways to do it?
An interesting exercise for anyone with a minicpan checkout would be to
scan CPAN and see how often the various uses are needed currently.
($self- compared to $_-).
Granted there are a hell of a lot of caveats in that, but it there's a
10 to 1 ratio of one to the other, surely that would help to make the
prefered preference a little clearer?
Adam K
How could import constants from other modules?
hi, all
is there any way to import constants from other modules without
specifying scope everytime?
such like this:
module A;
use constant { PI = 3.14, VER = 1.1 }
...
module B;
my $var = A::PI; # this way is fine when A is 'short' or rare
imagination
module C;
use constant tag { PI = 3.14, VER = 1.1 }
...
module D;
use constant C::tag;
my $var = PI; # forgive my laziness
is it a good idea to have header files and include pragma?
(sometimes, a big module file is also a headache. having this
feature, we could split it up.)
song10
___
Yahoo!
250MB
http://tw.promo.yahoo.com/mail_new/index.html
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
Re: .method == $self.method or $_.method?
Michael G Schwern skribis 2005-03-17 14:42 (-0800):
Because $_ can change.
method bar ($_:) {
.foo;
map { .baz } 1..10; # whoops
}
The problem here is not specific to methods.
It is generic to all nested uses $_. We used to see this mostly with
nested foreaches, but now we get methods too.
The solution is also generic for all these situations: either use
$OUTER::_ or give the outer $_ another (second) name.
This is consistent, easy to learn and easy to work around, especially
now that Perl has an easy syntax for aliasing.
I'm not proposing changing what $_ means, I'm proposing changing what .method
means. Instead of $_.method make it mean $invocant.method. Sooo I'm not
really sure where all that extra stuff about $_ was going, true as it may be.
That will be very weird if you still want .foo to work on $_. The same
prefix operator will then have two possible implied invocants. I think
of as a postfix *method* rather than an operator, and would want this
to be consistent.
Right. I believe the times one will want to do a method call on $_ when it
is *not* the invocant will be greatly outnumbered by the times when you
want to do a method call on the invocant. Thus adding ambiguity to .method
is not worth it.
I don't believe this, especially because I read subscripting as methods.
Isn't the whole problem solved by using dotless syntax for calling a
method on the current invocant? If calling methods on the invocant is
indeed more common, then Huffman will like this. I haven't looked into
possible clashing with subs/multis yet.
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: 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: 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: .method == $self.method or $_.method?
Right. I believe the times one will want to do a method call on $_ when it
is *not* the invocant will be greatly outnumbered by the times when you
want to do a method call on the invocant. Thus adding ambiguity to .method
is not worth it.
I think this boils it all down nicely. It seems more important to have
consistency on what .method does. I think it should stay bound to the
invocant and should die/warn if there is none. There are so many almost
short ways to call methods on the current topic of grep or map that it seems
a shame to mess up the consistency of .method just to remove a few
characters.
Consider:
method foo {
.do_one_thing
.and_another_thing
map { $_.do_something_with( .bar ) } .items;
# .bar worked on the invocant - not the items
.and_the_last_thing
}
method foo {
.do_one_thing
.and_another_thing
map { $^item.do_something_with( .bar ) } .items;
.and_the_last_thing
}
Both of those feel clean to me as opposed to
method foo {
o.do_one_thing
o.and_another_thing
map { .do_something_with( o.bar ) } o.items;
o.and_the_last_thing
}
Now granted - that the o. isn't the worst thing to look at. It still seems
harder to follow what is calling which method - you sort of have to deduce
that since the do_something_with call doesn't begin o and because you are in
a map then it must be behaving on the topic $_ even though $_ isn't in sight.
We have added a nother level of details (arguably ambiguity) to try and clear
up some ambiguity.
With the former methods it is clear and consistent which methods are being
called on which variables. The .method doesn't change mid method and I know
what variable is calling do_something_with because it is spelled out.
It seems that the oc behavior and the .method acts on $_ are huffmanized
the wrong direction.
Now with an object in non-method we have with .method only on invocant we
have:
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { $_.do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
sub foo {
map { .do_something_with() } get_items();
# dies because there is no invocant
}
and with the .method uses $_ we have
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { .do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
We haven't really won anything other than dropping a few characters.
As I was thinking about that I began wondering if it was possible to
dynamically specify what the invocant is. Wouldn't you know it? That is
what $_ does currently - except you only get .methods, not $.properties.
The more I think about it the more I think the current behavior of .method on
$_ is wrong. I don't think you should be able to dynamically set the
invocant. Consider the danger of:
method foo {
some_sub_bar();
.do_something();
# this now does get_some_other_object.do_something()
}
sub some_sub_bar {
$CALLER::_ = get_some_other_object();
}
That is kind of scary if call to another sub can hijack my method calls (I'm
sure there are other ways to hijack the method calls - but having the
invocant dynamically set offers too many dangers). Maybe it isn't possible
because $_ will be r only - but somehow I think $_ is rw and the invocant is
r only.
To sum up...
If you are in a method then you get .method and it always works even if $_ is
rebound to something else.
I think that the idea of $_ default to the invocant is necessary and good but
the mistake comes in inferring that .method then must work on $_.
.method should work on the invocant period - it just happens to be a
coincidence that $_ is the same as the invocant for most of the time.
Paul Seamons
I'll go back to lurking about now.
Re: eval (was Re: New S29 draft up)
eval read :file(foo) How about: eval slurp foo; Paul Seamons
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: 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: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
: What it doesn't solve is the $.method vs .method issue. They look similar
: but one works on the invocant and one works on $_. Still a trap.
Yes, and that's probably the killer of the oc idea. So much for
Sleep Brain, heh, heh. I think we'll need to figure out how to
shorten $_.foo instead. Either that, or there has to be a way to
explicitly make $_ the invocant of a subblock.
At the moment I'm trying to see if I could get used to ..method meaning
$_.method, and whether it buys me anything psychologically. Also, how
much of this could be solved with functions that merely default to $_
as in Perl 5? Why do .print if we can say print? (It's not a
rhetorical question, since, .print doesn't look for another argument
in the absence of parens, and print does, which could try to slurp
up a following block. Suppose you are one of those rare people who
actually checks the return value of print to see if you filled up
the disk:
if print {...}
That doesn't parse currently, because the print will treat {...}
as a closure argument and then there's no block for the if.
(Backtracking the parser is probably not the right answer.)
Larry
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
