Re: In defense of zero-indexed arrays.
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> A practical argument in its favour is that it makes DC> circular-lists-via-modulo: DC> @list[++nextidx%7] = $nextval; DC> $day_name = <>[$day%7]; DC> both work correctly. not to defend 1 based arrays but all you have to do with the above is add the base offset to them: DC> @list[++nextidx%7 + 1] = $nextval; DC> $day_name = <>[$day%7 + 1]; in any case i like 0 based. the best argument i have seen so far is that is makes -1 a meaningful index. that is something pl1 and fortran could never do without a range declaration. and larry's property and pragma ideas are fine solutions for those who want impaired indexing. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
RE: purge: opposite of grep
Damian Conway: # > Also, can I return superpositions (sorry, junctions), to provide # > multiple classifications? Or would I return an array for that? # # A (dis)junction ought to work there. That sounds horribly scary... --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configure) "If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible." --Ayn Rand, explaining how today's philosophies came to be
Re: purge: opposite of grep
Michael Lazzaro wrote: How would you do something like: (@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source; Since I don't understand what that's supposed to do, I probably *wouldn't* do something like it. What effect are you trying to achieve? Damian
Re: purge: opposite of grep
Dave Whipp wrote: I notice everyone still want Int context for eval of the block: Pease don't forget about hashes. Is there such a thing as 'hashkey context'? I doubt it. Unless you count Str context. Perl6 is much better than Perl5 for naming parameters. Could we make the following work? ( low=>@under, mid=>@in_range, high=>@over ) = partition @input -> $v { $v < 10 ?? "low" :: $v > 20 ?? "high" :: "mid"; }; I very much doubt it. I think at that point you really want: for @input -> $v { push ($v < 10 ?? @under :: $v > 20 ?? @over :: @in_range), $v; } Also, can I return superpositions (sorry, junctions), to provide multiple classifications? Or would I return an array for that? A (dis)junction ought to work there. Damian
Re: Usage of \[oxdb]
Nicholas Clark mused: I just had this thought - can I interpolate in there? Something like "\c[$(call_a_func())]" Why not just: "$(chr call_a_func()]" ??? Damian
Re: purge: opposite of grep
ralph wrote: I worry that C sounds too much like something class-related 'Classify' also seems wrong if some items are thrown away. I like 'part': (@foo,@bar) := part { ... } @source; ralph and I don't often agree, but I certainly do in this case. I like C very much as a name for this built-in. Must be the vaguely biblical association ;-) Headed off in another direction, having a sub distribute its results like this reminds me of: ... -> ... Can arrays on the rhs of a -> ever mean something useful? Sure. It means that the key of the pair is an array reference. Damian
Re: In defense of zero-indexed arrays.
Larry wrote: : Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 : will benefit most users. Do not invoke legacy. [1] How about, because I like it? You may, of course, see that as a legacy argument, depending on our relative ages... :-) A practical argument in its favour is that it makes circular-lists-via-modulo: @list[++nextidx%7] = $nextval; and cyclic-value-mapping-via-modulo: $day_name = <>[$day%7]; both work correctly. Anyway, that aside, I see no reason why we couldn't have array types that are explicitly declared with array bases other than 0. Perhaps even the built-in types can just take a range property: my @array is range(1...); Surely, that would be: my @array is domain(1...); ??? Damian
Re: In defense of zero-indexed arrays.
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: : I'm going to ask something that's probably going to launch off into a long, : silly thread. But I'm really curious what the results will be so I'll ask : it anyway. Think of it as an experiment. : : So here's your essay topic: : : Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 : will benefit most users. Do not invoke legacy. [1] How about, because I like it? You may, of course, see that as a legacy argument, depending on our relative ages... :-) Anyway, that aside, I see no reason why we couldn't have array types that are explicitly declared with array bases other than 0. Perhaps even the built-in types can just take a range property: my @array is range(1...); One could even go so far as to have a pragma that causes all arrays declared in the current *lexical* scope to be based at 1. Call it use fortran; or some such... This is not problematical in the same way that $[ was, since we're limiting the effect to the current lexical scope. In fact, speaking of legacy, you'll recall that the "fix" for Perl 5 was to make $[ = 1; really do a lexically scoped declaration despite having the appearance of a global assignment. By the way, I noticed when visiting Uruguay that the elevators number the floors ...-2, -1, 0, 1, 2..., where 0 is the ground floor, and basement floors are negative. Way cool. Now all we have to do is convince everyone that the year 1 B.C. is the same as year 0 A.D., and 2 B.C. is the same as -1 A.D., and so on. Larry
Re: purge: opposite of grep
Sean O'Rourke writes: > On Thu, 5 Dec 2002, Sean O'Rourke wrote: > > how 'bout "tang" for "Tog's A Negated Grep"? > > Gah. s/Tog/Tang/. Wouldn't that mean we had to rename grep to 'gnat'? ("Gnat's Not A Tang", presumably, never mind rot13 and reversal...) -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: In defense of zero-indexed arrays.
Damien Neil wrote: On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] Answer 1: Ignoring legacy, it won't. Bingo. Answer 2: Because C uses 0-based indexes, Parrot is written in C, and it would be just painful to switch back and forth when working on different layers of the system. (Not a legacy argument, unless you want to argue that Parrot is a legacy system.) I doubt "most users" will be writing Parrot. Answer 3: In a lower-level language than Perl, an array is usually a block of memory divided into array elements. The index is the offset from the start of the array. Assuming the base index of the array is 0. More generally, the index of an array element is that element's offset from the base index of the array. Your argument is somewhat circular. I have oodles of arrays declared to start at 1980. Most of my arrays start at index 1. But then I'm a Fortran programmer. (And I hope that's not an opening for a language war thread.) Choice of language aside, having max_index == num_elements appeals to me. YMMV. In any case, the choice of default base index is less important for Perl than for other languages given how seldom arrays in Perl are accessed by index as opposed to manipulated by push, pop, for $x (@array) loops and such. brad
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Sean O'Rourke wrote: > On 5 Dec 2002, Rafael Garcia-Suarez wrote: > > John Williams wrote in perl.perl6.language : > > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > > ex(1) / vi(1) commands (where 're' stands for regular expression, of > > course) : > > :g/re/p > > :v/re/p > > Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" > for "Elide REgex" or "tang" for "Tog's A Negated Grep"? Gah. s/Tog/Tang/. /s
Re: Stringification of references and objects.
On 12/6/02 4:41 PM, Michael Lazzaro wrote: > my PersonName $name = .new(...); > my FormalStr $s = $name;# "Dr. William P. Smith" > my InformalStr $s = $name;# "Bill" > > Whether that is good, bad, or indifferent I leave to the OO Police. I'm not even deputized, but I call foul: excessive use of subclassing ;) Even in Perl 5 code, I end up having multiple stringification methods for things like error messages. But I simply use different method names for each (e.g. error() and public_error()), and don't bother with overloading "" at all. I think the desire to have stringification DWIM is now bordering on RMMP ("read my mind, please" :) Yes, there will probably be many WTDI in Perl 6, but I doubt any will end up beating the simplicity and clarity of named methods. Standardizing these methods names in an effort to help out debuggers seems reasonable, but I wouldn't go much further than that. In fact, I'd go so far as to say that the default stringification of most objects should probably still be something like FOO(0x1234), since I frequently use those strings to find out if two things are pointing to the same object. At the very least, some sort of similar "unique identifier" should be accessible to any stringification method writer... -John
Re: Usage of \[oxdb]
On Fri, Dec 06, 2002 at 03:24:44PM +1100, Damian Conway wrote: > Larry was certainly in favour of it when he wrote A5 > (see under http://search.cpan.org/perl6/apo/A05.pod#Backslash_Reform). > Except the separators he suggests are semicolons: > > Perl 5 Perl 6 > \x0a\x0d\x[0a;0d] # CRLF > \x0a\x0d\c[CR;LF] # CRLF (conjectural) I just had this thought - can I interpolate in there? Something like "\c[$(call_a_func())]" and I interpolate the string returned by call_a_func() using whatever interpolation system it finds itself in. (so the same function could create the literal control characters if it finds itself in "\c[...]", or the pretty-printed version if it finds itself within "\\c[...]" I'm not sure if this is useful - I think its only benefit is to save a string eval occasionally, with the downside of being obscure, complicating understanding (interpolation becomes run time rather than compile time if it's non-constant), and possibly the implementation. [No I'm not smoking anything. I'm drinking tea today. Maybe it's just side effects of over-exposure to london.pm yesterday, or reading Damian's book (If it moves^Wis a reference - bless it! :-))] Nicholas Clark PS Time for a second edition: perl5.8.0 -lwe 'format FOO = ' -e '.' -e '$a = *FOO{FORMAT}; print ref $a' FORMAT
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:08 PM, Piers Cawley wrote: He notes that VisualWorks Smalltalk makes the distinction between 'displayString', for the user oriented stringification and 'printString', for the programmer oriented. One could imagine a scenario in which a user could accomplish an unlimited number of "styles" of stringification by creating multiple subclasses of C, one per desired style: class FormalStr is Str; class InformalStr is Str; class PersonName { ... method FormalStr { "$.hon $.first $.middleInitial\. $.last" } method InformalStr { $.nick || $.first } } my PersonName $name = .new(...); my FormalStr $s = $name;# "Dr. William P. Smith" my InformalStr $s = $name;# "Bill" Whether that is good, bad, or indifferent I leave to the OO Police. But the same approach could be used for Str and DebugStr, etc. It just depends on what audience we want Perl6 str's to be geared for. (Ignoring the various context/coercion issues raised by the above.) MikeL
Re: Stringification of references and objects.
> This is a bit of an oversimplification. $foo and @foo do not always > behave the same, even if $foo and @foo refer to the same array object. > In particular, $foo doesn't behave like @foo in a list context. > Scalars must continue to behave like scalars in list context, even > if they're internally composite. Am I the only one here who thinks Perl 6's rules for arrays/lists/refs are getting way too complicated? This is getting even worse than C's confusion of them. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Stringification of references and objects.
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: >>> Array(0x1245AB) >>> >>> Personally, I like this format. It's succinct, informative, and tells >>> you enough to do identity testing. >> >> I like it too, but I thought everyone else hated it :) > > I think people like it fine, but many people don't want it to be the > default stringification. Like I said in an earlier thread, the > problem is that there's "stringification for output purposes" and > "stringification for debugging purposes", but we have to chose one or > the other to be the default. I'd rather the debugging one _not_ be > the default, personally, because I imagine the other usage is more > common. Well, personally I think you're very wrong. Kent Beck is good on this in 'Smalltalk Best Practice Patterns': The two audiences for strings generated by objects, you and your client are often in conflict. You want all the internal, structural details of your object laid out in one place so you don't have to go searching layers and layers of objects to find what you want. Your client assumes the object is working correctly and just wants to see externally relevant aspects of the object in the string. He notes that VisualWorks Smalltalk makes the distinction between 'displayString', for the user oriented stringification and 'printString', for the programmer oriented. Personally I reckon that having the the default behaviour be the 'debugging' string makes too from the point of view of separation of concerns; generally you want to separate formatting from the objects themselves. Also, the debugging approach makes sense from the point of view of a 'composite' object. One can imagine cases where a contained object makes incorrect assumptions about how it is being displayed, which could cause problems for the implementation of the container's as_string method; instead of simply doing: join "\n\t" .members (say), you could find yourself adding class based overrides for different sorts of member objects and it could all get ugly quickly. > An obvious counterproposal would be to say that references are > invisible to stringification (e.g. it stringifies to whatever its > contents stringify to). This would seem to be in keeping with the the > spirit of arrayref/array transparentness, etc. Personally I'm not keen on this idea. The distinction between the thing itself and a pointer to the thing is an important distinction for the programmer to be aware of. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Perl 6 and Set Theory
=head1 Perl 6 and Set Theory This document will introduce a new way of thinking about some Perl 6 constructs. In addition, it proposes some minor changes that would help this way of thinking be more consistent. These changes may make Perl 6 a better language in general, as a side effect. Even in absence of an explicit "set" type, Perl 6 is quite proficient in set theory. There are two types of sets it knows about: finite and infinite. The former we call "junctions," while "classes" make up infinite sets. =head2 Junctions Junctions are a transparent mechanism for dealing with finite sets. They indeed hold a discrete set of objects, but operations on the junction are automatically delegated to operations on its members. The two types of junctions, disjunctive (C) and conjunctive (C) just determine how the junction is evaluated in boolean context. The expressions: 1 | 2 | 3 any(1, 2, 3) 1 & 2 & 3 all(1, 2, 3) represent the set: { 1, 2, 3 } Which we will call N. Performing some operation I on them constructs and returns the set: { z(x): x ∈ N } If, for example, this operation is C<{ $^x + 2 }>, we have: { x + 2: x ∈ N } or { 3, 4, 5 } If that was a comparison operation, say C<{ $^x > 2 }>, the resultant set would be: { undef, undef, 1 } Evaluating this in boolean context should be true if the junction was conjunctive, and false if it was disjunctive. So, for a junction J, boolean context evaluation is defined as follows: { ∃x: x ∈ J ∧ ?x, disjunctive ?J ≡ { { ∀x: x ∈ J ⇒ ?x, conjunctive That is, the "type" of junction just determines whether the quantifier is existential or universal. There is one behavior of junctions, however, that doesn't work with this definition: If a boolean operation is applied in non-boolean context to a junction, it will return a junction of only the values for which the condition evaluated true. But with a few minor changes, this can be achieved: • Junctions discard Cs on-sight (i.e. C can never be a member of a junction). • Comparison operators return C if they fail, and their left-hand side "C" if they succeed. • Comparison operators are right-associative. Unfortunately, the last change clobbers the left-short-circuiting behavior of comparison operators. A way to fix this would be to treat a chain of comparison operators as a single n-ary operator. Other methods for fixing this are welcome (and encouraged). Note that the definition of how junctions behave in itself allows operators involving more than one junction to represent the outer product of those junctions with respect to an operator. Consider two sets, A = any(1,2,3), and B = all(4,5,6). A + B = { x + B: x ∈ A } = { { x + y: y ∈ B }: x ∈ A } = { { 5, 6, 7 }, { 6, 7, 8 }, { 7, 8, 9 } } Where each inner set is a conjunctive set, and the outer is a disjunctive set. If you call this resultant set C, and ask: 5 < C < 9 It would be true (in fact, "C<5 but true>"), as all(6, 7, 8) would match. =head2 Classes In Perl 6, classes represent infinite sets of objects. The class C represents the set of integers, C the set of all numbers, including the integers. Inheritance represents supersets. Finite sets, or junctions, can be used for union and intersection of these infinite sets. Unlike junctions, classes are not transparent interfaces to their members. You can't say C<< Int > 10 >> to find out whether all integers are greater than 10. There is, in fact, no way to assert this in Perl, as Perl would have to instantiate ℵ₀ objects, which would take ℵ₀ seconds (forever). Similarly with Num, except now there's ℵ₁ objects and seconds (foreverer). For instance, to declare a variable that can represent either an integer or a string: my (Int | Str) $var; The type of that variable is the union of the sets of integers and strings. The value of $var must be a member of at least one of those sets. Since a derived object can be used in place of its parent anywhere, it must represent an improper superset of its parent. This seems backwards, but if you think about it logically: Every member of the parent set needs to be a member of the child set; every member of the child set need not be a member of the parent set. Q.E.D. Multiple inheritance represents a superset of multiple sets. C or C represents the "universe"; i.e. the set of all objects. The null junction C represents the empty set (which is different from C, as proposed above). It is an interesting issue whether any junction can be used as a class. That is: my (1 | 2 | 4) $var; would declare $var to only accept values 1, 2, and 4. This probably introduces too much complexity for what it's worth. =head2 Summary The rules for a junction J, again, are: z(J) ≡ { z(x): x ∈ J } { ∃x: x ∈ J ∧ ?x, disjunctive ?J ≡ { { ∀x: x ∈ J ⇒ ?x, conjunctive Classes have no such rules, as t
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: > John Williams wrote in perl.perl6.language : > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > ex(1) / vi(1) commands (where 're' stands for regular expression, of > course) : > :g/re/p > :v/re/p Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" for "Elide REgex" or "tang" for "Tog's A Negated Grep"? /s
Re: In defense of zero-indexed arrays.
> 2002-12-05 10:45:39, Michael G Schwern <[EMAIL PROTECTED]> wrote: > I'm going to ask something that's probably going to launch off into a > long, silly thread. But I'm really curious what the results will be so > I'll ask it anyway. Think of it as an experiment. > > So here's your essay topic: > > Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 > will benefit most users. Do not invoke legacy. [1] > > [1] ie. "because that's how most other languages do it" or "everyone is > used to it by now" are not valid arguments. Ask any Pascal programmer. > :) The other (reverse) way out, i'm not trying to make an essay, just think out loud but if you have $string = "Hello World", and you want the last three chars, you do: $wanted = substr $string, -3; If the first index was 1, it could be ok too, but what would be offset 0? What if someone was looking at his string backwards? $pos = 1; # 0 | 1 # - substr $string, $pos--, 1; # 'H' | 'e' substr $string, $pos--, 1; # 'd' | 'H' substr $string, $pos--, 1; # 'l' | '' ? substr $string, $pos--, 1; # 'r' | 'd' ? Dont ask me why someone would do that... But i expect to get the last $string's char with $pos == -1, not 0. I also find the 'offset' idea to be consistent with binary math. After all, with bytes, 0x7F + 1 == +0d127 but also -0d128... and i found it sometimes useful to be able to mix signed and unsigned values. One could argue it's not the way to go, it's tricky, you dont mix signed/unsigned... blah. Walking is tricky, bicycling is tricky, remember the first time you tried and you fell? blah. no more args :-) (yet another lurker)
Re: In defense of zero-indexed arrays.
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: > Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 > will benefit most users. Do not invoke legacy. [1] Answer 1: Ignoring legacy, it won't. Answer 2: Because C uses 0-based indexes, Parrot is written in C, and it would be just painful to switch back and forth when working on different layers of the system. (Not a legacy argument, unless you want to argue that Parrot is a legacy system.) Answer 3: In a lower-level language than Perl, an array is usually a block of memory divided into array elements. The index is the offset from the start of the array. In languages like C which allow pointer arithmetic, it makes sense for the array index to be the element offset, to allow a[i] to be equal to *(a + i). Higher level languages should follow this convention, for consistency. (Again, not a legacy argument, since it offers a first-principles rationale for 0-based arrays in certain contexts.) - Damien
Re: Quick translation wanted
On Fri, Dec 06, 2002 at 12:27:31PM -0700, Luke Palmer wrote: : > Date: Fri, 06 Dec 2002 11:15:20 -0800 : > From: Larry Wall <[EMAIL PROTECTED]> : > : > As for constructor syntax, I suppose we might make use of the $. notation : > like this: : > : > method new($.name, $.age) { : > return $class.bless; : > } : : Come to think of it, new is a class method, not an object method. How : is that specified again? Is there going to be sugar to blur that : distinction for constructors? You'll not that $class was declared typeless, so it doesn't matter if it was actually a class or an object of that class. Actually, that last example was wrong--it should have been method new($.name, $.age) { return .bless; } or method new($class: $.name, $.age) { return $class.bless; } But in either case, if $class is untyped, it can work with either cloning or class-based constructors. Larry
Re: Quick translation wanted
> Date: Fri, 06 Dec 2002 11:15:20 -0800 > From: Larry Wall <[EMAIL PROTECTED]> > > As for constructor syntax, I suppose we might make use of the $. notation > like this: > > method new($.name, $.age) { > return $class.bless; > } Come to think of it, new is a class method, not an object method. How is that specified again? Is there going to be sugar to blur that distinction for constructors? Luke
Re: purge: opposite of grep
Michael said: > I worry that C sounds too much like > something class-related 'Classify' also seems wrong if some items are thrown away. I like 'part': (@foo,@bar) := part { ... } @source; Headed off in another direction, having a sub distribute its results like this reminds me of: ... -> ... Can arrays on the rhs of a -> ever mean something useful? -- ralph
Re: Quick translation wanted
On Fri, Dec 06, 2002 at 08:44:23AM -0700, Luke Palmer wrote: : > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm : > Sender: [EMAIL PROTECTED] : > From: Simon Cozens <[EMAIL PROTECTED]> : > Date: 06 Dec 2002 14:54:43 + : > Organization: Bethnal Green is PEOPLE! : > X-Posted-By: 217.204.174.162 : > : > : > Is it clear how attributes accessors on objects are going to work yet? : > I need to say something along the lines of: : > : >sub new { : >my $class = shift; : >my ($name, $age) = @_; : > bless { : > name => $name, : > age => $age : > }, $class; : >} : > : >sub age { my $self=shift; $self->{age} } : > : : There's nothing decided on how constructors work yet, so I'll use a : fill-in syntax. : : class Person { : has $.name is private;# No accessor generated : has $.age; Attributes are probably private by default. Methods are public by default. : method new($n, $a) { : ($.name, $.age) = ($n, $a); : return bless; # bless me => myself : } : } That would need to be a .bless, since bless is not longer a builtin, but a class method. So I'd make it: class Person { has $.name; has $.age is public; method new($n, $a) { ($.name, $.age) = ($n, $a); return .bless; } } which is short for something like: class Person { has $.name; has $.age; method new($class: $n, $a) { ($.name, $.age) = ($n, $a); return $class.bless; } method age () is rw { return $.age; } } There may well be a property on a class that makes all its attributes public by default, so it acts more like a struct in C++. As for constructor syntax, I suppose we might make use of the $. notation like this: method new($.name, $.age) { return $class.bless; } and it would be assumed that those args go straight into the object. We also have to thrash out the difference between "new" and "init". An init() call might occur within a bless, in which case you might just write method init($.name, $.age) {...} Maybe the default initializer is method init($.name = undef, $.age = undef, *@extras) {...} So we might actually end up with a constructor calls looking like $class.bless(name => $me, rank => "low", serial => 12345); Named parameters tend to work a lot better than positional for constructors, especially if the parameters intended for a different initializer can be ignored. But this is all Apo 12, so still highly speculative... Larry
Re: purge: opposite of grep
Michael Lazzaro wrote: I worry that C sounds too much like something class-related, and would confuse people. What about C or something? Decent thesaurus entries for include: assign, classify, comb, compartmentalize, discriminate, distribute, group, order, segregate, sift, winnow, amputate, cut, dismember, excise, lop, disunite, divorce, estrange, part, wean, detach, disconnect, disengage, dissociate, extract, isolate, part, steal, take, uncouple, withdraw designate? -- Tim
Re: String Literals, take 3
On Fri, Dec 06, 2002 at 10:16:20AM -0700, John Williams wrote: : On Fri, 6 Dec 2002, Joseph F. Ryan wrote: : > : > What's wrong with single quoted here-docs? : : What's wrong is that the documentation team is trying to allow \qq[] : there too, contradicting their own assertion that backslashes are not : special in that context. Ahem. If you go back and look again, you'll see that I'm the one who contradicted the assertion... : > Don't forget that the backslash is already special in : > non-interpolating strings; I don't think that adding a single : > special case will make things too confusing. : > : > >What if \q[] was allowed in interpolated strings, but not in : > >non-interpolated strings. Then I'm happy with that non-interpolated : > >strings really don't interpolate, and you might be happy because it would : > >only make sense to do one level of nesting. ie, you cannot embed \qq[] : > >inside \q[]. Or you could do $(''), which is the same number of : > >characters as \qq[], and doesn't require introducing : > >yet-another-new-rule-to-an-already-too-complicated-escaping-system. : > : > I think \qq[] is the much more useful of the two, so : > that really doesn't help much. : : Oh well, I'm being overly-speculative above, which I shouldn't do on this : list, but I was wondering if compromise was possible. Changing the : behavior of backslashes and balanced delimiters is also speculative. : : The current behavior in perl5 is that only two sequences are special in : non-interpolated strings : :\\ --> \ :\ --> : : can be either the opening or closing delimiter when they are : balanced. So you CAN backslash them, but I don't HAVE to. : : Larry has added \qq[] and \q[], so "\q" is now special. (Are \qw[] and : \qx[] in? qw doesn't make sense, and qx might be insecure.) That's not what I said. I said that \qq[ is special. Don't go chopping my bracket off--I intend it to be required. Also, there's no reason to allow \q[] inside single quotes. The others are rare enough that they could be put inside \qq[]. In fact, if you want it all consistent, we could say that the *only* way to put anything non-verbatim into any single-quoted string is with \qq[]. So instead of '\\' you'd say '\qq[\\]' and instead of '\'' you'd say '\qq[']'. (And no, the latter doesn't actually require a backslash before the '. If you think it does, you're still thinking of a two-pass lexer like Perl 5. Perl 6 will have a one-pass lexer, and the only delimiter it's looking for at the time it sees the quote is actually a right bracket.) On the other hand, people are likely to expect \\ and \' to continue working as they currently do in ordinary single quoted strings. We could go with the stricter rule for just single-quoted here docs, I suppose. : I would really appreciate a ruling from the design team before we change : non-interpolative semantics regarding: : : 1) the interpretation of \, :PRO: it makes backslash behavior consistent :CON: the perl5 behavior is as unobtrusive as possible Well, no, I don't think \\ and \' are really "as unobtrusive as possible"... : 2) requiring balanced delimiters to be escaped, :PRO: it's consistent with non-balanced delimiter requirements :CON: you already can; don't force it those who don't want it See above about one-pass lexer. Balanced delimiters generally need no backslashing unless they're a literal outside of any other bracketing construct. : 3) allowing \qq[] in single-quoted here-docs. :PRO: it's consistent with single-quotes :CON: it contradicts the assertion that backslashes are not special in : single quoted here-docs : we need a quoting mechanism where NOTHING is special : : (Those are ordered from least to most offensive, BTW.) Then paint me most offensive, by all means. :-) Larry
Re: purge: opposite of grep
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote > > Some of those might be appropriate (or just amusing). :-) I still like partition (or simply C). Segregate (c) might also work I notice everyone still want Int context for eval of the block: Pease don't forget about hashes. Is there such a thing as 'hashkey context'? Perl6 is much better than Perl5 for naming parameters. Could we make the following work? ( low=>@under, mid=>@in_range, high=>@over ) = partition @input -> $v { $v < 10 ?? "low" :: $v > 20 ?? "high" :: "mid"; }; Also, can I return superpositions (sorry, junctions), to provide multiple classifications? Or would I return an array for that? Dave.
Re: Stringification of references and objects.
On Fri, Dec 06, 2002 at 10:40:18AM -0500, Dan Sugalski wrote: : If an aggregate and a reference to an aggregate are going to behave : the same, which is what Larry's indicated in the past, then : stringifying a reference should be the same as stringifying its : referent. This is a bit of an oversimplification. $foo and @foo do not always behave the same, even if $foo and @foo refer to the same array object. In particular, $foo doesn't behave like @foo in a list context. Scalars must continue to behave like scalars in list context, even if they're internally composite. As in Perl 5, if you say for $foo {...} the sub only gets one argument, the array ref, but if you say for @foo {...} or for @$foo {...} you get all of the elements. But it's probably fair to say that $foo and @foo always behave identically in a scalar context. We may, in fact, have to deprecate the term "list context" and replace it with something like "flattening context", since we can have lists of scalars that are in some sense in a "list context" but that aren't in a flattening context: my ($a,@b,%c) := (@a,$b,%c); But "flattening" is a lousy word. It's really more of a "variadic" context, but that's no improvement. At the moment I can't think of anything better than "splat" context... Larry
Re: String Literals, take 3
On Friday, December 6, 2002, at 09:46 AM, Luke Palmer wrote: 3) allowing \qq[] in single-quoted here-docs. PRO: it's consistent with single-quotes CON: it contradicts the assertion that backslashes are not special in single quoted here-docs The problem is, as Larry said, that heredocs are *exactly* where you most want to use \q and \qq. You have a big long hairy thing, and you want to treat only one-little-part of it differently, without escaping all the special characters throughout every other part of the doc. By allowing \qq in single-quoted heredocs, we allow things like: < ...big long text with $ chars $all$ $over$ $it$... The value of $v is \qq[$v] ...$more$ $icky$ $text$... END we need a quoting mechanism where NOTHING is special Well, I suppose you could default something to a qq heredoc, and q all the non-qq parts. But that's significantly more awkward-looking, IMO. Does \qq really come up in heredocs unless you explicitly mean it? MikeL
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: Array(0x1245AB) Personally, I like this format. It's succinct, informative, and tells you enough to do identity testing. I like it too, but I thought everyone else hated it :) I think people like it fine, but many people don't want it to be the default stringification. Like I said in an earlier thread, the problem is that there's "stringification for output purposes" and "stringification for debugging purposes", but we have to chose one or the other to be the default. I'd rather the debugging one _not_ be the default, personally, because I imagine the other usage is more common. An obvious counterproposal would be to say that references are invisible to stringification (e.g. it stringifies to whatever its contents stringify to). This would seem to be in keeping with the the spirit of arrayref/array transparentness, etc. So you're saying that classes should stringify to a pretty-print of their public members? No, the AS_STRING (or str(), or whatever) is definitely the way to go. We pretty much _have_ to do it via a method. Brent Dax wrote: What I'm saying is that .str and .identity (for lack of a better name) are identical in Object, but classes should feel free to override .str if they have a better WTDI. The built-in classes (Array, Hash, etc.) should override .str to yield their members in some format (probably influenced by properties). I like this a lot, personally. MikeL
Re: Stringification of references and objects.
At 6:36 PM -0500 12/5/02, Joseph F. Ryan wrote: By default, references should not stringify to anything "pretty", they should stringifiy to something useful for debugging. Heck, even perl5 style should be fine. Not only is this handy, but also prevents problems with circular referencing data structures, huge data structures, etc. However, all built-in types should have a .repr() method, which should provide primitive Data::Dumper-ish output If an aggregate and a reference to an aggregate are going to behave the same, which is what Larry's indicated in the past, then stringifying a reference should be the same as stringifying its referent. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String Literals, take 3
> Date: Fri, 6 Dec 2002 10:16:20 -0700 (MST) > From: John Williams <[EMAIL PROTECTED]> > > 2) requiring balanced delimiters to be escaped, >PRO: it's consistent with non-balanced delimiter requirements >CON: you already can; don't force it those who don't want it I'll say no, agreeing with the CON. > 3) allowing \qq[] in single-quoted here-docs. >PRO: it's consistent with single-quotes >CON: it contradicts the assertion that backslashes are not special in > single quoted here-docs I'd say no here, which is consistent with Perl 5. My opinion basically agrees with Perl 5: I've never had a problem with those quoting rules. OTOH, I've never had to deal with localization. In single-quoted heredocs, _nothing_ should be special. When I'm writing a P::RD grammar, I don't want to worry about doubling my backslashes, which might already be doubled. is never pretty. If there is a single backslashed construct, then backslashes must be doubled, which stinks. > we need a quoting mechanism where NOTHING is special I agree one-hundapacent! Luke
Re: purge: opposite of grep
On Thursday, December 5, 2002, at 07:55 PM, Damian Conway wrote: equally. The built-in would actually be doing classification of the elements of the list, so it ought to be called C. I worry that C sounds too much like something class-related, and would confuse people. What about C or something? Decent thesaurus entries for include: assign, classify, comb, compartmentalize, discriminate, distribute, group, order, segregate, sift, winnow, amputate, cut, dismember, excise, lop, disunite, divorce, estrange, part, wean, detach, disconnect, disengage, dissociate, extract, isolate, part, steal, take, uncouple, withdraw Some of those might be appropriate (or just amusing). :-) The selector block/closure would, naturally, be called in C context each time, so (again, as Larry pointed out) a boolean function would naturally classify into two arrays. Though it How would you do something like: (@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source; I was more hoping for a C or C derivative that would provide a series of 'stream'-like tests, not just one test with N answers. Something that was a shorthand for the obvious but somewhat tedious C counterpart. (If @source had an entry 'foobar', we could debate whether that should go in one destination stream or two.) Especially since you then get your purge/vrep/antigrep for free: I don't think we need a separate func either, but if we're gonna have a purge/vrep/antigrep, can someone _please_ think of a better name for it? "purge" clearly needs an inverse called "binge", "vrep" sounds like, well, UNIX, and "antigrep" sounds like something I put in my car to avoid it grepping when I start it on cold mornings. Even just "ngrep" sounds better to me. :-| MikeL
RE: Stringification of references and objects.
Joseph F. Ryan: # Brent Dax wrote # # >To tell you the truth, I don't consider arrayrefs references # anymore. # >They're just Array objects that don't happen to be in @whatever # >symbols. I don't know if this is the official view, but that fits my # >brain better. # > # # So you're saying that classes should stringify to a # pretty-print of their public members? No, because that wouldn't reveal enough for an equality check. At the same time, however, exposing private members would be wrong, especially since editing the string and creating a new instance from it would allow the user to manipulate private members. What I'm saying is that .str and .identity (for lack of a better name) are identical in Object, but classes should feel free to override .str if they have a better WTDI. The built-in classes (Array, Hash, etc.) should override .str to yield their members in some format (probably influenced by properties). --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configure) "If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible." --Ayn Rand, explaining how today's philosophies came to be
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 04:28 AM, Joseph F. Ryan wrote: Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members? How about something like what Ruby's irb does? % irb irb(main):001:0> class Foo irb(main):002:1>def initialize irb(main):003:2> @a, @b, @c = 1, 2, 3 irb(main):004:2>end irb(main):005:1> end nil irb(main):006:0> Foo.new # irb(main):007:0>
Re: String Literals, take 3
On Fri, 6 Dec 2002, Joseph F. Ryan wrote: > > What's wrong with single quoted here-docs? What's wrong is that the documentation team is trying to allow \qq[] there too, contradicting their own assertion that backslashes are not special in that context. > Don't forget that the backslash is already special in > non-interpolating strings; I don't think that adding a single > special case will make things too confusing. > > >What if \q[] was allowed in interpolated strings, but not in > >non-interpolated strings. Then I'm happy with that non-interpolated > >strings really don't interpolate, and you might be happy because it would > >only make sense to do one level of nesting. ie, you cannot embed \qq[] > >inside \q[]. Or you could do $(''), which is the same number of > >characters as \qq[], and doesn't require introducing > >yet-another-new-rule-to-an-already-too-complicated-escaping-system. > > I think \qq[] is the much more useful of the two, so > that really doesn't help much. Oh well, I'm being overly-speculative above, which I shouldn't do on this list, but I was wondering if compromise was possible. Changing the behavior of backslashes and balanced delimiters is also speculative. The current behavior in perl5 is that only two sequences are special in non-interpolated strings \\ --> \ \ --> can be either the opening or closing delimiter when they are balanced. So you CAN backslash them, but I don't HAVE to. Larry has added \qq[] and \q[], so "\q" is now special. (Are \qw[] and \qx[] in? qw doesn't make sense, and qx might be insecure.) I would really appreciate a ruling from the design team before we change non-interpolative semantics regarding: 1) the interpretation of \, PRO: it makes backslash behavior consistent CON: the perl5 behavior is as unobtrusive as possible 2) requiring balanced delimiters to be escaped, PRO: it's consistent with non-balanced delimiter requirements CON: you already can; don't force it those who don't want it 3) allowing \qq[] in single-quoted here-docs. PRO: it's consistent with single-quotes CON: it contradicts the assertion that backslashes are not special in single quoted here-docs we need a quoting mechanism where NOTHING is special (Those are ordered from least to most offensive, BTW.) ~ John Williams
Re: purge: opposite of grep
On Fri, Dec 06, 2002 at 09:33:14AM -0500, Miko O'Sullivan wrote: > For example, suppose I want to separate a list of people into people who > have never donated money and those who have. Assuming that each person > object has a donations property which is an array reference, I would want > to classify them in this manner: > > (@nevers, @donors) := classify($_->[donations]) @people; > > According to the C model, that would give me people who have donated > zero times, and people who have donated once, and the people who have > donated more than once would be lost. Then turn donations into a boolean. (@donors, @nevers) := classify(!$_->[donations]) @people; I don't think there is the need to bloat the langauge with every special case we can think of. Graham.
Re: Quick translation wanted
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Sender: [EMAIL PROTECTED] > From: Simon Cozens <[EMAIL PROTECTED]> > Date: 06 Dec 2002 14:54:43 + > Organization: Bethnal Green is PEOPLE! > X-Posted-By: 217.204.174.162 > > > Is it clear how attributes accessors on objects are going to work yet? > I need to say something along the lines of: > >sub new { >my $class = shift; >my ($name, $age) = @_; > bless { > name => $name, > age => $age > }, $class; >} > >sub age { my $self=shift; $self->{age} } > There's nothing decided on how constructors work yet, so I'll use a fill-in syntax. class Person { has $.name is private;# No accessor generated has $.age; method new($n, $a) { ($.name, $.age) = ($n, $a); return bless; # bless me => myself } }
Quick translation wanted
Is it clear how attributes accessors on objects are going to work yet? I need to say something along the lines of: sub new { my $class = shift; my ($name, $age) = @_; bless { name => $name, age => $age }, $class; } sub age { my $self=shift; $self->{age} } -- "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." -- Carl Sagan
Re: purge: opposite of grep
On Fri, 6 Dec 2002, Damian Conway wrote: > The selector block/closure would, naturally, be called in C context > each time, so (again, as Larry pointed out) a boolean function would > naturally classify into two arrays. Though it might at first be a little > counterintuitive to have to write: OK, but I would assert that the false/true classification is going to be the more common case, not "classify by index position", and that furthermore there will be a lot of situations where the false/true value may be any number, not just 1 or 0. For example, suppose I want to separate a list of people into people who have never donated money and those who have. Assuming that each person object has a donations property which is an array reference, I would want to classify them in this manner: (@nevers, @donors) := classify($_->[donations]) @people; According to the C model, that would give me people who have donated zero times, and people who have donated once, and the people who have donated more than once would be lost. Now, of course you can force the dontations into a boolean context, but, frankly, I think If we force people to always remember to force boolean context, just to preserve the (IMHO) unusual case of classifying by integer, we're, on balance, making more work for the world. Ergo, I suggest we simply have a separate command for the false/true situation: (@nevers, @donors) := falsetrue($_->[donations]) @people; (Yes, "falsetrue" is a stupid name, please replace with something better.) -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/05/2002 12:18 PM, Michael Lazzaro wrote: On Thursday, December 5, 2002, at 02:11 AM, James Mastros wrote: On 12/04/2002 3:21 PM, Larry Wall wrote: \x and \o are then just shortcuts. Can we please also have \0 as a shortcut for \0x0? \0 in addition to \x, meaning the same thing? I think that would get us back to where we were with octal, wouldn't it? I'm not real keen on leading zero meaning anything, personally... :-P You misinterpret. I meant \0 meaning the same as \c[NUL], IE the same as chr(0), a null character. (I suppse I should have said \0x[0].) Which means that the only way to get a string with a literal 0xFF byte in it is with qq:u1[\xFF]? (Larry, I don't know that this has been mentioned before: is that right?) chr:u1(0xFF) might do it too, but we're getting ahead of ourselves. Hmm... does this matter? Sorry. It does, in fact, not matter... momentarly stopped thinking in terms of utf8 encoding being a completly transparent process.
Re: Stringification of references and objects.
Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members?
RE: Stringification of references and objects.
Joseph F. Ryan: # >Why? Isn't the pretty form more generally useful? # > # # I don't think so; I'd think it to be annoying to have type # more code in order to specify a more cocise form; if I need # to dump a structure, I'd prefer to do it manually. I think it's useful to be able to say @array.str() and $arrayref.str() and get the same result. And since we already know what @array.str will do (essentially what "@array" does in Perl 5), that suggests that $arrayref.str() will do the same. # > method str() { # > #Unnamed invocant means you need $_, right? # > return $_.class() ~ "($_.id())"; # > } # > # >(where id() returns a uniquely identifying integer, usually the # >address). # > # # Objects aren't references anymore, are they? So I don't # think it is apporpriate for an object to stringify with its id. To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configure) "If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible." --Ayn Rand, explaining how today's philosophies came to be
Re: In defense of zero-indexed arrays.
On 05/12/02 02:45 -0800, Michael G Schwern wrote: > I'm going to ask something that's probably going to launch off into a long, > silly thread. But I'm really curious what the results will be so I'll ask > it anyway. Think of it as an experiment. > > So here's your essay topic: > > Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 > will benefit most users. Do not invoke legacy. [1] With languages like Perl that have negative subscripts, using a zero base gives continuity. @INC[-2..2] should continue to DWIM. Cheers, Brian