quotemeta
I vote for axing C in favor of C and C. -- Rod Adams
New S29 draft up
I just posted a fresh copy of S29 to: http://www.rodadams.net/Perl/S29.pod http://www.rodadams.net/Perl/S29.html New: All defined functions have been restructured into packages. Perl6::Arrays, Perl6::Lists, and Perl6::Hashes are (mostly) written. Some Math::Basic and Math::Trig functions added. :'s have been added into signatures where they belong. various other clean ups. Comments welcome. -- Rod Adams
Re: quotemeta
On Wed 16 Mar, Rod Adams wrote: > I vote for axing C in favor of C and C. > Given A05 states that bare scalars match literally, quotemeta is (almost?) obsolete. It can certainly be downgraded. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: s/true/better name/
Isn't saying "false doesn't exist" like saying, "dark doesn't exist"? Why have a word for that? I'm really afraid I'm missing something obvious here, but I'm worried that neither "whether" nor "indeed" work very well in many contexts. It seems to me that testing trueness exists in so many contexts that it's going to be hard to find an English word that fits all the important ones. 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 ;) Marcus
perl6-language@perl.org
Just a quick question. In Pugs t/op/arith.t we have: sub tryeq_sloppy ($lhs, $rhs, ?$todo1 = '') { ... ok($lhs==$rhs,$ todo); ... } But it breaks the $?CALLER based error reporting, because it introduces another layer of caller. In Perl5, I'd do this: { local @_ = ($lhs == $rhs, $todo); goto &ok; } Does that form still work with Perl 6? Or should I use this? { local &_ := &ok; call($lhs == $rhs, $todo); } However, I did not see A/E/S06 specifying that call() will assume the &goto semantic of erasing itself from the caller chain, so I hesitate to implement it that way. Is using wrap/call the correct choice here, or is there another way to do it that I missed? Thanks, /Autrijus/ pgpU4SEdazzFT.pgp Description: PGP signature
perl6-language@perl.org
On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote: > Does that form still work with Perl 6? Or should I use this? > > { local &_ := &ok; call($lhs == $rhs, $todo); } s/local/my/ of course. :-) Thanks, /Autrijus/ pgpGy03aIypYS.pgp Description: PGP signature
Q: index("Hello", "", 999)
What should index("Hello", "", 999) return in perl6? In perl5 that returns 5, but IMHO -1 would be right result. -- Markus Laire
Re: Q: index("Hello", "", 999)
On Wed, 2005-03-16 at 10:31, Markus Laire wrote: > What should index("Hello", "", 999) return in perl6? > > In perl5 that returns 5, but IMHO -1 would be right result. Urk... exception? Seriously, if you give index a position that is off the end of the string, your options should be: a. Extend the string b. Fail silently c. Throw an exception a. is kind of non-Perlish. b. is Perl 5ish, but I'm not convinced it's the right solution in all cases. In this case, specifically, I think it should be c. (perhaps with some "use nonfatal" that causes library functions to fail more gracefully). That said, the current Perl 5 behavior is very broken. You should never return 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 Tue, 2005-03-15 at 13:48, Brian Ingerson wrote: > Aaron, > > Upon reading this, it is unclear to me whether you have read about the > Kwid format or you are simply guessing that Kwid is the same syntax > used by Kwiki. I read the Kwid documentation from the Pugs distribution in depth. To create Kwid I carefully studied the POD information model (the semantic tree that POD parses to). Kwid uses the exact same info model. This means that switching between the two without loss of information is possible. I noted that in my original message. This makes the Kwid experiment much less risky Risk was not my concern. My concern was a Wiki-like model which is inconsistent with many of the goals of POD. POD is intended to be PLAIN OLD documentation. Kwid breaks this model of simplicity by introducing unique boundary characters for many types of operations, and by making the overall presentation more complex. While I appreciate several features of Kwid, I feel that it should not replace POD without first adopting a POD-like simplicity. Some people have argued that Kwid is only a syntactic change to Pod. I would argue that they are correct. They are demonstrably wrong. You cannot Parse Kwid correctly by changing the syntax of a POD parser. For example, the behavior of * foo bar Is totally dependent on what context it is enclosed in (.list or top-level). This cannot be emulated with simple syntactic changes to a POD parser. Interestingly, this is one of the main benefits of Kwid, IMHO. Re-read what I wrote and think about it. I think you'll find that it avoids some of the major pitfalls of old-POD and incorporates all of the useful features of Kwid while maintaining a simplicity that is as elegant as POD's. POD 1:1 mappings: POD My Kwid Proposal x<...> x[...] or x{...} (where x is C, B, I, X, L, etc) =item * * =item foo *= foo =item n *1 =for someformat =for someformat =over n =begin list The one obvious thing to POD users is the replacement of <> with [] or {}. Why is this? Because < and > are used in un-balanced ways in a large number of situations, so they should not be the primary bracketing constructs. Also because the visual cue to many users of POD is that it's SGML-like, and that way lies danger, since POD's <>-bracketed constructs are not intended to be balanced. Also, there should be a "=begin block" which in HTML would be , and in POD would be "=over n". Kwid 1:1 mappings: KwidMy Kwid Proposal * * .list =begin list ... =end list .someformat =begin someformat ... =end someformat .comment=begin comment ... =end comment [generic] [generic] Extensions I proposed: =begin x,y,zSection used only in the given formats =begin !x,y,z Section NOT used in the given formats As you can see, what I proposed IS a simple syntactic transformation of Kwid. -- 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 Wed, Mar 16, 2005 at 12:00:28PM -0500, Aaron Sherman wrote: > > The one obvious thing to POD users is the replacement of <> with [] or > {}. Why is this? Because < and > are used in un-balanced ways in a large > number of situations, so they should not be the primary bracketing > constructs. Actually, I quite like <> as the bracketing characters. They are visually distinctive, they connect well with their adjacent C/X/L/etc without visually merging into it (compare L with L[foo]), and in the circumstance that you want to bracket an unbalanced bracket, you just double (triple, whatever) up and add some space: C<< $x > $y >> Looks pretty clear to me. --Dks
Re: Q: index("Hello", "", 999)
On Wed, Mar 16, 2005 at 05:31:17PM +0200, Markus Laire wrote: : What should index("Hello", "", 999) return in perl6? : : In perl5 that returns 5, but IMHO -1 would be right result. Well, neither of those is the right result, since index is probably not going to be returning integers in Perl 6, but string positions which might have different integer values depending on whether you look at them as bytes, codepoints, graphemes, etc. And the string position value will be true for valid string positions and false/undef otherwise. When you call index, it's going to assume that 999 is to be converted to a string position under the current Unicode pragma, which turns out to be undefined on the string in question, so your call above probably either warns or throws an exception because you tried to use an undefined value to do something defined. Larry
Re: quotemeta
On Wed, Mar 16, 2005 at 10:17:33AM +, Richard Proctor wrote: : On Wed 16 Mar, Rod Adams wrote: : > I vote for axing C in favor of C and C. : > : : Given A05 states that bare scalars match literally, quotemeta is (almost?) : obsolete. It can certainly be downgraded. Except that q:meta would be an upgrade in terms of specialness, and besides, it's inside out from what you want, which is to quote a particular argument to a string interpolation, not the entire interpolation. It just wants to be a miscellaneous function hidden in the bowels of the core somewhere. Larry
Re: Q: index("Hello", "", 999)
Markus Laire wrote: What should index("Hello", "", 999) return in perl6? Since the first thing that needs definition is how does the empty string match, it could be e.g. any(0.."Hello".elems). As described in A12 string positions are much more these days than simple ints. There is a class StrPosition or Pos[Str] or Pos of Str or some such. So one signature could be: multi sub index( Str $searched, Str $substr, Pos[Str] ?$pos where { 0 <= $_ < $searched.elems } ) returns Undef[Pos[Str]] ^ Pos[Str] where { 0 <= $_ < $searched.elems } { ... } In perl5 that returns 5, but IMHO -1 would be right result. This is because of the usage of "". Otherwise it's -1. Regards, -- TSa (Thomas Sandlaß)
Re: pop, push, reverse, sort, and splice on a multidimensional array
On Tue, Mar 15, 2005 at 02:22:13AM -0600, Rod Adams wrote: : : my int @a is shape(Int ; Int) = (1..10 ; 2..100 :by(2) ; 4); : : $x = pop @a : push @a, $x; : @b = sort @a; : # etc : : I see two views to take with these cases. : : 1) flatten the array to one dimension, and act accordingly. : : or : : 2) assume : : my int @a is shape(Int ; Int); : my @a is Array of Array of int; : : Mean exactly the same thing, as do : : @a[3;4] : @a[3][4] : : And then operate the Perl 5 way, where C would return an array ref. : : : #2 seems like the way to go, but I'm open to other suggestions. Seems right to me too. Could always reshape the array to one dimension to get the other behavior, and since the array is reshaped, it wouldn't end up "lopsided". : I'm especially interested in hearing people's view on how C : should work with multi-dim arrays. I suppose that would depend on the dimensionality of the subscript. :-) Larry
perl6-language@perl.org
On Tue, Mar 15, 2005 at 02:47:33AM -0600, Rod Adams wrote: : I'm trying to define zip(), but can't come up with a signature for a : function that returns a lazy list of lvalues, but the list itself is not : lazy? If we go with my once-upon-a-time notion of using zip(@a;@b), then it naturally comes in as [EMAIL PROTECTED],[EMAIL PROTECTED] : As a second matter, can you declare a type for the elements of a slurpy : array? Yes, and it distributes as any array return type declaration would. : So far I have: : : multi sub zip (Array [EMAIL PROTECTED]) returns List { : gather { : while any(@lists) { any() is not guaranteed to produce left-to-right order. : for @lists -> @list { : take shift @list; : } : } : } : } : : But I can't tackle the lvalue problem. Why do they need to be lvalues? I always thought of zip as non-destructive. Has zip historically been destructive in other languages? : btw, I'm defining the semantics of some of several functions by simply : supplying a reference implementation. That's cool. Larry
Re: Referencing a caller's slurpy array.
On Tue, Mar 15, 2005 at 01:54:09AM -0600, Rod Adams wrote: : A06 says: : : If you |shift| or |pop| without an argument, it shifts or pops whatever : slurpy array is in scope. : : : Shall we assume that @_ is always an alias for this array, so I can say : something like: : : multi sub pop (Array [EMAIL PROTECTED] = @caller::_) returns Scalar : : ? Well, the alternative would be to have an explicit compiler variable like @?SLURPY, but maybe using @_ for that is more parsimonious. : btw, is ?@ legal in a signature? It's not specifically mentioned in : A/S04, but it makes sense it would be allowed along with ?%. Certainly. The zone markers are as orthogonal to sigils as we can make 'em. Though I'm not sure we've given a meaning to *&foo yet. I suppose that would have to mean that the next slurpy parameter has to be a sub ref. Larry
Re: Q: index("Hello", "", 999)
On Wed, Mar 16, 2005 at 06:44:47PM +0100, Thomas Sandlaß wrote: : Markus Laire wrote: : >What should index("Hello", "", 999) return in perl6? : : Since the first thing that needs definition is how does : the empty string match, it could be e.g. any(0.."Hello".elems). If the position of the first attempt is specified, the null string should match right there. It's an infinite loop if they don't add 1 next time (implying our position type needs to be able to add and subtract in whatever the current units are). One nit, .elems is not defined on strings. .chars works under whatever the current Unicode regime is (default graphemes). : As described in A12 string positions are much more these days : than simple ints. There is a class StrPosition or Pos[Str] : or Pos of Str or some such. So one signature could be: : : multi sub index( Str $searched, : Str $substr, : Pos[Str] ?$pos where { 0 <= $_ < $searched.elems } :) : returns Undef[Pos[Str]] : ^ Pos[Str] where { 0 <= $_ < $searched.elems } : { : ... : } : : : : >In perl5 that returns 5, but IMHO -1 would be right result. : : This is because of the usage of "". Otherwise it's -1. Well, that, and Perl 5 is being "kind" in rounding 999 down to 5 on the assumption that the programmer was specifically using 999 to mean "end of string". It's kind of stupid to assume that for index, but rindex is another matter. Larry
perl6-language@perl.org
On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote: : Just a quick question. In Pugs t/op/arith.t we have: : : sub tryeq_sloppy ($lhs, $rhs, ?$todo1 = '') { : ... : ok($lhs==$rhs,$ todo); : ... : } : : But it breaks the $?CALLER based error reporting, because : it introduces another layer of caller. : : In Perl5, I'd do this: : : { local @_ = ($lhs == $rhs, $todo); goto &ok; } : : Does that form still work with Perl 6? We will have some equivalent way to do an explicit substituting tail call, but perhaps not with that syntax, since passing @_ through is kind of bogus these days. Probably we end up with &func.goto(@args) or some such. : Or should I use this? : : { local &_ := &ok; call($lhs == $rhs, $todo); } : : However, I did not see A/E/S06 specifying that call() will assume the : &goto semantic of erasing itself from the caller chain, so I hesitate : to implement it that way. call() doesn't erase itself from the call chain, but it does "cloak" itself so that CALLER doesn't see it by default. (Presumably there's an option to caller() that makes hidden frames visible.) The whole point of wrappers is that the aren't realy there in some logical sense. : Is using wrap/call the correct choice here, or is there another way : to do it that I missed? wrap/call should do what you want there, but if you want to hack in &func.goto, that'd be good too. Larry
Re: s/true/better name/
Juerd writes: > Nicholas Clark skribis 2005-03-15 17:53 (+): > > On Tue, Mar 15, 2005 at 05:57:57PM +0100, Juerd wrote: > > > And re its spelling, that's a very good feature, because it'll slowly > > > teach me how to spell this word. And when I know how to spell it, I can > > > use it on IRC without dict(1)ing to see if I remembered correctly. This > > > will eventually save me hours! :) > > One problem you may find with dict is that one common misspelling, "wether", > > is also a valid English word, which any decent word list should contain. > > (It's a castrated ram) > > Dict uses dictionaries, not just word lists. It outputs the > definition(s), so this misspelling is easily detected. > > I know both words exists. I just can't manage to remember which one is > which, and maybe Perl 6 can help me :) Meany other hackers halve trouble remembering witch is witch to. I'm all ways perfectly rite thou. Luke
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 12:25, David Storrs wrote: > I quite like <> as the bracketing characters. They are > visually distinctive, they connect well with their adjacent C/X/L/etc > without visually merging into it (compare L with L[foo]), and in > the circumstance that you want to bracket an unbalanced bracket, you > just double (triple, whatever) up and add some space: > > C<< $x > $y >> > > Looks pretty clear to me. You are confusing aesthetics with usability. Yes, the above looks clear, but then I have to type "C<< " and " >>" just to tell the POD parser that there might be unbalanced < or > characters in my string. You're failing to apply Larry's rules of Perl 6. Huffman and the "easy things easy, while hard things are possible" principles demand that a common case not require copious extra gunk, and noting could be simpler than: C[$x > $y] is about as B[easy] as it gets in [Perl] vs: C<< $x > $y >> is about as B as it gets in L[Perl|perl] without going full Wikish: [=$x > $y] is about as *easy* as it gets in [Perl] However, saving a couple of keystrokes and cleaning up the above text is inconsequential compared to 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! -- 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/
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. Either that, or we could define true to be the disjunction of all things true. Then that would work correctly, even when answer() is returning something more interesting than a bare bool. Luke
Re: Markup language-like features in Perl6?
Michele Dondi writes: > However I have the impression that there's still "too much" to it. > Granted, GUIs are intrinsically some order of complexity above textual > IO, but I think that letting the language have intrinsic markup > language(-like) features may make things much easier from the > huffmanization POV in these regards. Well, I don't really know how Perl's very expressive declarative data structure support doesn't help you. Maybe you could give a rough, ugly (if you don't have a nice proposal) description of what you mean. Luke
perl6-language@perl.org
On Wed, Mar 16, 2005 at 10:24:16AM -0800, Larry Wall wrote: > On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote: > : Is using wrap/call the correct choice here, or is there another way > : to do it that I missed? > > wrap/call should do what you want there, but if you want to hack in > &func.goto, that'd be good too. Done as r804. It also passes the expected context ("want") of its original caller to &func, which I assume is the correct behaviour. Thanks, /Autrijus/ pgpBo6lHOX0Pe.pgp Description: PGP signature
Re: s/true/better name/
On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote: : Isn't saying "false doesn't exist" like saying, "dark doesn't exist"? : Why have a word for that? : : I'm really afraid I'm missing something obvious here, but I'm worried : that neither "whether" nor "indeed" work very well in many contexts. It : seems to me that testing trueness exists in so many contexts that it's : going to be hard to find an English word that fits all the important : ones. Most of those contexts are implicitly boolean, and this function would be redundant there. The main use for this function is to provide a boolean context for its argument and return 0 or 1 when you really do want 0 or 1 for some context that isn't directly boolean. This is actually relatively rare. : 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 point is that most people coming from other languages would expect "true" to be a true value, not a function testing whether some other value is true. It would be particularly confusing if we made it default to testing $_, in which case $_ = 0; if 1 == true { say "true" } else { say "false" } would say "false". It is a little less confusing in given $value { when true {...} except that, in fact, both of those cases would be syntax errors if true were a function, since it would parse the following block as an argument to true. So if we really want to test a value for whether its .bit property returns the bool::true value, we will probably require you to use the method syntax: when .true {...} and then it's obvious that there's some object involved. (And it parses right, because .true would require parens if there were arguments.) On the other hand, these also do the same thing underneath, at least in the abstract: when ?$_ {...} if $_ {...} The optimizer is likely to bypass actually calling the .bit/.true method on known types, however. Larry
Re: s/true/better name/
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?
Re: s/true/better name/
On Wed, Mar 16, 2005 at 01:41:56PM -0500, Mark J. Reed wrote: : 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 could be forced to work if MMD is smart enough to call an == function that we were smart enough to define that is smart enough to look at the .bit property of the left argument to coerce that value to 0 or 1. But the naive implementation ends up comparing 42 == 1 and returning false. Unfortunately, == is one of those things we'd like to optimize heavily, and it's hard if there's a lot of MMD cruft in the way. Larry
perl6-language@perl.org
On Thu, Mar 17, 2005 at 02:38:45AM +0800, Autrijus Tang wrote: : On Wed, Mar 16, 2005 at 10:24:16AM -0800, Larry Wall wrote: : > On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote: : > : Is using wrap/call the correct choice here, or is there another way : > : to do it that I missed? : > : > wrap/call should do what you want there, but if you want to hack in : > &func.goto, that'd be good too. : : Done as r804. It also passes the expected context ("want") of its : original caller to &func, which I assume is the correct behaviour. Yes. Larry
Re: Referencing a caller's slurpy array.
Larry Wall writes: > Certainly. The zone markers are as orthogonal to sigils as we can > make 'em. Though I'm not sure we've given a meaning to *&foo yet. > I suppose that would have to mean that the next slurpy parameter has > to be a sub ref. Uhmm... isn't *&foo the adverbial block? That is, isn't it where grep gets its code block in: @list.grep:{ $_ % 2 } Luke
Re: Referencing a caller's slurpy array.
On Wed, Mar 16, 2005 at 11:53:43AM -0700, Luke Palmer wrote: : Larry Wall writes: : > Certainly. The zone markers are as orthogonal to sigils as we can : > make 'em. Though I'm not sure we've given a meaning to *&foo yet. : > I suppose that would have to mean that the next slurpy parameter has : > to be a sub ref. : : Uhmm... isn't *&foo the adverbial block? That is, isn't it where grep : gets its code block in: : : @list.grep:{ $_ % 2 } Maybe it can mean either of those things without conflict, as long as you don't try to make it mean both. :{...} is just short for a named parameter that happens to bind to the *&foo looking parameter, but as with ordinary list operators, they can be passed positionally as well as by name. But yes, to be perfectly frank, I'd forgotten about that. Doubtless a sign of premature senility. Larry
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 12:00 -0500, Aaron Sherman wrote: > On Tue, 2005-03-15 at 13:48, Brian Ingerson wrote: > > Aaron, > > > > Upon reading this, it is unclear to me whether you have read about the > > Kwid format or you are simply guessing that Kwid is the same syntax > > used by Kwiki. > > I read the Kwid documentation from the Pugs distribution in depth. > > To create Kwid I carefully studied the POD information model > (the semantic tree that POD parses to). Kwid uses the exact same > info model. This means that switching between the two without > loss of information is possible. > > I noted that in my original message. > > This makes the Kwid experiment much less risky > > Risk was not my concern. My concern was a Wiki-like model which is > inconsistent with many of the goals of POD. POD is intended to be PLAIN > OLD documentation. I think consistency with "goals" is fine, but consistency with the "data model" is more important. POD has a very nice data model that maps well to other formats. It is really well done. So logic stands that any format which can map cleanly to POD and yet offer an advantages to the author is a benefit to the author without needing to retool the extensions. Further any dialect can be converted to any other without information or structure loss. POD's syntax is certainly good enough, but doesn't match the way that people commonly write structured prose; especially in this era of text based formatting such as in wikis. POD's syntax /elegance/ also tends to break down into workarounds too fast in edge cases. NOTE: POD does have some minor warts in the data model, but they can be fixed later on. > Kwid breaks this model of simplicity by introducing unique boundary > characters for many types of operations, and by making the overall > presentation more complex. Let's look at an example and explore the rationale: Pod uses this syntax B which is fine, but it is a very common idiom to use *bold stuff* outside of Pod. Usenet posts, email, irc, etc. People use this, they grok it, and lots of tools grok it as well. (I'm thinking irc clients as an example). So how do we get *there* formally and avoid making a mess where * is just supposed to be an asterisk? Kwid does this by formally changing X<...> into {X...X} Where `X` is any Pod code like `B`, `I` or `C`. Since there are only 3 codes in common use (ignore `L` for a second), Kwid thus uses {*bold*} {/italic/} and {`code`}. This has a subtle but significant advantage over X<...>. The difference is that instead of the ending marker being '>' it is 'X}', which is orders of magnitude less likely to show up in the content being escaped. This means you avoid the X<< ... >> mess almost entirely. But the better part of this is that the Kwid forms can be relaxed to drop the curlies in most cases. This technique uses the principle of "hugging". So you can say *$a = $b * $c* and get the bolded equation since the middle * isn't hugging anything. Hugging is a nontrivial heuristic, but let's just say it Does The Right Thing. And if you aren't sure just say {*$a = $b * $c*}. ie, just add some curlies to what you already have. *Bold* and /italics/ are rather obvious, intuitive and commonly used. Backticks for `code` was chosen because backticks are rarely used in code. Except of course when writing about Kwid itself. But to get C<`code`> you just go to the curlies: {``code``}. Simple. Backticks also seem to be right visually, but that's just my opinion. For L<...>, I decided to use the very common wiki idiom of [...] for a link. Everything in the `...` is the same as Pod. I is purely subjective whether Kwid's overall presentation is more or less complex than Pod's. Kwid attempts to elegantly move towards the modern internet era of social software, with the hope that those participating in those arenas might feel more at home. > While I appreciate several features of Kwid, I feel that it should not > replace POD without first adopting a POD-like simplicity. > > Some people have argued that Kwid is only a syntactic change to > Pod. I would argue that they are correct. > > They are demonstrably wrong. You cannot Parse Kwid correctly by changing > the syntax of a POD parser. > > For example, the behavior of > > * foo > bar The behaviour of this is completely consistent. You may need to reread the perlkwid document for it has recently changed. ie * foo bar * baz boom matches * foo bar * baz boom matches .list * foo bar * baz boom .list. The explicit `.list` is only needed when the parser cannot guess from the context. ... I would encourage those interested in further fleshing out Kwid to join irc://irc.freenode.net/#kwid where all of this is actively being discussed. Cheers, Brian
Re: s/true/better name/
Larry Wall wrote: On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote: : Isn't saying "false doesn't exist" like saying, "dark doesn't exist"? : Why have a word for that? : : I'm really afraid I'm missing something obvious here, but I'm worried : that neither "whether" nor "indeed" work very well in many contexts. It : seems to me that testing trueness exists in so many contexts that it's : going to be hard to find an English word that fits all the important : ones. Most of those contexts are implicitly boolean, and this function would be redundant there. The main use for this function is to provide a boolean context for its argument and return 0 or 1 when you really do want 0 or 1 for some context that isn't directly boolean. This is actually relatively rare. Doesn't C< +?(...) > take care of those cases? Sure, it's line noise, but do we really need a new keyword for something that's "relatively rare"? Especially when that keyword is likely to confuse people a lot more than the application of two unary operators? -- Rod Adams
Re: Referencing a caller's slurpy array.
Luke Palmer wrote: Larry Wall writes: Certainly. The zone markers are as orthogonal to sigils as we can make 'em. Though I'm not sure we've given a meaning to *&foo yet. I suppose that would have to mean that the next slurpy parameter has to be a sub ref. Uhmm... isn't *&foo the adverbial block? That is, isn't it where grep gets its code block in: @list.grep:{ $_ % 2 } In S29, I currently have C as: multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List { gather { for @values -> $x { take $x if $x ~~ $test; } } } If you wish to supply a closure for C<$test>, you're free to do so. If I were building it to accept just a closure, I would think: multi sub grep (Code &test : [EMAIL PROTECTED]) or multi sub grep (: Code +&test = &defaulttest , [EMAIL PROTECTED]) would make more sense than: multi sub grep (: Code *&test, [EMAIL PROTECTED]) At least to me it does. If you see some advantage to that way, please inform me of it. It might change C away from: multi sub map (Code $expression : [EMAIL PROTECTED]) returns List { gather { while @values { take $expression .( splice(@values, 0, $expression.arity) ); } } } -- Rod Adams
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 13:30 -0500, Aaron Sherman wrote: > On Wed, 2005-03-16 at 12:25, David Storrs wrote: > > > I quite like <> as the bracketing characters. They are > > visually distinctive, they connect well with their adjacent C/X/L/etc > > without visually merging into it (compare L with L[foo]), and in > > the circumstance that you want to bracket an unbalanced bracket, you > > just double (triple, whatever) up and add some space: > > > > C<< $x > $y >> > > > > Looks pretty clear to me. > > You are confusing aesthetics with usability. Yes, the above looks clear, > but then I have to type "C<< " and " >>" just to tell the POD parser > that there might be unbalanced < or > characters in my string. You're > failing to apply Larry's rules of Perl 6. Huffman and the "easy things > easy, while hard things are possible" principles demand that a common > case not require copious extra gunk, and noting could be simpler than: > > C[$x > $y] is about as B[easy] as it gets in [Perl] > > vs: > > C<< $x > $y >> is about as B as it gets in L[Perl|perl] > > without going full Wikish: > > [=$x > $y] is about as *easy* as it gets in [Perl] vs Kwid: `$x > $y` is about as *easy* as it gets in [Perl] Did you really read `perlkwid.kwid`? There is simply no mention of `[=...]` as a markup option, which makes me wonder where you got it from? > However, saving a couple of keystrokes and cleaning up the above text is > inconsequential compared to 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! Well said! Cheers, Brian
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 14:17, Brian Ingerson wrote: > Kwid does this by formally changing > >X<...> > > into > >{X...X} Ok, where is THAT proposal?! I'm reading the doc that's in doc/perlkwid.kwid in the pugs source tree. Hmmm... odd, I just did an update and it's GONE now... was I looking at some phantom doc that had an old spec for Kwid?! > Where `X` is any Pod code like `B`, `I` or `C`. Since there are only 3 > codes in common use (ignore `L` for a second), Kwid thus uses {*bold*} > {/italic/} and {`code`}. Well, I'm personally not fond of the bare-bracketting with {}, but as long as it's not a stand-alone /italic/ like it was in the original doc, that sounds fine. Why {/foo/} is more readable than I[foo], I'm not sure... but I'll try to take your word for it. > For L<...>, I decided to use the very common wiki idiom of [...] for a > link. Everything in the `...` is the same as Pod. There, I think you're making a small mistake, but not a huge one. I'd separate out magical wiki-like [foo] from pedantic, pod-like L[foo] so that you can get either one. Wiki's [foo] is like a URN, where POD's L[foo] is more in tune with a relative URL. > > While I appreciate several features of Kwid, I feel that it should not > > replace POD without first adopting a POD-like simplicity. > > > > Some people have argued that Kwid is only a syntactic change to > > Pod. I would argue that they are correct. > > > > They are demonstrably wrong. You cannot Parse Kwid correctly by changing > > the syntax of a POD parser. > The behaviour of this is completely consistent. You may need to reread the > perlkwid document for it has recently changed. Apparently. > ie > > * foo > bar > * baz > boom > > matches > > * foo bar > * baz boom > > matches > > .list > * foo bar > * baz boom > .list. Hrm... How, then do you differentiate: * Bullet list. 1. Numbered list. Other Term/definition lists ? In POD, that would be: =item * Bullet list =item 1 Numbered list. =item Other Term/definition lists > I would encourage those interested in further fleshing out Kwid to join > irc://irc.freenode.net/#kwid where all of this is actively being > discussed. Sorry, no access to IRC at work. If the specification of core pieces of P6 are being done off-list, why is there a list? -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
perl6-language@perl.org
Larry Wall wrote: If we go with my once-upon-a-time notion of using zip(@a;@b), then it naturally comes in as [EMAIL PROTECTED],[EMAIL PROTECTED] It pretty much has to use the list of lists syntax, since the number of Arrays we are zipping is variadic, and that means using a slurpy, which would flatten the arrays into one. So the semicolons stay. Unless there's a non-flattening slurpy syntax out there : As a second matter, can you declare a type for the elements of a slurpy : array? Yes, and it distributes as any array return type declaration would. Does this mean that we can define multiple slurpuy arrays (and hashes?!?) in a parameter list, of different types, and Perl will sort the arguments into the right slurpy for us? If so, how does this interact with the answer about C<@CALLER::_>? : So far I have: : : multi sub zip (Array [EMAIL PROTECTED]) returns List { : gather { : while any(@lists) { any() is not guaranteed to produce left-to-right order. I'm not counting on it being ordered. I'm testing to see if any of the lists still has anything left in it. The left to right-ness of the processing is done in the C. : for @lists -> @list { : take shift @list; : } : } : } : } : : But I can't tackle the lvalue problem. Why do they need to be lvalues? I always thought of zip as non-destructive. Has zip historically been destructive in other languages? I wasn't aware of a C in other languages. My thought was that people might want to update the values stored inside, as an homage to my common Perl 5 construct: for ($var1, $var2) { s/.../.../; s/.../.../; } (and yes, I'm a bit chagrined that Perl6 is converting that lovely thing to: for $var1, $var2 -> $_ is rw { s/.../.../; s/.../.../; } though given $var1 { s/.../.../; s/.../.../; } is nice. ) But if you don't see the need for lvalueing the elements coming out of C, that certainly makes things easier. :-) -- Rod Adams
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 14:24, Brian Ingerson wrote: > vs Kwid: > > `$x > $y` is about as *easy* as it gets in [Perl] > > Did you really read `perlkwid.kwid`? Yes, and can you please stop asking that question? I read it several times, and you're starting to get just this side of insulting. If I got something wrong, fine, say so. Stop trying to dismiss everything else I've said by suggesting that I'm completely uninformed. > There is simply no mention > of `[=...]` as a markup option, which makes me wonder where you > got it from? I got it from that document or so I thought. Since it's now deleted, I'm no longer sure. Having a reference again would be nice. It's hard to have a conversation about a document that does not exist. Ok, that said PLEASE DO NOT USE UNBALANCED CHARACTERS TO DELIMIT! Please, for the love of all that is valid input to any scanner / parser anywhere, do not re-introduce quoting hell. Really. Please. Don't. I'll buy you a beer. I swear, just put the unbalanced operator down and step back. Sorry, but I use POD specifically because it makes my life simple. Introducing unbalanced quotes into it would remove that functionality. A few examples: "And then I says, `Mabel,' I says, `shut up.'" The ``` character is no longer used. And of course, TONS of Gnu documentation which uses the TeX-friendly: This is the way you ``quote'' things. which means cutting-and-pasting such docs is now much more labor-intensive. -- 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 Wed, Mar 16, 2005 at 01:22:06PM -0600, Rod Adams wrote: : Larry Wall wrote: : : >On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote: : >: Isn't saying "false doesn't exist" like saying, "dark doesn't exist"? : >: Why have a word for that? : >: : >: I'm really afraid I'm missing something obvious here, but I'm worried : >: that neither "whether" nor "indeed" work very well in many contexts. It : >: seems to me that testing trueness exists in so many contexts that it's : >: going to be hard to find an English word that fits all the important : >: ones. : > : >Most of those contexts are implicitly boolean, and this function would : >be redundant there. The main use for this function is to provide a : >boolean context for its argument and return 0 or 1 when you really : >do want 0 or 1 for some context that isn't directly boolean. This : >is actually relatively rare. : > : > : Doesn't C< +?(...) > take care of those cases? : : Sure, it's line noise, but do we really need a new keyword for something : that's "relatively rare"? : Especially when that keyword is likely to confuse people a lot more than : the application of two unary operators? Well, sure, but by a similar argument we don't need "not", "and", or "or" either. I think an acknowledgement of its rarity could show up in making it something relatively long like "whether". On the other hand, I have a linguistic problem with "whether" in that in English it seems to be looser than "and", and "or", while as a "positive not" in Perl, it would be classified as tighter. That is, $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); 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. Larry
perl6-language@perl.org
On Wed, Mar 16, 2005 at 01:48:27PM -0600, Rod Adams wrote: : Larry Wall wrote: : >Yes, and it distributes as any array return type declaration would. : > : > : Does this mean that we can define multiple slurpuy arrays (and : hashes?!?) in a parameter list, of different types, and Perl will sort : the arguments into the right slurpy for us? If so, how does this : interact with the answer about C<@CALLER::_>? No, I just meant that Foo [EMAIL PROTECTED] applies the Foo as the type of the elements of @array despite the presence of the *. : I'm not counting on it being ordered. I'm testing to see if any of the : lists still has anything left in it. The left to right-ness of the : processing is done in the C. Oh, right--I'd better learn to read Perl 6 one of these days. :-) : My thought was that people might want to update the values stored : inside, as an homage to my common Perl 5 construct: : : for ($var1, $var2) { : s/.../.../; : s/.../.../; : } : : : (and yes, I'm a bit chagrined that Perl6 is converting that lovely thing to: : : for $var1, $var2 -> $_ is rw { : s/.../.../; : s/.../.../; : } : : though : : given $var1 { : s/.../.../; : s/.../.../; : } : : is nice. : : ) Well paint yourself unchagrined, because S04 sez: Parameters are by default constant within the block. You can declare a parameter read/write by including the "is rw" trait. If you rely on $_ as the implicit parameter to a block, then then $_ is considered read/write by default. That is, the construct: for @foo {...} is actually short for: for @foo -> $_ is rw {...} so you can modify the current list element in that case. However, any time you specify the arguments, they default to read only. Larry
Re: s/true/better name/
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. Thanks, /Autrijus/ pgpMdkE8bpGa5.pgp Description: PGP signature
perl6-language@perl.org
Larry Wall wrote: Well paint yourself unchagrined, because S04 sez: Parameters are by default constant within the block. You can declare a parameter read/write by including the "is rw" trait. If you rely on $_ as the implicit parameter to a block, then then $_ is considered read/write by default. That is, the construct: for @foo {...} is actually short for: for @foo -> $_ is rw {...} so you can modify the current list element in that case. However, any time you specify the arguments, they default to read only. < gets out unchagrining paint and splashes it about. :-) > You know, the amazing thing about those Synopses and Apocalypses you wrote is that no matter how many times I read them, I always find 5 new things in them on each pass. And I'm the kind of guy who typically absorbs entire 200 page reference manuals in one pass. I swear you found the English equivalent of Quantum Mechanics in there, where entire paragraphs exist and don't exist at the same time, without changing. :-) Of course, I now have to question the need for C. Other than linguistics, which is not to be dismissed, what difference is there between given $expr { ... } and for $expr { ... } with equivalent ...'s? hmm. Come to think of it, the C would flatten $expr if it happened to look like an array or something equally "bumpy", where C would not. But perhaps it would make sense to define C and C as synonyms in all other ways but "autoflatten". As far as linguistics go, "for" makes a suitable replacement for "given" in my head. It's just a very heavily loaded term when you leave English and enter CS-speak. -- Rod Adams
perl6-language@perl.org
Larry Wall skribis 2005-03-16 12:17 (-0800): > for @foo {...} > is actually short for: > for @foo -> $_ is rw {...} Has there been any decision on <-> yet? If <-> is there, it's much easier to say that without arguments, <-> $_ is used. That way, there is no surprising magic "is rw", but just another operator (that happens to be the exact same thing in practice). 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 16/03/05 14:33 -0500, Aaron Sherman wrote: > On Wed, 2005-03-16 at 14:17, Brian Ingerson wrote: > > > Kwid does this by formally changing > > > >X<...> > > > > into > > > >{X...X} > > Ok, where is THAT proposal?! I'm reading the doc that's in > doc/perlkwid.kwid in the pugs source tree. Hmmm... odd, I just did an > update and it's GONE now... was I looking at some phantom doc that had > an old spec for Kwid?! Sorry, it has been moved around the pugs source tree a bit. It is currently swinging from the documentation branch: ext/Pugs-Documentation/perlkwid.kwid > > Where `X` is any Pod code like `B`, `I` or `C`. Since there are only 3 > > codes in common use (ignore `L` for a second), Kwid thus uses {*bold*} > > {/italic/} and {`code`}. FYI, it turns out that at least one modern format, [Markdown|http://daringfireball.net/projects/markdown/syntax], uses backticks for code. Markdown doesn't really map to the Pod space very well, but it has a few gems... > Well, I'm personally not fond of the bare-bracketting with {}, but as > long as it's not a stand-alone /italic/ like it was in the original doc, > that sounds fine. Why {/foo/} is more readable than I[foo], I'm not > sure... but I'll try to take your word for it. In short you don't need to worry about I[[ $foo[3] ]]. Since the ending marker is '/}', you only ever need to worry about escaping anything but '/}' itself. I might as well show how that would be done: {/foo \/} bar/} {{/foo /} bar/}} {/foo { /} } bar/} Those are 3 possible ways to make I. Note that '{ ' and ' }' are the "asis" or "leave me alone" indicators. But the real point is that '/}' is rather unlikely to ever show up in italics outside this discussion. > > For L<...>, I decided to use the very common wiki idiom of [...] for a > > link. Everything in the `...` is the same as Pod. > > There, I think you're making a small mistake, but not a huge one. I'd > separate out magical wiki-like [foo] from pedantic, pod-like L[foo] so > that you can get either one. Wiki's [foo] is like a URN, where POD's > L[foo] is more in tune with a relative URL. So I will give a little extra info on this... The idea is to DWIM and there is a lot you can do with the `[...|.../...]` syntax. Pod's strict syntax is: L /Text/ is obviously the text that should render. /Resource/ can be a local manpage (ie another Pod document) and then /section/ is a section in that doc. If /resource/ is empty, the current document is assumed. /Resource/ can also be a fully qualified url and in that case section does not apply. For some reason Pod does not allow L but there seems to be no obvious reason. (This is the the only major thing where Kwid strays from Pod's info model). I am not certain what use case `L[...]` could get you that isn't already covered by `[...]`. > > > While I appreciate several features of Kwid, I feel that it should not > > > replace POD without first adopting a POD-like simplicity. > > > > > > Some people have argued that Kwid is only a syntactic change to > > > Pod. I would argue that they are correct. > > > > > > They are demonstrably wrong. You cannot Parse Kwid correctly by changing > > > the syntax of a POD parser. > > > The behaviour of this is completely consistent. You may need to reread the > > perlkwid document for it has recently changed. > > Apparently. > > > ie > > > > * foo > > bar > > * baz > > boom > > > > matches > > > > * foo bar > > * baz boom > > > > matches > > > > .list > > * foo bar > > * baz boom > > .list. > > Hrm... > > How, then do you differentiate: > > * Bullet list. > 1. Numbered list. > Other > Term/definition lists > > ? In POD, that would be: > > =item * > > Bullet list > > =item 1 > > Numbered list. > > =item Other > > Term/definition lists This makes no sense in html and perlpod says: * And perhaps most importantly, keep the items consistent: either use "=item *" for all of them, to produce bullets; or use "=item 1.", "=item 2.", etc., to produce numbered lists; or use "=item foo", "=item bar", etc. -- namely, things that look nothing like bullets or numbers. In Kwid, therefore, this: * Bullet list. + Numbered list. - Other Term/definition lists would produce 3 single item lists. You can obviously switch types in sublists: * Bullet list. ++ Numbered list. * another bullet -- Other Term/definition lists > > I would encourage those interested in further fleshing out Kwid to join > > irc://irc.freenode.net/#kwid where all of this is actively being > > discussed. > > Sorry, no access to IRC at work. If the specification of core pieces of > P6 are being done off-list, why is there a list? Honestly this project was started as an /experiment/ and was not intended to distract p6l. Kwid requires no extra i
Re: s/true/better name/
On Wednesday 16 March 2005 15:40, Autrijus Tang wrote: > On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: > > 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. A shotgun brainstorming of possible operator names: determine ponder query consider examine veracity inquire bool boolean bin binary propriety
Re: quotemeta
Larry Wall skribis 2005-03-16 9:41 (-0800): > Except that q:meta would be an upgrade in terms of specialness, > and besides, it's inside out from what you want, which is to quote > a particular argument to a string interpolation, not the entire > interpolation. It just wants to be a miscellaneous function hidden > in the bowels of the core somewhere. Doesn't it want to be the method .escaped then? The method could support all kinds of escaping/encoding. 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 16/03/05 14:56 -0500, Aaron Sherman wrote: > On Wed, 2005-03-16 at 14:24, Brian Ingerson wrote: > > > vs Kwid: > > > > `$x > $y` is about as *easy* as it gets in [Perl] > > > > Did you really read `perlkwid.kwid`? > > Yes, and can you please stop asking that question? I read it several > times, and you're starting to get just this side of insulting. If I got > something wrong, fine, say so. Stop trying to dismiss everything else > I've said by suggesting that I'm completely uninformed. Aaron, /please/ take no offense. I just don't understand where you picked `[=...]` up other than that is the (hated) syntax artifact of the original `CGI::Kwiki`. I don't recall ever using it in regards to Kwid. I'm sure there's a reasonable explanation. :) > > There is simply no mention > > of `[=...]` as a markup option, which makes me wonder where you > > got it from? > > > I got it from that document or so I thought. Since it's now deleted, > I'm no longer sure. Having a reference again would be nice. It's hard to > have a conversation about a document that does not exist. In my first mail of the thread I pointed to it: http://svn.openfoundry.org/pugs/ext/Pugs-Documentation/perlkwid.kwid As I said in my last mail, it has moved around a bit, so pardon our dust. > Ok, that said PLEASE DO NOT USE UNBALANCED CHARACTERS TO DELIMIT! > Please, for the love of all that is valid input to any scanner / parser > anywhere, do not re-introduce quoting hell. Really. Please. Don't. I'll > buy you a beer. I swear, just put the unbalanced operator down and step > back. A beer is tempting... > Sorry, but I use POD specifically because it makes my life simple. > Introducing unbalanced quotes into it would remove that functionality. A > few examples: > > "And then I says, `Mabel,' I says, `shut up.'" > > The ``` character is no longer used. > > And of course, TONS of Gnu documentation which uses the TeX-friendly: > > This is the way you ``quote'' things. No problem with this example. `` doesn't /hug/ anything so it shows up asis. Cutting and pasting LaTeX doesn't mess anything up in this regard. But really, you'll likely refactor it to: This is the way you "quote" things. Since `` and '' don't do anything for you in either Pod or Kwid. Cheers, Brian
Re: quotemeta
On Wed, Mar 16, 2005 at 10:46:29PM +0100, Juerd wrote: : Larry Wall skribis 2005-03-16 9:41 (-0800): : > Except that q:meta would be an upgrade in terms of specialness, : > and besides, it's inside out from what you want, which is to quote : > a particular argument to a string interpolation, not the entire : > interpolation. It just wants to be a miscellaneous function hidden : > in the bowels of the core somewhere. : : Doesn't it want to be the method .escaped then? The method could support : all kinds of escaping/encoding. The question is, escaped for what? quotemeta() is rather Unix-centric in a conservative sort of way. Maybe we're just talking about an option to .as(). Larry
perl6-language@perl.org
On Wed, Mar 16, 2005 at 02:55:21PM -0600, Rod Adams wrote: : Of course, I now have to question the need for C. Other than : linguistics, which is not to be dismissed, what difference is there between : :given $expr { ... } : : and : :for $expr { ... } : : with equivalent ...'s? : : hmm. Come to think of it, the C would flatten $expr if it happened : to look like an array or something equally "bumpy", where C would : not. But perhaps it would make sense to define C and C as : synonyms in all other ways but "autoflatten". We considered this at one point, but in addition to the difference between list and scalar context, there's also the fact that the inside responds differently to "next" and "last". A "given" is officially NOT a loop, so "next" and "last" escape from it to whatever the outer loop is. Larry
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, Mar 16, 2005 at 01:30:04PM -0500, Aaron Sherman wrote: > On Wed, 2005-03-16 at 12:25, David Storrs wrote: > > > I quite like <> as the bracketing characters. They are > > visually distinctive, they connect well with their adjacent C/X/L/etc > > without visually merging into it (compare L with L[foo]), and in > > the circumstance that you want to bracket an unbalanced bracket, you > > just double (triple, whatever) up and add some space: > > > > C<< $x > $y >> > > > > Looks pretty clear to me. > > You are confusing aesthetics with usability. No, I am relating simplicity and consistency to usability. If it costs two extra keystrokes, I'm cool with that. > and noting could be simpler than: > > C[$x > $y] is about as B[easy] as it gets in [Perl] C[$x[0] > $y] # hmmm...parser ok with that? C[$x[0] > $] # hmmm...error, but what was intended: $y] or $]]? C<< $x[0] > $y >> # parser's ok (so's the human) C<< $x[0] > $ >> # oh, obviously $y was intended > However, saving a couple of keystrokes and cleaning up the above text is > inconsequential compared to "...the power of the Force." Sorry, had to say it. > 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. I use Wikis, I run one, I recognize their usefulness. I just don't like them. 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? Quick, what level heading is this: + ? And this is just the beginning...I didn't even get into the weird cases like ==bold fixed font== and __bold italic__, which have no perceptible relation to their component pieces (I would have expected */bold italics/*). Yes, it's powerful and it can do useful things, but as soon as I stray from the most basic stuff I find myself going back to the docs to look up how it's done. Contrast this to POD (I'm not trying for point-to-point equivalence): 1) All formatting starts with = in the first column. 2) Every POD command must have a blank line above and below it. 3) A list of any type starts with =over N and finishes with =back 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. 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. I freely admit that the link syntax in POD is difficult to manage and not as powerful as it could be. --Dks PS I'm subscribed to the list so feel free to just reply there; I don't need a personal copy as well. -- [EMAIL PROTECTED]
Re: Referencing a caller's slurpy array.
Rod Adams writes: > >Uhmm... isn't *&foo the adverbial block? That is, isn't it where grep > >gets its code block in: > > > > @list.grep:{ $_ % 2 } > > > > > > > In S29, I currently have C as: > > multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List { > gather { > for @values -> $x { > take $x if $x ~~ $test; > } > } > } That's the listop form. I was referring to the method form: multi sub grep (@array: *&code) returns List { ... } The fact that there is a conflict in context in the argument points out one of the weaknesses of the current multi declaraition semantics. Currently, it would just default to list context. I think the *compiler* should be able to tell the difference between the two forms without having to go to runtime method dispatch (perhaps it still does dispatch, but if you're in the latter form, you don't even try to dispatch to the former routine). But that's a big brainstorm that needs to happen, and I'm not prepared to do that right now. Luke
RE: New S29 draft up
> -Original Message- > From: Rod Adams [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 16, 2005 3:18 AM > To: Perl6 Language List > Subject: New S29 draft up > > > I just posted a fresh copy of S29 to: > > http://www.rodadams.net/Perl/S29.pod > http://www.rodadams.net/Perl/S29.html > > New: > > All defined functions have been restructured into packages. > > Perl6::Arrays, Perl6::Lists, and Perl6::Hashes are (mostly) written. > > Some Math::Basic and Math::Trig functions added. > > :'s have been added into signatures where they belong. > > various other clean ups. > Isn't there also supposed to be an Arrays::kv? Also, I'm pretty sure Larry said the Lists::reduce should go in the core. Let me try to define them. multi sub kv (Array @array : [EMAIL PROTECTED]) returns List Returns the indexes and associated values stored in @array, lazily and in order by index. Optionally, only those of the slice defined by @indices. multi sub reduce (Code $expression : [EMAIL PROTECTED]) returns List { my $res; for @values -> $cur { FIRST {$res = $cur; next;} $res = &$expression($res, $cur); } $res; } Joe Gottman
Re: New S29 draft up
Joe Gottman writes: > multi sub kv (Array @array : [EMAIL PROTECTED]) returns List > Returns the indexes and associated values stored in @array, lazily and in > order by index. Optionally, only those of the slice defined by @indices. This one is real easy: multi sub kv (@array) returns List { zip(1...; @array); } Array @array means an array of arrays. The [EMAIL PROTECTED] parameter seems superflous, since you could just do: for @array[1..10].kv -> $k, $v {...} Luke
Re: New S29 draft up
Luke Palmer wrote: Joe Gottman writes: multi sub kv (Array @array : [EMAIL PROTECTED]) returns List Returns the indexes and associated values stored in @array, lazily and in order by index. Optionally, only those of the slice defined by @indices. This one is real easy: multi sub kv (@array) returns List { zip(1...; @array); } Doesn't C go until the longest input is exhausted, returning undef at the end of the shorter ones? multi sub kv (@array) returns List { zip([EMAIL PROTECTED] ; @array); } Should work, though. Array @array means an array of arrays. Grr. Another thing I knew better on and was getting wrong. If nothing else, I'm getting used to thinking Perl 6 more and more by writing this thing. The [EMAIL PROTECTED] parameter seems superflous, since you could just do: for @array[1..10].kv -> $k, $v {...} Yea, but I saw Larry mention somewhere about supplying an optional list of values to kv, etc. Forget exactly where, but I know I saw it. At least, that was a reference to the Hash kv, where it makes sense, when it's not painfully obvious that the keys mentioned already exist. My thinking is that the kv/values/etc method of supplying a slice omits elements that don't exist from the output, while the subscript slices would generate undef. Also, I've taken a step and made it where it's now: multi sub keys (@array : Any|Junction [EMAIL PROTECTED]) returns Int|List multi sub kv (@array : Any|Junction [EMAIL PROTECTED]) returns Int|List multi sub pairs (@array : Any|Junction [EMAIL PROTECTED]) returns Int|(List of Pair) multi sub values (@array : Any|Junction [EMAIL PROTECTED]) returns Int|List Which "slices" based on C<$index ~~ any(@indextests)>, which seems a bit more flexible. Thanks to Joe for pointing out the missing functions. They've been added locally and will be posted shortly. (Any others?) -- Rod Adams
Re: Referencing a caller's slurpy array.
Luke Palmer wrote: Rod Adams writes: In S29, I currently have C as: multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List { gather { for @values -> $x { take $x if $x ~~ $test; } } } That's the listop form. I was referring to the method form: multi sub grep (@array: *&code) returns List { ... } Got it. I'll be adding that form to various functions shortly. Could I please get a list of what forms I need to be defining in S29? Right now I have: - General non-OO form. - adverbial code block form (where applicable). I haven't gotten a solid answer on when and how Perl will autogenerate methods from subs. 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? -- Rod Adams
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 13:42 -0800, Brian Ingerson wrote: First off, thanks for your kind responses. I'm sure I just got confused by some web page I was looking at, and overwrote part of my stack that I'd just populated from the Kwid doc. And thanks also for pointing me to the Kwid docs where they live now. > In short you don't need to worry about I[[ $foo[3] ]]. Since the ending > marker is '/}', you only ever need to worry about escaping anything but > '/}' itself. I might as well show how that would be done: We're suffering a major disconnect over the nature of bracketting. I see no reason to I[[ $foo[3] ]] at all. That would simply be I[$foo[3]] ... we are using a real parser here, no? I can't imagine basing this on some pile of regexps, and we all have "matched the balanced brackets" tools at our disposal, regardless of what parser / parser-generator we're using these days. Here's a simple Parse::RecDescent grammar for my proposal, so that we can talk about it in more reasonable terms. Please note that I'm TERRIBLE with P::RD, so I'm sure someone can figure out why I keep ending up with the string "text_chunk" in my resulting syntax tree ;-) See attached program and sample input. Just run parseajskwid.pl on ajskwid.kwid. > For some reason Pod does not allow L but there seems to be no > obvious reason. (This is the the only major thing where Kwid strays from > Pod's info model). That's not POD's info model, that's POD's implementation limitation. > I am not certain what use case `L[...]` could get you that isn't already > covered by `[...]`. I'm very happy with the modern Wiki convention (keep in mind, when we talk about Wiki, we're talking about something that's either nearly as old as or older than the Web, depending on what you count as it's birth) of using [...] as a sort of magical indexer. Like I said elsewhere, you might have: [Kwid] in your document. This is a hint that you expect there to be a thing named "Kwid" somewhere and you wish that somewhere to be applied thusly: L[Kwid|somewhere] in your document. Where L[Kwid] would simply fail because it is as strict as POD, and it won't find L[Kwid|perlkwid]. Other examples of this DWIMery: [http://www.perl.org/] => L[http://www.perl.org/|http://www.perl.org] [;-)] => =for html =for !html ;-) > > How, then do you differentiate: > > > > * Bullet list. > > 1. Numbered list. > > Other > > Term/definition lists [...] > In Kwid, therefore, this: > > * Bullet list. > + Numbered list. > - Other > Term/definition lists That was the answer I was looking for, thanks. I'm not thrilled with it (again, too many special characters that people might have thought they could get away with using in their documentation), but it's not too bad at all. > > Sorry, no access to IRC at work. If the specification of core pieces of > > P6 are being done off-list, why is there a list? > > Honestly this project was started as an /experiment/ and was not > intended to distract p6l. Kwid requires no extra input from the language > side as long as: > > =kwid > ... > =cut 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? = AJS Kwid == Introduction Hello, and welcome to B[AJS Kwid], an experimental form of a proposed syntax and grammar for Perl 6 documentation. == Why Kwid? Kwid was originally proposed for several reasons, and I'll let the authors of that proposal speak for themselves. However, it has been selected as the basis of AJS Kwid for the following reasons: * It is much terser, while maintaining readability. * It maps closely to Wiki syntax, which is well known. * Some features (e.g. the C[[...]] linking) are more flexible. == Why AJS Kwid? AJS Kwid is an attempt to introduce a bit more I[PODishness] to the Kwid syntax. Not much of Kwid is changed in any real way, only the extent to which it closely resembles POD. === Was Kwid Broken? Not at all. Kwid was fine as is, when taken on its own. Only in terms of the human elements of POD compatibility was it problematic (that is, internally it was construct-for-construct, a complete POD replacement, but did not "feel" like POD, and thus the transition from Perl 5 would be even more jarring than Perl 6 is likely to make it). == AJS Kwid Elements The elements of AJS Kwid are fairly simple: =begin list * Newline (or CR/NL) separated lines * Empty lines are treated as paragraph breaks. * Each line can start with C[=], C[*], whitespace, or any text-component. **= C[=] Introduces a command. ***= C[=begin word] Begins a block of type "word", which is ended with an C[=end word] line, later in the document. Such typed blocks must match up, so you have to end a C[=begin foo] with a C[=end foo]. ***= C[=[=...]] string Is a he
return of copies vs references
I need some clarification on the semantics of subroutine or method return statements, regarding whether copies or references are returned. It will help me in my p6ification of p5 code. Say I had a class with 3 private attributes, named [$:foo, @:bar, %:baz], and I was making an explicit accessor for returning the full values of each. Take these 3 example method statements: return $self.foo; return $self.bar; return $self.baz; For each of the above cases, is a copy of or a reference to the attribute returned? For each, will the calling code be able to modify $obj's attributes by modifying the return values, or not? 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. Note that specifying this in the attribute definition isn't appropriate, since an attribute could just as easily be an array of arrays, or hash of hashes, and I am returning an inner array or hash that I either do or don't want to be modifiable by calling code. Separate question, just to confirm, I assume that plain '=' always does a copy? Thank you for any clarification. -- Darren Duncan
Re: s/true/better name/
Larry Wall wrote: On Wed, Mar 16, 2005 at 01:22:06PM -0600, Rod Adams wrote: : Larry Wall wrote: : : >On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote: : >: Isn't saying "false doesn't exist" like saying, "dark doesn't exist"? : >: Why have a word for that? : >: : >: I'm really afraid I'm missing something obvious here, but I'm worried : >: that neither "whether" nor "indeed" work very well in many contexts. It : >: seems to me that testing trueness exists in so many contexts that it's : >: going to be hard to find an English word that fits all the important : >: ones. : > : >Most of those contexts are implicitly boolean, and this function would : >be redundant there. The main use for this function is to provide a : >boolean context for its argument and return 0 or 1 when you really : >do want 0 or 1 for some context that isn't directly boolean. This : >is actually relatively rare. : > : > : Doesn't C< +?(...) > take care of those cases? : : Sure, it's line noise, but do we really need a new keyword for something : that's "relatively rare"? : Especially when that keyword is likely to confuse people a lot more than : the application of two unary operators? Well, sure, but by a similar argument we don't need "not", "and", or "or" either. Well, "and" and "or" serve the purpose of being at a much lower precedence level than "&&" and "||". I would see the value in alphabetic "not" as serving the same relation to "!". But I would still see it returning a Bool, not a numified 0 or 1. I could see a "boolean" operator serving the same relation to "?". But for those cases where someone absolutely has to have a 1 or 0, not some Boolean object, sticking a "+" or "int" in front of a "!", "?", "not", or "boolean" seems to cover that case fine. I think an acknowledgement of its rarity could show up in making it something relatively long like "whether". On the other hand, I have a linguistic problem with "whether" in that in English it seems to be looser than "and", and "or", while as a "positive not" in Perl, it would be classified as tighter. That is, $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); You're going to have that problem with any word you come up with, given "and" and "or"'s relationship with assignment. Unless you make the word magically alter the operator precedence table for any statement it's a part of... Which could happen if you make it a macro that adds some strategic parens for the user. But that jumps way over the "least surprise" line 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. Wouldn't a warning cover that? -- Rod Adams
Re: return of copies vs references
Darren Duncan writes: > I need some clarification on the semantics of subroutine or method > return statements, regarding whether copies or references are > returned. It will help me in my p6ification of p5 code. > > Say I had a class with 3 private attributes, named [$:foo, @:bar, > %:baz], and I was making an explicit accessor for returning the full > values of each. > > Take these 3 example method statements: > > return $self.foo; > return $self.bar; > return $self.baz; > > For each of the above cases, is a copy of or a reference to the > attribute returned? For each, will the calling code be able to > modify $obj's attributes by modifying the return values, or not? Well if you're making accessors, why the heck are you making them private? But I can't really answer your question, because it depends on how you write the accessors. I'll answer your question by rephrasing it to use `$.foo`, [EMAIL PROTECTED], `%.baz`. Assume they are all declared with `is rw`: a) my $x = $obj.foo; b) $obj.foo = $x; d) my $ref = \$obj.foo; e) $$ref = $x; a) my @x = $obj.bar; # @x is now a copy, because = copies b) @obj.bar = (1, 2, 3); c) @obj.bar[2] = 3; d) my $ref = $obj.bar; e) @$ref = (1, 2, 3); a) my %x = $obj.baz; b) %obj.baz = (a => 1, b => 2); c) %obj.baz{b} = 2; d) my $ref = $obj.baz; e) %$ref = (a => 1, b => 2); These are all legal. If you don't declare your attributes with `is rw`, then the "b"s, "c"s (perhaps), and the "e"s are illegal. Now back to your question. You could write rw accessors for each of your private variables that behave like the ones above like so: sub foo() is rw { $:foo } sub bar() is rw { @:bar } sub baz() is rw { %:baz } If you want to intercept the write and do something with it, you can do this (see S06 for details): sub foo() is rw { new Proxy: FETCH => sub ($self) { $:foo }, STORE => sub ($self, $val) { say "Setting to $val"; $:foo = $val; }; } Luke
Re: return of copies vs references
At 11:26 PM -0700 3/16/05, Luke Palmer wrote: > For each of the above cases, is a copy of or a reference to the attribute returned? For each, will the calling code be able to modify $obj's attributes by modifying the return values, or not? Well if you're making accessors, why the heck are you making them private? But I can't really answer your question, because it depends on how you write the accessors. I am writing accessors to mediate with the attributes, which are all private, and whose implementation may change over time. What I want, in the normal case, is that calling code which invokes my methods will get a copy of attributes which it can modify, that won't affect the original attribute values. When I last asked a related question here, I was told that simply returning an attribute will allow the caller to modify the original attribute by default. I wanted to make sure this didn't happen. It is possible that there was a misunderstanding regarding the previous question, and the default action is in fact a copy. -- Darren Duncan
Re: return of copies vs references
On Wed, Mar 16, 2005 at 09:49:47PM -0800, Darren Duncan wrote: : I need some clarification on the semantics of subroutine or method : return statements, regarding whether copies or references are : returned. It will help me in my p6ification of p5 code. : : Say I had a class with 3 private attributes, named [$:foo, @:bar, : %:baz], and I was making an explicit accessor for returning the full : values of each. I am assuming you're talking about read-only accessors, not rw accessors. : Take these 3 example method statements: : : return $self.foo; : return $self.bar; : return $self.baz; Those would have to be: return $self.:foo; return $self.:bar; return $self.:baz; or return $:foo; return @:bar; return %:baz; : For each of the above cases, is a copy of or a reference to the : attribute returned? 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{}; 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;
Re: return of copies vs references
On Wed, Mar 16, 2005 at 11:10:40PM -0800, Darren Duncan wrote: : When I last asked a related question here, I was told that simply : returning an attribute will allow the caller to modify the original : attribute by default. That used to be true for arrays and hashes, but I just changed my mind on it. (Scalars always copy.) : I wanted to make sure this didn't happen. It : is possible that there was a misunderstanding regarding the previous : question, and the default action is in fact a copy. See my other message--it should make you a little happier. I had not sufficiently thought through what would happen with autogenerated read-only accessors in scalar context. Larry