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: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Damian Conway wrote: [No, I'm not back; I'm just passing by. But I feel that I need to comment on this whole issue] Thanks! This message has lots of useful information that I would have otherwise probably missed. It seems that the basic premise of the POD document object model gels well with that early design document, so I look forward to being able to flesh out the details. Using ^=\s to delimit a line starting with a = will interfere with the Kwid method of: = Heading foo Which I was imagining would be converted to a DOM tree that when represented in the "Normative XML" would look like: Heading foo That's sort of DocBook style, and in fact I was thinking that for the internal representation, DocBook node names could be used where there is no other better alternative. Of course, non-documentation things like Test fragments or inclusions of external entities, like UML diagrams won't have a representation in DocBook :-). The uses of a leading = in a paragraph are fairly uncommon. For instance, when quoting POD you would simply indent it a bit to make it verbatim and there is no issue. I see a middle ground; that is, `=` quoting is only is allowed if it directly follows the initial POD marker; =head1 Foo = = =head1 = = = = =head1 That's just getting ridiculous Which I see as represented by; Foo =head1 = = =head1 That's just getting ridiculous Which of course would lose the ='s. But that's OK, because if you wanted verbatim you could have just indented the block. If you wanted to lead a normal paragraph with it, you'd just use the normally implicit =para (equivalent to =pod): =para = = = This is what a Kwid =head1 looks like As for going with =kwid to denote the starting of kwid, I have so far been pessimistically assuming that something like `=dialect kwid`, or `=use kwid` (as described in the design doc you attached) would be required. However, we could allow `=unknown`, where `unknown` is an unknown keyword, to try to load Pod::Dialect::unknown, and hope like hell it provides the Role of Pod::Dialect. While the `^=` escaping is “active”, the presence or absence of whitespace following the initial `=` will delimit breaks in paragraphs. This has to be so, otherwise the previous example would have been: Foo =head1 = = =head1 That's just getting ridiculous Which is just plain silly. This follows what people are used to with POD - blank lines must be empty, not just no non-whitespace characters (an increasingly vague concept these days). So, the POD processing happens in 3 levels (note: the first isn't really mentioned in perlpodspec.kwid, which is a bug); =list - chunkification from the original source, into POD paragraphs, which may or may not include an initial `^=foo` marker. At *this* level, the only escaping that happens is the `^=` escaping. That's all that needs to happen while the code is being read, and for most code that is how the POD will remain, in memory, somewhere intermingled with the Parse Tree for the code, so that the code can still be spat back out by the P6 equivalent of `B::Deparse` - parsing of these raw chunks into a real POD DOM. Please, tired XML veterans, please don't get upset by the use of the term "DOM", I think the last thing anyone wants is to have studlyCaps functions like `getElementById` and `createTextNode`. It is the tree concept itself which is important, and this pre-dates XML anyway. Strictly speaking, this step actually converts POD paragraph chunk events into POD DOM events. These can be used to build a real DOM, for instance if you need to do an XPath style query for a link (I was amazed that someone's actually gone and built Pod::XPath!), or they might simply be passed onto the next stage by an output processor with no intermediate tree being built. So, at this point, dialects get hooks to perform custom mutation of POD paragraph events into DOM events, and the arbitrator of this process ensures that the output events are well "balanced" by spitting out closing tags where it has to. They can store state in their parser object, but none of this state will be preserved past the parsing state. However, the nodes that they "spit out" after this point may still not be "core" POD, such as for includes or out-of-band objects. These hooks will be sufficient to allow them to hijack subsequent chunks that would otherwise be served to other dialects, ie, they can choose to "arbitrate" subsequent chunks. I'm aiming to make it so that it is possible for dialects to be "round trip safe", by being able to go back from this DOM state to the original POD paragraph chunks. This would require dialects to "play nice" of course, but is a potential option to help make things like smart text editors be able to automatically syntax highlight POD dialects :). Linking will be in terms of this intermediate tree, so you won't be able to link to included portions of m
Re: Junctions Question
Stevan Little writes: > my $a = 'a'; > my $b = ''; > my $c = ''; > > my $any_of_them = $b | $c | $a; > # this test passes > ok('a' eq $any_of_them, '($b | $c | $a) matches at least one "a"'); > > $b = 'b'; > $c = 'c'; > > # this test passes ... > ok('a' eq $any_of_them, '($b | $c | $a) matches at least one "a"'); > # but these two tests don't > ok('b' eq $any_of_them, '($a | $b | $c) matches at least one "b"'); > ok('c' eq $any_of_them, '($c | $a | $b) matches at least one "c"'); That behavior is correct. Just as if you said: my $a = 'a'; my $b = $a; $a = 'b'; say $b; # a This should work, however: my $a = 'a'; my $b = ''; my $c = ''; my $any_of_them = \$a | \$b | \$c; $b = 'b'; $c = 'c'; ok('b' eq $$any_of_them); # passes That second $ might not need to be there. I don't understand exactly how transparent references are yet. Luke
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
Junctions Question
Hello All, I have been working on some misc. junction tests for Pugs and I ran into an item which I am not sure of. It has to do with a junction of variables which is then assigned to variable itself, and how "bound" the variables inside the junction are. This is best illustrated with code, so here is the test with comments to explain: my $a = 'a'; my $b = ''; my $c = ''; my $any_of_them = $b | $c | $a; # this test passes ok('a' eq $any_of_them, '($b | $c | $a) matches at least one "a"'); $b = 'b'; $c = 'c'; # this test passes ... ok('a' eq $any_of_them, '($b | $c | $a) matches at least one "a"'); # but these two tests don't ok('b' eq $any_of_them, '($a | $b | $c) matches at least one "b"'); ok('c' eq $any_of_them, '($c | $a | $b) matches at least one "c"'); Those last two tests do pass if I re-make the $any_of_them junction after assigning $b and $c. This is actually best illustrated again with this code. my $a = 'a'; my $b = ''; my $c = ''; my $any_of_them = $b | $c | $a; say $any_of_them; $b = 'b'; $c = 'c'; say $any_of_them; my $any_of_them = $b | $c | $a; say $any_of_them; Which will print the following: any(a) any(a) any(a,b,c) So my question is; Is this correct? Or should $a, $b and $c be more tightly bound within the $any_of_them junction? Thanks in advance, - Stevan
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: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Oh, and I forgot to mention: In the contents of any block, any line with '=' in column zero and a whitespace character in column 1, has those two characters removed when the contents are extracted. So you can write: =begin data POSSIBLE_POD_DIRECTIVES = = =doh -- Oh, dear! Oh frikking dear! = =ray -- A ravening beam of destruction = =me -- A name I call my invocant = =far -- A long, long way to Australia = =sew -- What I do with contention = =LA -- A place to follow trends = =tee -- I pipe to double streams = =end data To create the inline data: =doh -- Oh, dear! Oh frikking dear! =ray -- A ravening beam of destruction =me -- A name I call my invocant =far -- A long, long way to Australia =sew -- What I do with contention =LA -- A place to follow freaks =tee -- I pipe to double streams Damian
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
[No, I'm not back; I'm just passing by. But I feel that I need to comment on this whole issue] Even before Brian announced Kwid, I was privately suggesting to Larry that Markdown (http://daringfireball.net/projects/markdown/) was an excellent evolution of mark-up notations and might be well suited to Perl 6. At least...as a second allowable syntax. And, in my view, Kwid kicks Markdown's butt in terms of its suitability for Perl documentation. POD itself is brilliant and we should certainly not abandon it, but it's critical to remember that POD is just an *interface* (or B, if you prefer ;-) to Perl's built-in documentation systems. I strongly believe that Kwid is, for many purposes, a cleaner and less-intrusive interface, and I for one will be using it (even if I have to build a kwid2pod translator). But frankly, I'd rather just be able to write: =kwid in place of =pod within standard Perl 6. As for the larger issue of redoing pod, I've appended my notes on where the Design Team left their discussions when last we discussed it. This might spark some ideas (but note that I will not be able to respond to them any time soon -- alas, bread-winning must, for the moment, take precedence over most of my public activities). Damian -cut--cut--cut--cut--cut- There would be a single consistent rule that says that every POD block (except raw text blocks) has one of the following three equivalent syntactic forms: =begin TYPE OPTIONAL_MULTIWORD_LABEL_TO_END_OF_LINE BLOCK_CONTENTS_START_HERE_AND_CONTINUE_OVER_MULTIPLE_LINES_UNTIL... =end TYPE OPTIONAL_SAME_MULTIWORD_LABEL or: =for TYPE OPTIONAL_MULTIWORD_LABEL_TO_END_OF_LINE BLOCK_CONTENTS_START_HERE_AND_CONTINUE_OVER_MULTIPLE_LINES_UNTIL... or: =TYPE BLOCK_CONTENTS_START_HERE_AND_CONTINUE_OVER_MULTIPLE_LINES_UNTIL... For example: =begin table Table of Contents Constants 1 Variables 10 Subroutines 33 Everything else 57 =end table =begin list =begin item * Doh =end item =begin item * Ray =end item =begin item * Me =end item =end list =begin comment This is the most verbose way to write all this =end comment Or equivalently: =for table Table of Contents Constants 1 Variables 10 Subroutines 33 Everything else 57 =begin list =for item * Doh =for item * Ray =for item * Me =end list =for comment This is a less verbose way to write all this Or also equivalently: =for table Table of Contents Constants 1 Variables 10 Subroutines 33 Everything else 57 =for list =item * Doh =item * Ray =item * Me =comment This is the least verbose way to write all this POD formatters could then be simply and consistently implemented by inheriting from a standard Pod::Base class, which would provide a C<.parse_pod> method that sequentially extracts each block construct (from whichever of the three syntaxes), including raw text blocks (which are actually just unlabelled C<=for body> blocks), and raw code blocks (which are actually just unlabelled C<=for verbatim> blocks). C<.parse_pod> would be something like: multi method parse_pod ($self: Str $from_str) { # Get sequence of POD blocks to be parsed # Using standard rules... my @blocks = $self.extract_pod($from_str); # Dispatch each block to be processed by the # appropriate method... for @blocks -> $block { my ($type, $label, $contents) = $block; $self.$type($label, $contents); } } When each C<.$type()> method is called, both the label and contents would passed as simple strings (either of which might, of course, be empty if the corresponding component had been omitted from the block). The (multi)method thus selected would then be responsible for formatting/processing/whatevering the label and contents passed to it: method head1 ($label, $contents) {...} method head2 ($label, $contents) {...} method list ($label, $contents) {...} method item ($label, $contents) {...} # etc. Note that under this scheme the Perl5 syntax for: =head1 Title here =head2 Subtitle here =head3 Subsubtitle here =head4 Subsubsubsubtitle here =item Bullet Item text =cut =pod would mostly all continue to work (though, of course, C<=cut> and C<=pod> would actually be dealt with directly within C<.extract_from>). The most noticable change would be that something like: =item Bullet Text of item here would now have to be written either as: =item Bullet Text of item here (an improvement, I suspect), or as: =item Bullet Text of item here (assuming the .item() method was clever enou
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: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, Mar 17, 2005 at 05:04:53PM -0500, Aaron Sherman wrote: > On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote: > > > The interesting thing to me is that all 3 syntaxes map over the same > > data model and thus are easily interchangable. > > It is, however, contrary to the spirit of POD for you or me to continue > much further down this road (see below). > > > Sam "mugwump" Vilain [...] > > is working on more formally defining the common model or "AST" that > > these dialects map to. > > My effort here was to try to PREVENT the proliferation (e.g. by Kwid and > POD butting heads and ending up in a stalemate). > > I'll continue only as far as is needed to propose this in full as an > example parser / converter, and then I'm going to stop. If Brian is correct about the fundamental interchangeability of these dialects (and I have no reason to think he isn't), may I suggest that the simple answer is to have a program which can translate from one dialect to another--just like we distribute pod2man, pod2html, and pod2text, we would now distribute pod2kwid and ajskwid2pod. --Dks -- [EMAIL PROTECTED]
Re: return of copies vs references
As an addendum, my idea would also apply to non-attribute variables. If you say 'my %abc' in a method or sub, and later say 'return %abc', then a reference to %abc will be returned by default. So its not like I'm treating attributes differently. -- Darren Duncan At 3:27 PM -0800 3/17/05, Darren Duncan wrote: It occurs to me that I may have requested something before that would cause more problems than it solves if implemented. So I have a different idea that would hopefully be efficient, powerful, and easy to learn. In short, make it work much like Perl 5. The idea is Perl methods and subs will always return references or scalars by default, just as method/sub arguments always take references or scalars by default; so we have symmetry between the in/out. And they would do this the same way regardless of the caller scalar/list context. If the writer of a method/sub wants to return a copy of a non-trivial structure like a hash or array, they explicitly copy it and return the copy. This is elegant because when they are explicitly copying, they can also fully control to what depth in a tree-like structure the items have either their values or their references copied. For example, with the same $:foo, @:bar, %:baz attributes ... These would return references to the structure root, in all contexts: return \$self.:foo; return $self.:bar; return $self.:baz; return \$:foo; return @:bar; return %:baz; These would return a new structure with level-1 copies of the elements, but if any elements are references then the copies point to the same things in all contexts: return $self.:foo; return [$self.:bar]; return {$self.:baz}; return $:foo; return [@:bar]; return {%:baz}; The exact syntax could vary. The above would scale to, say, explicit 2-dimensional copy similarly to Perl 5, like this: return [$self.:bar.map:{ [$_] }]; return [@:bar.map:{ [$_] }]; Now, I am operating under the assumption here that in Perl 6, the line between having a reference to something or having that thing is blurred, and so there is no need to do explicit dereferencing; eg, no @{} or %{}. All that the caller context would then determine is whether what the method/sub returned is flattened or not; the caller context would not determine whether the method/sub returns a copy or a reference. Question: Is there a trait for a sub/method that specifies whether it forces a scalar or list context? Any opinions on this? -- Darren Duncan
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 17 Mar 2005 16:16:00 -0700, gcomnz <[EMAIL PROTECTED]> wrote: Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: >By the way, I think I've seen a few people suggest some sort of >syntax-switching mechanism for "Pod6". The day people have to think >about what dialect of Pod they're using is the day Pod dies as a >useful documentation language. 1. TMTOWTDI 2. Competition will help, not hinder. I for one would very much like to see a more Wiki and less POD like syntax. But that's a matter of taste. I will say though that I've never heard of anyone suffering because of how wide or narrow the [ and ] characters are in Wiki markup ;-). And MediaWiki's format is a beautiful example of a markup that has taken off and vastly simplified page creation and editing for over 100,000 editors at Wikipedia. 3. A format like I or C is just plain ugly and verbose. I can't imagine why anyone defends that as something too keep. In understand there's a lot of love/hate emotion when it comes to Wiki's, but if we step back and ignore for a moment what the alternatives are will we really still want to keep that ugly inline syntax? (No disrespect intended, POD clearly predates of lot of other ideas about simple markups.) Marcus
Re: return of copies vs references
It occurs to me that I may have requested something before that would cause more problems than it solves if implemented. So I have a different idea that would hopefully be efficient, powerful, and easy to learn. In short, make it work much like Perl 5. The idea is Perl methods and subs will always return references or scalars by default, just as method/sub arguments always take references or scalars by default; so we have symmetry between the in/out. And they would do this the same way regardless of the caller scalar/list context. If the writer of a method/sub wants to return a copy of a non-trivial structure like a hash or array, they explicitly copy it and return the copy. This is elegant because when they are explicitly copying, they can also fully control to what depth in a tree-like structure the items have either their values or their references copied. For example, with the same $:foo, @:bar, %:baz attributes ... These would return references to the structure root, in all contexts: return \$self.:foo; return $self.:bar; return $self.:baz; return \$:foo; return @:bar; return %:baz; These would return a new structure with level-1 copies of the elements, but if any elements are references then the copies point to the same things in all contexts: return $self.:foo; return [$self.:bar]; return {$self.:baz}; return $:foo; return [@:bar]; return {%:baz}; The exact syntax could vary. The above would scale to, say, explicit 2-dimensional copy similarly to Perl 5, like this: return [$self.:bar.map:{ [$_] }]; return [@:bar.map:{ [$_] }]; Now, I am operating under the assumption here that in Perl 6, the line between having a reference to something or having that thing is blurred, and so there is no need to do explicit dereferencing; eg, no @{} or %{}. All that the caller context would then determine is whether what the method/sub returned is flattened or not; the caller context would not determine whether the method/sub returns a copy or a reference. Question: Is there a trait for a sub/method that specifies whether it forces a scalar or list context? Any opinions on this? -- Darren Duncan
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: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman wrote: Sam "mugwump" Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or "AST" that these dialects map to. Why? Seriously, why on earth do you want to encourage the proliferation of variant markup languages?! There aren't enough? My effort here was to try to PREVENT the proliferation (e.g. by Kwid and POD butting heads and ending up in a stalemate). The only problem is that, presented with a compromise, the Kwid folks seem to be content to ADD it to the list of variants rather than, in fact, compromise and collapse the list. I'll continue only as far as is needed to propose this in full as an example parser / converter, and then I'm going to stop. My goal is not to proliferate the number of markups further, and I'd MUCH rather see Perl 6 rely on POD than fragment the SINGLE MOST IMPORTANT TASK in creating code to share with the world: documentation. Well, I don't think anyone wants to see as many POD dialects as there are wiki text formats (BBCode, anyone?). Maybe there will be something very close to the original POD, but with a verbose way of making tables, and an enhanced linking syntax. But otherwise identical to the original Perl 5 POD. Note that POD dialects, and differing POD conventions already exist in Perl 5 and are in common use. They were designed in the original POD with the =for tag. At the moment, tools like `pod2html' have to be heavily aware of the POD dialect, which I think is sub-optimal when it comes to some of the really interesting things people have achieved with POD. Look at MarkOv's OODoc, or Test::Inline, for instance. All I'm trying to do is giving these beasts a name, and defining a mechanism by which they can be used by tools that only know how to deal with "standard" documents - thus giving users the freedom to define a local convention if one of them doesn't quite fit their needs. Using a local Subversion repository, and Request Tracker, and want to be able to put hyperlinks in POD to refer to these entities? No problem, just extend the dialect and add a link style. Then select from a dozen output tools or variants to see which one works for you. Sam.
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 17:07, Brent 'Dax' Royal-Gordon wrote: > Aaron Sherman <[EMAIL PROTECTED]> wrote: > > and the hacks in > > pod syntax (e.g. C<< < >>) to get around this are glaring anti- > > huffmanisms. > > Whatever bracketing character we decide to use, there will always be > occasions where we need to use it in an unbalanced way within a > formatting code. Absolutely yes. See C[...] vs C{...} vs C[\]] I'm pointing out that the ROUTINE case is to need < and > in unbalanced ways. Hence we have names for them that to not involve the words "open", "close", "left" or "right". We could name "[", "fobit", but then people would automatically call "]" a "right-fobit" or a "close-fobit". We look at a piece of code or documentation that contains an un-balanced fobit and we get a little chill because it's WRONG somehow. THAT is the kind of balanced operator you want to tie your documentation to. > > > The most common use of them in Perl 5--method call/dereference--is > > > going away in Perl 6 > > > > Hmm, I remain unconvinced of that as the most common use, especially > > with the copious use of =>. Still, in my local source tree you're right, > > though by < a factor of 2. > > Are you looking at your entire source tree, or just the Pod in it? > The code in Pod--and especially the short snippets of code typically > included in a C<> construct--is very different from arbitrary Perl > code. I EXPLICITLY ignored POD. I don't have the find+perl that I used handy any more, but I was counting state every time I saw an "^=[hoib]" and decrementing state every time I saw an "^=cut" so that I only counted code... I probably caught some strange gunk after __END__ and __DATA__ tags, but not enough to throw the stats that far off. It was 23k vs. 44k. > > Perl 6 also adds new uses of E and E for pipelining, and further > > expands the usefulness of the => operator as a pair constructor. Rules > > also add new uses of these characters, but those are balanced, so > > improving POD with a real grammar specification would solve for that. > > I definitely support intelligently defining the way Pod handles angle > brackets which aren't part of a formatting code. I also think writing > a reference grammar would be an excellent idea. Already done, see my previous message. It's still brain-dead in some places, and I need to re-work it to correctly handle nested operations (e.g. B[I[...]]), but I'll have that soon. It will also, I've decided, parse POD. Just as Perl 6 parses Perl 5 by recognizing the first few statements, AJS Kwid will recognize "=head.*" as an indication that POD is being used, and parse it into KwidData internally so that the same tools could be used. I'm stopping once it works. I'm not looking to fork POD. If people don't like the proposal, once they can play around with it, then I'll drop it. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman <[EMAIL PROTECTED]> wrote: > > Specifically, I like the use of angle brackets in Pod. Angle brackets > > are simple, distinctive shapes; they remain wide in variable-width > > This is aesthetic preference. I could cite the reasons that I have an > aesthetic preference for the other syntax, but the reality is that angle > brackets aren't angle brackets; they are less-than (E) and greater- > than signs (E). We ignore this fact at our peril, Only in name. Years of HTML and Perl have trained me to treat these as bracketing constructs, and Perl 6 is set to increase that use. > and the hacks in > pod syntax (e.g. C<< < >>) to get around this are glaring anti- > huffmanisms. Whatever bracketing character we decide to use, there will always be occasions where we need to use it in an unbalanced way within a formatting code. (Though I do admit that angle brackets are more likely to be unbalanced than other characters.) The problem I have with square brackets specifically is that they get lost really easily, especially in variable-width fonts. Gmail, for example, displays e-mail in a sans-serif font, and virtually all such fonts have narrow square brackets. The square brackets in your examples were visually lost in the surrounding text--without spaces, square brackets are invisible. That's okay when you're subscripting, because your brain doesn't really need them to understand what's going on, but it's not when you're applying and reading formatting codes. Further, although Perl 6 is the time to make such a change, I'm not convinced the change is really necessary. We might be able to avoid a few uses of C<< >>, but is that a big enough win to change *yet another* aspect of Perl? Especially an aspect programmers can--and traditionally did--ignore? > > The most common use of them in Perl 5--method call/dereference--is > > going away in Perl 6 > > Hmm, I remain unconvinced of that as the most common use, especially > with the copious use of =>. Still, in my local source tree you're right, > though by < a factor of 2. Are you looking at your entire source tree, or just the Pod in it? The code in Pod--and especially the short snippets of code typically included in a C<> construct--is very different from arbitrary Perl code. > Perl 6 also adds new uses of E and E for pipelining, and further > expands the usefulness of the => operator as a pair constructor. Rules > also add new uses of these characters, but those are balanced, so > improving POD with a real grammar specification would solve for that. I definitely support intelligently defining the way Pod handles angle brackets which aren't part of a formatting code. I also think writing a reference grammar would be an excellent idea. > Thanks Brent, I'm not sure if you intended your mail as an endorsement, > but other than one sticking point, you and I appear to be on the same > page. Thank you for your message. I intended my e-mail to be an endorsement of Pod as it exists, with extensions rather than a redesign. I think you have mostly the right idea, but I really don't think switching to square brackets is necessary. By the way, I think I've seen a few people suggest some sort of syntax-switching mechanism for "Pod6". The day people have to think about what dialect of Pod they're using is the day Pod dies as a useful documentation language. -- 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: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote: > The interesting thing to me is that all 3 syntaxes map over the same > data model and thus are easily interchangable. The other interesting > thing is that all three could be supported without affecting the Perl5 > or Perl6 syntax proper. If any of the above was news to you, then I suggest you take another look at why POD (and more generally, any abstract markup language) exists. If any of the above were NOT true, it would be contrary to the entire point of an abstract, layout-neutral markup language. It is, however, contrary to the spirit of POD for you or me to continue much further down this road (see below). > Sam "mugwump" Vilain refers to each of these syntaxes as /Pod dialects/. > He is working on more formally defining the common model or "AST" that > these dialects map to. Why? Seriously, why on earth do you want to encourage the proliferation of variant markup languages?! There aren't enough? My effort here was to try to PREVENT the proliferation (e.g. by Kwid and POD butting heads and ending up in a stalemate). The only problem is that, presented with a compromise, the Kwid folks seem to be content to ADD it to the list of variants rather than, in fact, compromise and collapse the list. I'll continue only as far as is needed to propose this in full as an example parser / converter, and then I'm going to stop. My goal is not to proliferate the number of markups further, and I'd MUCH rather see Perl 6 rely on POD than fragment the SINGLE MOST IMPORTANT TASK in creating code to share with the world: documentation. If I'm left on a desert island with POD, then the only part I'll lament is the desert island. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 16:39, Juerd wrote: > Aaron Sherman skribis 2005-03-17 16:30 (-0500): > > > See PodTables in the Pugs wiki. > > Or see the archive of this list, where we hammered it out previously. > > Since when is anything in Perl 6, except its name, set in stone? > > PodTables is a more detailed and more consistent approach to a > suggestion I did long time ago. I think you're thinking of something else. I'm talking about Luke's proposal from this very list, back in Aug, which was a followup on Larry's comments about my proposal, and which I agreed was far better than what I had suggested in the first place. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: s/true/better name/
Brian Ingerson skribis 2005-03-17 11:57 (-0800): > 'Tis a pity nobody suggested `tis()`. That sounds more like a smart match on the topic: if tis 'foo' { ... } if $_ ~~ 'foo' { ... } 't => $_, is => ~~ 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?
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; } This keeps $_ unambiguosly the 'it', while 'this' is more specific. Think: it puts the lotion on the skin method blah { for ($.prisoners) { .put($lotion, $skin); # is the same as $_.put($lotion, $skin); } } It is not us, it is not self, it is not here, it is, err, just the default. For implies it in this case. Contrary: this puts the lotion on the skin self ~~ method cooperate ($self:) { # in class Prisoner # this method puts lotion on skin, haha $self.put($lotion, $skin); } We are discussing a certain thing, which is the invocant. It's not default. The default might be something else altogether. It's pretty obvious that in a method like this the invocant is the default, but what if it isn't? 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 {}. Lastly, what is wrong with $.method? -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me dodges cabbages like macalypse log N: neeyah! pgpqRpkMb5Me5.pgp Description: PGP signature
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman skribis 2005-03-17 16:30 (-0500): > > See PodTables in the Pugs wiki. > Or see the archive of this list, where we hammered it out previously. Since when is anything in Perl 6, except its name, set in stone? PodTables is a more detailed and more consistent approach to a suggestion I did long time ago. It also states what I found important when inventing the syntax: things to consider when inventing your own syntax for the same feature. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 09:54, Juerd wrote: > > > Pod needs incremental improvements--tables > > Oops, forgot that one. I'll add it tonight, when I get home from work. > > See PodTables in the Pugs wiki. Or see the archive of this list, where we hammered it out previously. YMMV. I'll have the second revision available sometime tonight, I think, hopefully with an AJS Kwid to KwidData to POD translator (lossy, but still mostly workable). -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: s/true/better name/
On Thu, Mar 17, 2005 at 14:09:26 -0700, Luke Palmer wrote: > Is wrong. If answer() decides that it should start returning a more > interesting value of true, then the test fails. I think the only name for this function, from which you can actually understand what it does, is bool(?:ean)? as a context enforcer. It's got the following properties: - well known and accepted semantic meaning - no associated action (it doesn't do anything) - relatives (scalar, list, hash) - it maps to '?', which is also the prefix to certain operations, thus unambiguating further As I see it 'so', 'whether', 'true', 'is', 'id', etc all have too much english cargo, or are not exactly what it does. The only one that I can see fitting here, as an action instead of a context disambiguation is 'istrue', which takes an expr, and returns a bool if expr is true. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me sneaks up from another MIME part: neeyah! pgpRod53H02RA.pgp Description: PGP signature
Re: s/true/better name/
Mark J. Reed writes: > Luke Palmer wrote: > > >Marcus Adair writes: > >> Additionally I question whether this is truly a case improving to the > >> point of least surprise? After all, I don't know a programmer who's > >> going to be surprised by what true means. There are still *some* things > >> you may have to learn in software dev 101 ;) > > > >The problem is this (common) one: > > > >if answer() == true { > ># do something > >} > > > >We want to give the programmer no good way to do that, because it's > >wrong. > > > > What do you mean "wrong"? It looks perfectly valid to me. It's > redundant, since answer() by itself would suffice as a condition with no > comparison, but does that make it wrong? It's wrong in the same way that: if (ref $obj eq 'MyClass') {...} Is wrong. If answer() decides that it should start returning a more interesting value of true, then the test fails. Luke
Re: s/true/better name/
On 17/03/05 04:40 +0800, Autrijus Tang wrote: > On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: > > whereas as a native English speaker would probably expect > > > > $x = whether($a or $b); > > > > So I'm thinking we'll just go back to "true", both for that reason, > > and because it does syntactically block the naughty meaning of true as > > a term (as long as we don't default true() to $_), as Luke reminded us. > > But "true()" reads weird, and it does not read like an unary (or list) > operator at all to me. As the bikeshedding is still going on, may I > suggest "aye()"? It is the same length as "not()", both are adverbs, > and is rare enough to not conflict with user-defined subs. 'Tis a pity nobody suggested `tis()`. Cheers, Brian
Re: s/true/better name/
John Macdonald wrote: A shotgun brainstorming of possible operator names: well, I didn't follow this thread very closely (and I don't know if it is "officially" closed :-) but I suddenly thought about "yes". what about: $x = not $a or $b; # vs $x = yes $a or $b; $yesno = yes any(@foo) == any(@bar); may not be gramatically correct English, but isn't it intuitive enough? cheers, Aldo
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: .method == $self.method or $_.method?
On Thu, 17 Mar 2005, Larry Wall wrote: : > o.frobme(...) : : How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>? : (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!) : : How 'bout a single underscore? _.frobme()?!? Thought about those in the night, but they don't strike me as visually distinct enough. They just look like someone stepped on the front of your expression. But then do 'c' and 'o'? They're too identifier-like IMHO to be psychologically associated with something 'special'. It kind of reminds me of some fortran code I saw (I don't know fortran) and I could hardly cope with those 'c'omments... (However I would be favourable to {one,two} letter(s) long builtin functions/operators, when they are frequently used (think huffmanization) and talking about language design in general. Michele -- Your right, I didn't think of that at all, but still, who's gonna go into the temp internet folder and create a cookie? At least not most users. Of course *most* users aren't going to do that. *Most* users aren't trying to hack your site! You don't program securely for *most* users - you program securely for the few users who *are* trying to be malevolent. - Paul Lalli in clpmisc, "Re: free source authentication script"
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: return of copies vs references
Larry Wall wrote: That's actually weirdly symmetrical with the notion that only subs can impose compile-time context on their arguments, while methods always have to assume list context because you have to generate the argument list before you can know which method you're going to dispatch to. Sorry if it's only me, but I don't understand what this means. I get, that at the call site of a sub, first of all the lexically closest sub can be determined at compile time. This means its signature is available and can be checked and imposed on the arguments---right so far? Single invocant methods are defined inside classes. Thus the knowledge of the compiler about their signature hinges on how well the type of the invocant can be determined. If the data is insufficient this is---depending on compile mode---either a static type error or dynamic lookup has to be compiled, with an optional warning. BTW, do method names have to be pre-declared? Or does the following just defer the existence check: sub blubb ( $obj ) { print $obj.somemethod( "FirstArg", "SecondArg" ); } What I want to ask is: is ".somemethod()" parsed purely syntactically? And is there a compiler mode where this is a type error like "type Any doesn't have .somemethod"? With multi subs and methods I guess a lexical definition is needed as for subs. But that doesn't mean that all dispatch targets are known already. Thus a dynamic built-up of the arglist and MMD is compiled. Right? A very nice feature of the compiler here were to perform implementation side checks when the complete program is loaded? This involves potential ambiguity and absence failures. BTW, how far down to pure byte code can Perl6 packages be compiled? Too much off the mark? -- TSa (Thomas Sandlaß)
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote: > I've been thinking about this in my sleep, and at the moment I think > I'd rather keep .foo meaning $_.foo, but break the automatic binding > of the invocant to $_. Instead of that, I'd like to see a really, > really short alias for $self. Suppose we pick "o" for that, short > for "object". Then we get self calls of the form: > > o.frobme(...) > > Now that has some interesting possibilities for variants. We could > have > > c.bless(...) Wow. With those single-casting-cost cantrips, the OO color will surely make a huge comeback in Perl6: The Gathering golfing tournaments! :) I like them. They look really really good to my eyes after the first 20 minutes or so of mental reconfiguration. For some strange psychological reasons, they make Pugs 6.2 so much more enjoyable to work on for me. :-) Thanks, /Autrijus/ pgpuLiyu2UtLd.pgp Description: PGP signature
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 17/03/05 00:49 -0500, Aaron Sherman wrote: > On Wed, 2005-03-16 at 13:42 -0800, Brian Ingerson wrote: > > Well, look over AJS Kwid, and see what you think. The bullet syntax you > give could work fine as a replacement for what I demonstrate, but I > think everything else is pretty much 1:1. Now it's just a matter of: do > you make it Wikiish or PODish? Aaron, I think AJS Kwid is fine if it fits your brain. It doesn't fit mine in much the same way that Kwid doesn't fit yours, in much the same way that Pod doesn't quite fit either of ours. The interesting thing to me is that all 3 syntaxes map over the same data model and thus are easily interchangable. The other interesting thing is that all three could be supported without affecting the Perl5 or Perl6 syntax proper. Sam "mugwump" Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or "AST" that these dialects map to. Given that, I am going to continue working on the Kwid dialect and developing the Kwid tools I have started. The ideas in AJS Kwid seem too different to incorporate without muddying the Kwid vision. I encourage you work on the AJS Kwid dialect too. I would guess that the Kwid tools I'm working on, when completed, could be easily adapted to AJS Kwid. Cheers, Brian PS All my work thus far is available in the pugs repository.
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: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 05:52:15PM +0100, Michele Dondi wrote: : On Thu, 17 Mar 2005, Larry Wall wrote: : : >really short alias for $self. Suppose we pick "o" for that, short : >for "object". Then we get self calls of the form: : > : > o.frobme(...) : : How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>? : (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!) : : How 'bout a single underscore? _.frobme()?!? Thought about those in the night, but they don't strike me as visually distinct enough. They just look like someone stepped on the front of your expression. Larry
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote: : Then we get self calls of the form: : : o.frobme(...) Sleep Brain would also like to point out that this lets you use o standalone when you want to pass the current object as an ordinary argument to some other class. Likewise for c, if we decide to have that too. Coffee Brain perks up and points out that for strategic psychological reasons it really likes the fact that, Huffmanly speaking, the dynamic class can be as short as "c" and the static class as long as $?CLASS. Larry
Re: .method == $self.method or $_.method?
On Thu, 17 Mar 2005, Larry Wall wrote: really short alias for $self. Suppose we pick "o" for that, short for "object". Then we get self calls of the form: o.frobme(...) How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>? (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!) How 'bout a single underscore? _.frobme()?!? Michele -- L'amava come si ama qualcosa che e' necessario alla vita. La odiava come si odia chi tradisce. - Laura Mancinelli, "Gli occhi dell'imperatore"
Re: .method == $self.method or $_.method?
I've been thinking about this in my sleep, and at the moment I think I'd rather keep .foo meaning $_.foo, but break the automatic binding of the invocant to $_. Instead of that, I'd like to see a really, really short alias for $self. Suppose we pick "o" for that, short for "object". Then we get self calls of the form: o.frobme(...) Now that has some interesting possibilities for variants. We could have c.bless(...) which would presumably give you the class of the invocant. Perhaps more interestingly, if o and c are functions, then you can provide arguments, with a default of 0. So the above could really be short for o(0).frobme(...) c(0).bless(...) Now, we also have this other problem that we're forcing people to name all the invocants for MMD methods, poor things. But with the above notation, the first invocant is o(0), the second invocant is o(1), etc. Not that we would encourage people to code this way, but it'd be nice to have a way of getting at the actual args in the same way we used to always get at them using @_. (Such a notation might well be useful in wrappers that don't know what they're being wrapped around, such as various debugging wrappers.) That's what Sleepy Brain says. But Coffee Brain despises Sleepy Brain. :-) Larry
Re: .method == $self.method or $_.method?
Garrett Goebel skribis 2005-03-17 8:37 (-0600): > Perhaps we should consider making $_ readonly in map and grep? That's one way to avoid clever tricks. Please let's not. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman skribis 2005-03-17 8:30 (-0500): > This is aesthetic preference. I could cite the reasons that I have an > aesthetic preference for the other syntax, but the reality is that angle > brackets aren't angle brackets; they are less-than (E) and greater- > than signs (E). We ignore this fact at our peril, and the hacks in > pod syntax (e.g. C<< < >>) to get around this are glaring anti- > huffmanisms. Other than awareness, this really doesn't have a point to it. In ASCII, ' was meant as an apostrophe, but we use it as a quote. Yen was never meant to have anything to do with zipping. Guillemets originally had nothing to do with parallelization. The hacks for square brackets are exactly the same. Think of how [EMAIL PROTECTED] would be parsed without nesting. And if you say nesting fixes all, then consider C["]"] as a counter-example. Are you willing to parse code in a "simple" documentation format? > > Pod needs incremental improvements--tables > Oops, forgot that one. I'll add it tonight, when I get home from work. See PodTables in the Pugs wiki. > > Pod does *not* need to be ripped out and replaced with something > > very different, > yes, yes, yes! Agreed. > > especially something that involves adding "line noise" to documents > > intended for human consumption. > yes, yes, yes! Agreed, though I like *bold*, /italic/, _underline_ and `code` very much. I'd like an option to enable it. 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?
Autrijus Tang wrote: > > Luke Palmer wrote: > > > > And it would be a shame to disallow the use of $_ in map. > > Err, wait, I don't think we are discussing whether $_ is to > be outlawed in map {}. Perhaps we should consider making $_ readonly in map and grep? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 15:09 -0800, David Storrs wrote: > C[$x[0] > $y] # hmmm...parser ok with that? > C[$x[0] > $] # hmmm...error, but what was intended: $y] or $]]? In the former case, it's fine. See the grammar I sent last night. In the latter case, you would get balanced-[] matching, and given how hard it is for PERL to do the right thing, there, I think it's fair to fall back on "only perl can parse perl", and just do what the eye suggests is correct. Remember that POD (and thus Kwid) are not intended to be Perl-specific, just Perl-friendly. You can always: C{$x[0] > $]} If you need unbalanced []s That said, I'd be ok with something like Z[name|text] and Z{name|...} for doing external grammars, but it'd still have to live inside one of the balanced operators correctly. Please also note that as a side-effect of using extract_bracketed in my grammar, C[\]] works. This introduces escaping which may or may not be good. It was not a conscious decision, just a side-effect. I PREFER: C{]} Which also works. > C<< $x[0] > $y >> # parser's ok (so's the human) > C<< $x[0] > $ >> # oh, obviously $y was intended By the same token: C[ $x[0] > $y ] # Parser's ok C[ $x[0] > $ ] # Parser's ok... human might care > > the massive savings in terms of taking > > advantage of the legions of people who are learning Wiki syntax these > > days. Making POD *more* Wiki-like without sacrificing useful features of > > POD is invaluable in terms of tech writers and other > > non-Perl-programmers writing useful docs in POD! > > Here's the real crux of your argument, and the real crux of my problem > with this approach. I don't like Wiki syntax; to me, it seems > arbitrary and non-unified. Agreed. > I use Wikis, I run one, I recognize their usefulness. I just don't like > them. Fair enough. I don't like them either, for many reasons. I like them in equal measure. It's a bit like sendmail ;-) > Here are some of the formatting rules for TWiki (the Wiki version I > use): > > 1) Elements of a bulleted list must match /^ {3}\* / > 2) Elements of a numbered list must match /^ {3}1 / > 3) Headings must match /^*\++/. Number of +s determines level > 4) *bold* > 5) /italic/ > 6) =fixed font= > 7) put text to be rendered as-is here > > What is the organizing priciple? What similarities do they have? Yes, yes, yes. I agree. See AJS Kwid. Please. > Contrast this to POD (I'm not trying for point-to-point equivalence): > > 1) All formatting starts with = in the first column. Add ONE new item to that list: * > 2) Every POD command must have a blank line above and below it. Why do you want TWO ways of determining commands? I can see requiring a blank line above OR below, just for readability, but not both. I'm a POD lover. I've used POD since the mid-90s and I'm THRILLED with it. However, there's that nagging problem with having to type: \n\n=head1 Foo\n\n=head2 Introduction\n\nTopics:\n\n=over 5\n \n=item *\n\nFoo vs. Bar\n\n=item *\n\nC<\n>\n AJS Kwid: \n= Foo\n\n== Introduction\n\nTopics:\n* Foo vs Bar\n* C[\n]\n > 3) A list of any type starts with =over N and finishes with =back Again, you're asking for a second way to determine what point 1 already told you. If this were code, I might buy that, but it's documentation. We like documentation. We want to encourage documentation and =over ain't the way to encourage nothing ;-) If you prefer a requirement for a leading blank line for readability, I could see that, and we could talk about it. I do see the value in "=begin list/=end list", but only in cases like this: =begin list * a * b =end list =begin list * Apples * Grapes =end list Where you wish to make it clear that you are ending the first list. Which do you find more readable: =over 5 =item C<--help> Help is given =item C<--verbose> Verbosity is given =item C<--debug> Debugging is done =back vs: =begin list *= C[--help] Help is given *= C[--verbose] Verbosity is given *= C[--debug] Debugging is done =end list Replace *= with + and =begin list with .list and =end list with .list. for the original Kwid proposal. > 4) List items are denoted with =item X where X is either * (bullets), > an int (numbered), or word/phrase. Use only one type per list. > 5) Headings are denoted by =head1, =head2, etc > 6) Formatting effects are done with X where X is one of: > B (bold), C (code), I (italics). You may also use > X<< text >> or X<<< text >>> if you have < or > in your text. > 7) Text that is indented will be rendered as-is in fixed width font. There's a 1:1 mapping with all of the above except for the <> vs []/{} and "=head1 heading" vs "= heading", which are simply syntactic transformation
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 02:17 -0800, Brent 'Dax' Royal-Gordon wrote: > David Storrs <[EMAIL PROTECTED]> wrote: > > Aside from links, that's pretty much the entire perlpodtut boiled down > > into 7 bullets; a little experimentation to get the hang of it and it > > all holds together nicely, easy to remember. > > Yes, yes, yes. Pod is one of the things Perl 5 did almost exactly right. Absolutely, and that's why I'd like to see more POD details preserved. > It's simple, intuitive, and stays out of your way. It gives you most of > the formatting primitives you actually *need*, and nicely balances the > need for easy-to-remember and easy-to-type formatting codes with the > need to avoid using them on accident. It's a very clean, > low-punctuation format, which makes it visually distinctive from the > surrounding code. This is the spirit in which I've absorbed some of Kwid into my proposal only where it supports those goals. I've removed some extra formatting characters because I thought that they added too many chances for overlap with real documentation. I've also searched my local PODs to see where AJS Kwid would overlap POD and cause problems (6.4% of my local PODs, for example, start some lines with "*", which would be a minor, but notable problem, but 13.1% start a line with "-" which is a larger problem, thus my "*1" which could easily be "*-" if we prefer that). > Specifically, I like the use of angle brackets in Pod. Angle brackets > are simple, distinctive shapes; they remain wide in variable-width This is aesthetic preference. I could cite the reasons that I have an aesthetic preference for the other syntax, but the reality is that angle brackets aren't angle brackets; they are less-than (E) and greater- than signs (E). We ignore this fact at our peril, and the hacks in pod syntax (e.g. C<< < >>) to get around this are glaring anti- huffmanisms. > The most common use of them in Perl 5--method call/dereference--is > going away in Perl 6 Hmm, I remain unconvinced of that as the most common use, especially with the copious use of =>. Still, in my local source tree you're right, though by < a factor of 2. Perl 6 also adds new uses of E and E for pipelining, and further expands the usefulness of the => operator as a pair constructor. Rules also add new uses of these characters, but those are balanced, so improving POD with a real grammar specification would solve for that. > Pod needs incremental improvements--tables Oops, forgot that one. I'll add it tonight, when I get home from work. > (maybe) footnotes Good point, and I'd add that to X[...] rather than introducing something new, personally. > simpler links, tweaks to =begin/=end, etc. I think everything you list above is EXACTLY AJS Kwid, with one exception, which is the dreaded paradigm shift of using [] instead of <> Much as it may be an EMOTIONAL sticking point, it's a very minor thing. If we can agree on everything else, and I suspect we can, then let's come back to that. > Pod does *not* need to be ripped > out and replaced with something very different, yes, yes, yes! > especially something > that involves adding "line noise" to documents intended for human > consumption. yes, yes, yes! Thanks Brent, I'm not sure if you intended your mail as an endorsement, but other than one sticking point, you and I appear to be on the same page. Thank you for your message.
Re: retiring wantarray?
BTW, i should mention that given want { } in s06 is nice for replacing the simple kind of wantarray usage cases, but not what this message brought up. In short, i did read it, so don't send me links ;-) -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgpH6GwU4Nyq1.pgp Description: PGP signature
retiring wantarray?
Hola... This message is not about removing wantarray, but finding a better solution for a typical but annoying usage-idiom. sub value_added { # not really a wrapper my $result = original(@args); ... return $result; } Is a typically broken subroutine in perl 5, unless original() never returns lists. Usually people use wantarray, or if they're being even more politically correct, they use Want, but this is an annoying overhead. What are perl6's solutions towards making this easier? I tend to design around this, normally returning lists, unless the sub name implies singularity. Here are some ideas: # i don't like this one, it complicates things sub value_added { original(@args); # return is collected here } after { # but just before leaving, this is done: ... # how do we access the return? what can you do here? } # this seems nicer, but very ad-hoc sub value_added { return_later(original(@argS); ... # with no explicit return or return later, the return_later is # returned, instead of the last expression's result } # this is my favourite sub value_added { $return is context_sensitive = original(@args); # hides wantarray magic ... # you can ask $return what it's context is # but it pretends to be just a normal value anyway (array ref in # list, etc). How do you modify it, without breaking it? # implicit strong type? $return; # magically unwraps } # or in perl5, maybe it could be done like: sub value_added { my $return = Returner::Smart->new(sub { original(@args) }); # Returner is an object that does Want based lookups ... $returner->return; # could this do lvalue crap? } -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me does a karate-chop-flip: neeyah!! pgpi8tV5KTNDl.pgp Description: PGP signature
Re: return of copies vs references
Thank you, Luke and Larry, for your replies. They did help. For now, I will use the syntax $obj.:bar[] and $obj.:baz{} in the get_bar|baz() accessor methods to get copies returned; if the rules change again, I'll update later. I noticed that the example seemed incomplete, saying only what would happen with the above in list context, and not saying what would happen in scalar context. I would like a way of specifying that the copy always happens regardless of the caller's context. This doesn't have to be a language 'default', and I'm fine if its a little more verbose, just as long as its consistent and unambiguous. return $self.:foo # in any context return $self.:bar[];# in list context return $self.:baz{};# in list context return $:foo; # in any context return @:bar; # in any context return %:baz; # in any context Eg, something that is like lines 5 and 6, but lets me explicitly use 'self'. -- Darren Duncan
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
David Storrs <[EMAIL PROTECTED]> wrote: > Aside from links, that's pretty much the entire perlpodtut boiled down > into 7 bullets; a little experimentation to get the hang of it and it > all holds together nicely, easy to remember. Yes, yes, yes. Pod is one of the things Perl 5 did almost exactly right. It's simple, intuitive, and stays out of your way. It gives you most of the formatting primitives you actually *need*, and nicely balances the need for easy-to-remember and easy-to-type formatting codes with the need to avoid using them on accident. It's a very clean, low-punctuation format, which makes it visually distinctive from the surrounding code. Specifically, I like the use of angle brackets in Pod. Angle brackets are simple, distinctive shapes; they remain wide in variable-width fonts; they're associated with formatting codes in my (HTML-influenced) mind. The most common use of them in Perl 5--method call/dereference--is going away in Perl 6, which makes them even more usable. (I never have a problem correctly marking up C<< $foo > $bar >>, but occasionally I carelessly type C<$foo->bar>.) Pod needs incremental improvements--tables, (maybe) footnotes, simpler links, tweaks to =begin/=end, etc. Pod does *not* need to be ripped out and replaced with something very different, especially something that involves adding "line noise" to documents intended for human consumption. In my mind at least, Pod has five goals: 1. Simple. 2. Adequate. 3. Easy to write. 4. Easy to convert. 5. Readable without a formatter. #5 may be last on the list, but it's not least. -- 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
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: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote: > The only minor thing I > can see would be that you will end up with a slight asymmetry question > of "if we use $:attribute for a private attribute, do we call :method > for a private method?" That occurs no matter if .method means $self.method or $_.method. Anyhow, I don't see why not. :)
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 02:21:09AM -0700, Luke Palmer wrote: > In particular, the fact that `map` rebinds $_. Consider: > > method data () { > map { .process($_) } @.array; > } > > Is that calling `$_.process($_)` for each `$_` in [EMAIL PROTECTED], or is it > calling `$self.process($_)`? It must be the former, which, given the > context, is probably not what was intended (despite the terrible (but > unfortunately, typical) naming, we can still tell what the programmer > was thinking). `.process` means something else everywhere else in the > method, and Perl goes to great lengths to keep it that way, but in this > case it's different. > > And it would be a shame to disallow the use of $_ in map. 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. Thanks, /Autrijus/ pgpgqlszdlpCR.pgp Description: PGP signature
Re: return of copies vs references
On Thu, Mar 17, 2005 at 02:06:46AM -0700, Luke Palmer wrote: : I'll just point out, the rest of this message, with all the autocopy : complexity (according to /some/ people), uses this assumption. It all : happily goes away if $self.:bar returns a list if @:bar is declared. : And I can't, off hand, see any other problems with it. Maybe I'm just : blind, though. Yeah, that part's negotiable. But it will seem a little strange if we push it so far that private accessors default to protecting your own data from you, which it would if we forced the autocopy on private accessors in scalar context. I think private accessors will have to be distinguished from public accessors somehow. With forced ref return on private accessors we could be more general in how we specify autocopy on all return statements, but it could be made to work the other way too, in which case we say that only private accessors pay attention to context. And maybe that just falls out of the fact that private accessors are really just subs in disguise. So maybe the distinction is that real methods always return lists, and only subs (and sublike private methods) pay attention to the context in which they're called. That's actually weirdly symmetrical with the notion that only subs can impose compile-time context on their arguments, while methods always have to assume list context because you have to generate the argument list before you can know which method you're going to dispatch to. So I could buy it either way. Opinions? Larry
Re: .method == $self.method or $_.method?
Larry Wall writes: > In that case we'd have to say that "given" and "for" always require > "-> $x" inside methods, and that $x is never automatically aliased to > $_. But there are other ramifications with switch statements and > exception handlers I have to think through, In particular, the fact that `map` rebinds $_. Consider: method data () { map { .process($_) } @.array; } Is that calling `$_.process($_)` for each `$_` in [EMAIL PROTECTED], or is it calling `$self.process($_)`? It must be the former, which, given the context, is probably not what was intended (despite the terrible (but unfortunately, typical) naming, we can still tell what the programmer was thinking). `.process` means something else everywhere else in the method, and Perl goes to great lengths to keep it that way, but in this case it's different. And it would be a shame to disallow the use of $_ in map. Disallowing one of the most beautiful areas of Perl, topicalization, in methods would be irritating at best. "Oh, so I can only program in a crappy subset of Perl because I'm in a method?" I don't know about the other programmers here, but just about all my code is in methods. Actually, scanning over my most recent module, *all* my code is in methods, except for the tests. Luke
Re: Symbol table lookup and hash
On Thu, Mar 17, 2005 at 10:33:42AM +0200, Gaal Yahas wrote: : I'm looking to understand symbol tables and the symtable hash better. : : What's the motivation for ::() syntax? Is it mainly for binding aliases? It's for explicit symbolic reference. The ${...} syntax is now entirely reserved for hard references only. : How would $::("MY::bar") behave when my $bar has not been declared? Would be undefined as an rvalue, and either legal or illegal as an lvalue depending on whether the lexical scope in question is still being compiled. (Modifications to a lexical symbol table are banned after the lexical scope is done compiling.) : (Similarly, what happens with an undeclared $::("Foo::bar") ?) Almost exactly the same thing as Perl 5 would do with ${"Foo::Bar"}, except there might be a search outward for all scopes containing a Foo subpackage, which ends up finding the global Foo package by default. In Perl 6 you use a "*" when you absolutely want to start looking at the root, much like Unix filenames starting with '/'. : If I do the analogous thing with the symbol table hash, (how) is the : behavior any different? What can you express with ::() but not with the : symtable hash? The only difference is that ::() will parse its argument for "::" and potentially traverse multiple nested symbol tables, whereas accessing the symbol table hash directly will assume you're only giving the exact key for the hash and not look for "::". Also, the sigils on ::() are outside ("@::($foo)"), whereas sigils in the symbol table are part of the key name ("%::{'@' . $foo}"). But once you get to the container object in question, it's the same either way. Larry
Re: return of copies vs references
Larry Wall writes: > Perl 5 always makes a copy of return values, but that just turns > out to not matter for references, since a copy of a reference is as > good as the original reference. Perl 5 also propagates scalar/list > context into subs. For $:foo it doesn't matter--it always behaves > as a scalar value even in list context. In list context, @:bar and > %:baz should probably return copies of their values much like they > do in Perl 5, (or more likely, some kind of lazy COW reference that > can lazily interpolate into the surrounding lazy list context). > Whether $self.:bar and $self.:baz should behave the same is an > interesting question. They *look* scalar, so maybe they should imply > reference return, and you'd have to say > > return $self.:bar[]; > return $self.:baz{}; I'll just point out, the rest of this message, with all the autocopy complexity (according to /some/ people), uses this assumption. It all happily goes away if $self.:bar returns a list if @:bar is declared. And I can't, off hand, see any other problems with it. Maybe I'm just blind, though. Luke > to get the equivalent of > > return @:bar; > return %:baz; > > But bare > > return $self.:bar; > return $self.:baz; > > would be equivalent to: > > return \@:bar; > return \%:baz; > > But I could argue it the other way too. > > : For each, will the calling code be able to > : modify $obj's attributes by modifying the return values, or not? > > The caller can modify the value only if an explicit ref is returned (or > the accessor is marked "rw"). > > Where we seem to differ from Perl 5 is that in scalar context, a bare > array or hash automatically enreferences itself rather than returning > some kind of size. So in scalar context, it would seem that > > return @:bar; > return %:baz; > > and > > return $self.:bar; > return $self.:baz; > > are equivalent to: > > return \@:bar; > return \%:baz; > > (Again, $:foo is never a problem unless it's already a reference.) > > So the issue is whether this interpretation will encourage people to > accidentally > return references to things they didn't want to give write access to. On the > other hand, making the private methods context sensitive doesn't actually > seem to fix this particular problem, but just pushes it down one level into > the implicit accessor. Maybe we need to work something up where > references returned from read-only accessors are always COW references. > If we assume that [...] is lazy when it can be, then that would be saying that > scalar context forces > > return @:bar; > > to mean > > return [@:bar]; > > and you'd have to write an explicit > > return \@:bar; > > to get around that. But that seems kind of hacky and special-casey. > > On the other hand, there are going to be strong cultural forces > discouraging people from writing such accessors in the first place, > so maybe we just go ahead and let people return hard refs in scalar > context on the assumption they know what they're doing. I suspect > that most actual accessors to arrays and hashes will just look like > ordinary getter and setter methods with extra args for subscripts, or > will return an explicit proxy if they want to behave like an lvalue. > And in either of those cases, you don't try to return the entire > array or hash. So maybe we should settle for the clean but slightly > dangerous semantics here. > > Except that we've defined default read-only accessors that would, > under the "clean" rules, give people automatic access to arrays and > hashes if called in scalar context. So I think we really only have > three options here for the public accessors: > > Don't generate autogenerate accessors at all for arrays and hashes. > Generate array and hash accessors that refuse to work in scalar context. > Generate array and hash accessors that autocopy in scalar context. > > Of those three, the last seems the most friendly. > > : Going further, what is the exact syntax for each type of attribute to > : specify whether a copy or a reference is returned? > : > : In Perl 5, with the latter two, the difference was a "return $bar" vs > : "return [EMAIL PROTECTED]" for reference vs copy. I would like that Perl 6 > : is also at least as clearly disambiguated. > > If we go "dwimmy" rather than "clean", and assume private array and > hash accessors always return refs, then these return refs from public > accessors: > > return \$self.:foo; # in any context > return $self.:bar;# in any context > return $self.:baz;# in any context > return \$:foo;# in any context > return \@:bar;# in any context > return \%:baz;# in any context > > and these return copies: > > return $self.:foo # in any context > return $self.:bar[]; # in list context > return $self.:baz{};
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote: : Personally, .foo meaning $self.foo seems more consistent to my mind, and : I'd happily standardise on implicit invocants. I'm thinking about it. There are definitely things to be said for both sides, and maybe we can come up with a solution that's better than what we have. And after all, I originally came up with the .foo notation precisely for the purpose of leaving out $self and still having it self-documenting, as it were. I have a vague feeling that the real linguistic thing going on here is that you shouldn't change the meaning of "it" within a method, so one possible solution would just be to prohibit any rebinding of $_ to anything other than the current object. In that case we'd have to say that "given" and "for" always require "-> $x" inside methods, and that $x is never automatically aliased to $_. But there are other ramifications with switch statements and exception handlers I have to think through, and I'm a slow thinker, and unfortunately I'm having to moonlight at a real job to put bread on the table and pay back all the money I've borrowed over the last several years in order to devote myself to Perl 6--so you'll all just have to be patient with me. Well, you don't have to, but it'd be nice... : The only minor thing I : can see would be that you will end up with a slight asymmetry question : of "if we use $:attribute for a private attribute, do we call :method : for a private method?" I think those would still be .:method, and we just live with the asymmetry, unless we decide there's sufficient declarational power in the class that we can always distinguish :method from :pairkey, which there might be. But even if there is, most uses of private methods will probably be from within trusted classes, and access to my own attributes through $:foo instead. Plus .:method doesn't require people to remember what's been declared to decide if it's a pair or a private method. Larry
Symbol table lookup and hash
I'm looking to understand symbol tables and the symtable hash better. What's the motivation for ::() syntax? Is it mainly for binding aliases? How would $::("MY::bar") behave when my $bar has not been declared? (Similarly, what happens with an undeclared $::("Foo::bar") ?) If I do the analogous thing with the symbol table hash, (how) is the behavior any different? What can you express with ::() but not with the symtable hash? -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
Re: Referencing a caller's slurpy array.
On Wed, Mar 16, 2005 at 11:49:12PM -0600, Rod Adams wrote: : I haven't gotten a solid answer on when and how Perl will autogenerate : methods from subs. In general I don't think of it as autogeneration at all, but as failover to a different dispatcher. I can't think of a case where an ordinary sub implies an ordinary method or an ordinary method implies an ordinary sub. Multi subs can live in both worlds simultaneously when they're defined within a class, but in that case it's a single definition that is visible to both dispatchers. There may end up being some hanky-panky of an autogeneration nature going on to optimize the more common failover cases, and we've cut ourselves a little slack in how we handle single argument functions and/or argumentless methods, but by and large we should just be able to get away with a single MMD definition for most purposes, and separate definitions where the valence actually changes. : For instance, would : : @array.grep(/foo/); : : generate a call to the list op C above, or do I need to be : defining another form of C that's more agreeable to : autogeneration? If so, what makes a sub more agreeable to auto method : generation? Well, grep is one of those cases where you really need two different definitions because you have conflicting invocants. If within the Array class you write a multi sub like this: multi sub grep (Array @array, Selector $for) {...} then it can be called either as @array.grep(/foo/) or grep(@array,/foo/), but never as grep(/foo/,@array). At least, not unless we install some mechanism like active/passive voice into Perl, in which case the passive voice could be autogenerated from the active voice, albeit with a modified verb. But for now I think two definitions are appropriate, with some thought about bifurcating the verb into "do to" and "done by" variants if there's likely to be MMD confusion. The .grep variant should probably just be an ordinary method rather than a "squinting" multi method to avoid confusion with the standard listop form. If we find ourselves with double declarations all over the place, then maybe we can look for some autogeneration relief. Larry
Re: s/true/better name/
Larry Wall wrote: $x = whether $a or $b; $x = not $a or $b; would actually be parsed as $x = whether($a) or $b; $x = not($a) or $b; whereas as a native English speaker would probably expect $x = whether($a or $b); Reading this makes me wanting: $x = either $a or $b; $y = neither $a nor $b; And of course binary \ and \\ for the latter :) So I'm thinking we'll just go back to "true", both for that reason, and because it does syntactically block the naughty meaning of true as a term (as long as we don't default true() to $_), as Luke reminded us. What is so bad of having a proper type bool? I mean one that gives a type error or warning for 'answer() == true' if &answer returns Int because bool { not .does Comparable }? This type would be rather lightweight, compile time only with representation bit. The .bit property would then actually become a call of 'as bool'. Regards, -- TSa (Thomas Sandlaß)
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote: > I should add that Darren and I, who both have similar tendencies towards > larger scale coding where consistency is far preferred to compactness, > both ended up concluding that our style policies will be to _always_ use > explicit invocants (except of course for one liners). I thought your conclusion was you'd only use an explicit invocant if .foo meant $_.foo. And to drop it if .foo means $self.foo as there's no ambiguity.
Re: .method == $self.method or $_.method?
That is correct. It probably should have read "...our style policies will be to _always_ use explicit invocants, if .foo ends up meaning $_.foo in the final release (as it does now)". (of course, I suspect Darren will keep using them anyways, but then he likes to be even more explicit than I am) :) Personally, .foo meaning $self.foo seems more consistent to my mind, and I'd happily standardise on implicit invocants. The only minor thing I can see would be that you will end up with a slight asymmetry question of "if we use $:attribute for a private attribute, do we call :method for a private method?" Adam K Michael G Schwern wrote: On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote: I should add that Darren and I, who both have similar tendencies towards larger scale coding where consistency is far preferred to compactness, both ended up concluding that our style policies will be to _always_ use explicit invocants (except of course for one liners). I thought your conclusion was you'd only use an explicit invocant if .foo meant $_.foo. And to drop it if .foo means $self.foo as there's no ambiguity.
Re: .method == $self.method or $_.method?
I should add that Darren and I, who both have similar tendencies towards larger scale coding where consistency is far preferred to compactness, both ended up concluding that our style policies will be to _always_ use explicit invocants (except of course for one liners). In the case of the Algorithm::Dependency module that is being ported over as a test, and given that larger chunks of code have a tendency towards named iterators in loops anyways, and we've ended up with the only sane way to be the wordiest of the various ways-to-do-it. Just for the record, I for one would have much preferred to have .foo be the same as $.foo and @.foo and %.foo and refer to the invocant method, at the cost of using C< map { $_.foo } >. To describe it in emotional terms, the current situation feels "backwards and inside out". Adam K Michael G Schwern wrote: There's a discussion going on #perl6/irc.freenode.org right now wondering about what .method means. We'd all assumed it meant $self.method (where $self is always the method invocant) but then had a look at Synopsis 12 which states Dot notation can omit the invocant if it's in $_: .doit(1,2,3) This seems to cripple .method's usefulness by coupling it to $_ which can change often. Now in order to be safe for anything but trivial methods you're back to writing out $self all over the place, something that Perl 6 was supposed to fix about Perl 5. It has also been pointed out that .foo, $.foo, @.foo and %.foo are all (intentionally) similar and all but one operates on the invocant. Only .foo operates on $_. This seems like a newbie trap waiting to happen. MOST of the time .foo will work like $self.foo but every once in a while they'll get caught in a gotcha. Thoughts?
.method == $self.method or $_.method?
There's a discussion going on #perl6/irc.freenode.org right now wondering about what .method means. We'd all assumed it meant $self.method (where $self is always the method invocant) but then had a look at Synopsis 12 which states Dot notation can omit the invocant if it's in $_: .doit(1,2,3) This seems to cripple .method's usefulness by coupling it to $_ which can change often. Now in order to be safe for anything but trivial methods you're back to writing out $self all over the place, something that Perl 6 was supposed to fix about Perl 5. It has also been pointed out that .foo, $.foo, @.foo and %.foo are all (intentionally) similar and all but one operates on the invocant. Only .foo operates on $_. This seems like a newbie trap waiting to happen. MOST of the time .foo will work like $self.foo but every once in a while they'll get caught in a gotcha. Thoughts?