Re: Ruminating RFC 93- alphabet-blind pattern matching
Yary Hluchan wrote: making *productions* of strings/sounds/whatever that could possibly match the regular expression? Correct me if I am wrong, but isn't this the :any switch of apoc 5? http://www.perl.com/pub/a/2002/06/26/synopsis5.html Not really, unless the input string is infinite! Well, thats just in the general purpose case, right? That's because a regex like /a*/ matches: 'w' 'qsdf' 'i bet you didn't wnt this to mtch' So, you're going to need some sort of controlled input to a regex match with the :any for it to work right. Here's my approach to the problem: generate a possible string that could match every atom in the regex individually, and then generate matches for the whole regex off of that. I liked Luke's approach of stapling methods onto the Rx classes, so I used an approach that made use of that idea. I completed each of the needed rules, since the methods in my example are pretty simple (they probably would be in Luke's example too, but I just wanted to be sure I wasn't missing anything). use List::Permutations <>; # Perl 5's name. sub generate (rx $spec, Int $limit) { my $string = $spec.generate_match (&propagate, $limit); $string =~ m:any/ (<$spec>) { yield $1 } /; my sub propagate ($atom) { given ($atom) { when Perl::sv_literal { $string ~= $_.literal() } when Perl::Rx { $string ~= .generate_match (&propagate, $limit) if .isa(generate_match) } } } } Perl::Rx::Atom::generate_match (&p, $limit) { return &p.($.atom) } Perl::Rx::Zerowidth::generate_match (&p, $limit) { return &p.($.atom) } Perl::Rx::Meta::generate_match (&p, $limit) { return join '', $.possible } Perl::Rx::Oneof::generate_match (&p, $limit) { return join '', $.possible } Perl::Rx::Charclass::generate_match (&p, $limit) { return join '', $.possible } Perl::Rx::Sequence::generate_match (&p, $limit) { my $string; $string ~= &p.($_) for $.atoms; return $string; } Perl::Rx::Alternation::generate_match (&p, $limit) { my $string; $string ~= &p.($_) for $.branches; return $string; } Perl::Rx::Modifier::generate_match (&p, $limit) { my $string; $string ~= &p.($_) for $.atoms; # is $self ($.) still the topic here? or is the last # member of $.atoms? return $self.mod.transform($string); } Perl::Rx::Modifier::repeat (&p, $limit) { $string := join '', map { join '', $_ } permutations (split //, &p.($.atom)) xx ($.max // $limit); return $string; } So, given a call like: generate (/(A*B*(C*|Z+))/, 4); The C<$string> variable in the 2nd line of C would become: And the :any switch takes care of the rest. (-: Joseph F. Ryan [EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Joseph F. Ryan wrote: Luke Palmer wrote: On Thu, Apr 03, 2003 at 07:29:37AM -0800, Austin Hastings wrote: This has been alluded to before. What would /A*B*/ produce? Because if you were just processing the rex, I think you'd have to finish generating all possibilities of A* before you began iterating over B*... The "proper" way would be to first produce all possibilities of length n before giving any possibility of length n+1. '' 'A' 'B' 'AA' 'AB' 'BB' 'AAA' 'AAB' ... I haven't spent a milisecond of working out whether that's feasible to implement, but from a theoretical POV it seems like the solution. Well, I'm not certain there is really a "proper" way. But sure, your way is doable. use Permutations <>; # Generate all strings of length $n method Rule::Group::generate(Int $n) { # Type sprinkles :) compositions($n, [EMAIL PROTECTED]) ==> map { my @rets = map {$^atom.generate($^n) } zip(@.atoms, $_); *permutations([EMAIL PROTECTED]) } } How's that for A4 and A6 in a nutshell, implementing an A5 conept? :) I hope I got it right Provided each other kind of rx element implemented generate, that returned all generated strings of length $n, which might be zero. This would be trivial for most other atoms and ops (I think). Oh, compositions($a,$b) is a function that returns all lists of length $b whose elements sum to $a. Yes, it exists. I have a couple syntax questions about this if anyone knows the answers: $^atom.generate($^n) I want @rets to be an array of array refs. Do I have to explicitly take the reference of that, or does that work by itself? zip(@.atoms, $_) I want the array ref in $_ to be zipped up with @.atoms as if $_ were a real array. If this I correct, am I allowed to say: zip(@.atoms, @$_) for documentation? Also, related to the first question: *permutations([EMAIL PROTECTED]) Does that interpolate the returned list from permutations right into the map's return, a la Perl5? Do I need the * ? As far all of these questions, I think the answer is related. I think the general question is "Is implicit flattening needed for perl6 builtins?" I think that the answer is no, or at least should be no, because it won't be hard to get the builtins to DWIM because of multimethods. For instance, an implementation of map might be: sub *map (&code, Array @array) { return @array.map(&code); } sub *map (&code, [EMAIL PROTECTED]) { my @ret; for @rest { @ret.push( &code.($_) ); } return @ret; } Except that it should be: multi *map (&code, Array @array) { return @array.map(&code); } multi *map (&code, [EMAIL PROTECTED]) { my @ret; for @rest { @ret.push( &code.($_) ); } return @ret; } I swear, my brain must hate me; I always overlook the most obvious mistakes. (-: Joseph F. Ryan [EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Luke Palmer wrote: On Thu, Apr 03, 2003 at 07:29:37AM -0800, Austin Hastings wrote: This has been alluded to before. What would /A*B*/ produce? Because if you were just processing the rex, I think you'd have to finish generating all possibilities of A* before you began iterating over B*... The "proper" way would be to first produce all possibilities of length n before giving any possibility of length n+1. '' 'A' 'B' 'AA' 'AB' 'BB' 'AAA' 'AAB' ... I haven't spent a milisecond of working out whether that's feasible to implement, but from a theoretical POV it seems like the solution. Well, I'm not certain there is really a "proper" way. But sure, your way is doable. use Permutations <>; # Generate all strings of length $n method Rule::Group::generate(Int $n) { # Type sprinkles :) compositions($n, [EMAIL PROTECTED]) ==> map { my @rets = map { $^atom.generate($^n) } zip(@.atoms, $_); *permutations([EMAIL PROTECTED]) } } How's that for A4 and A6 in a nutshell, implementing an A5 conept? :) I hope I got it right Provided each other kind of rx element implemented generate, that returned all generated strings of length $n, which might be zero. This would be trivial for most other atoms and ops (I think). Oh, compositions($a,$b) is a function that returns all lists of length $b whose elements sum to $a. Yes, it exists. I have a couple syntax questions about this if anyone knows the answers: $^atom.generate($^n) I want @rets to be an array of array refs. Do I have to explicitly take the reference of that, or does that work by itself? zip(@.atoms, $_) I want the array ref in $_ to be zipped up with @.atoms as if $_ were a real array. If this I correct, am I allowed to say: zip(@.atoms, @$_) for documentation? Also, related to the first question: *permutations([EMAIL PROTECTED]) Does that interpolate the returned list from permutations right into the map's return, a la Perl5? Do I need the * ? As far all of these questions, I think the answer is related. I think the general question is "Is implicit flattening needed for perl6 builtins?" I think that the answer is no, or at least should be no, because it won't be hard to get the builtins to DWIM because of multimethods. For instance, an implementation of map might be: sub *map (&code, Array @array) { return @array.map(&code); } sub *map (&code, [EMAIL PROTECTED]) { my @ret; for @rest { @ret.push( &code.($_) ); } return @ret; } So, given an Array/Array Subclass/Reference to one of the two as the 2nd argument to map, map would call the method version of map; otherwise, the arguments after the code block are flattened and looped over. This behaivor should be consistant across all of the perl6 builtins. Joseph F. Ryan [EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Edward Peschko wrote: What I think you're looking for is the fact that they're not regexes any more. They are > "rexen", but in horrifying-secret-reality, what has happened is that Larry's decided to move Fortran out of core, and replace it with yacc. just an aside, and a bit off-topic, but has anybody considered hijacking the regular expression engine in perl6 and turning it into its opposite, namely making *productions* of strings/sounds/whatever that could possibly match the regular expression? ie: a* producing '' a aa aaa etc. Correct me if I am wrong, but isn't this the :any switch of apoc 5? http://www.perl.com/pub/a/2002/06/26/synopsis5.html Joseph F. Ryan [EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Austin Hastings wrote: Another example. Let's say there's a class that deals with colors. It has an operator that returns true if two colors look about the same. Given a list of color objects, is there a regexp to find a rainbow? Even if the color class doesn't support stringification? Yes. grammar Rainbow; rule color {...}; # this one's on you. rule same_color($color is Colorific) { ::: { fail unless $1.looks_like($color); } } rule band($color is Colorific) { + } rule Rainbow { ? } I'm a bit confused by the C rule; specifically, this line: $1.looks_like($color) Shouldn't this be: C<< $color.looks_like($1) >> ? Otherwise, it suggests that you're redefining the match object class, which probably isn't a good idea. Joseph F. Ryan [EMAIL PROTECTED]
Re: Embedded foreign syntax (was Re: P6ML?)
Joseph F. Ryan wrote: >Miko O'Sullivan wrote: > >>Andy Wardley wrote: >> >>>For example, it might be possible to do something like this: >>> >>> use Perl6::XML; >>> >>> >>> blah blah >>> >>> >>> use Perl6; >>> >>> print $thingy.blah; >> >> >> >>We already have the ability to embed foreign languages (XML, HTML, >>whatever) using here docs: >> >>$myml = MyXmlParser->new(<< '(MARKUP)'); >> >> blah blah >> >>(MARKUP) > > >As a side note, P6C now has the ability to inline code of a different >language, so something like this will work: > >use inline 'XML', q[ > > blah blah > > ... > > >]; > >Provided, of course, that there is an parrot/imcc targetted XML processor. Who needs >a P6ML now? (-: > >Joseph F. Ryan >[EMAIL PROTECTED] Woops; my mail client crashed when I sent this the first time; I had thought it hadn't sent, so I re-wrote it and sent it again. Sorry for the double post! Joseph F. Ryan [EMAIL PROTECTED] -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
Re: Embedded foreign syntax (was Re: P6ML?)
Miko O'Sullivan wrote: >Andy Wardley wrote: > >>For example, it might be possible to do something like this: >> >> use Perl6::XML; >> >> >>blah blah >> >> >> use Perl6; >> >>print $thingy.blah; > > > >We already have the ability to embed foreign languages (XML, HTML, >whatever) using here docs: > > $myml = MyXmlParser->new(<< '(MARKUP)'); > > blah blah > > (MARKUP) As a side note, P6C now has the ability to inline code of a different language, so something like this will work: use inline 'XML', q[ blah blah ... ]; Provided, of course, that there is an parrot/imcc targetted XML processor. Who needs a P6ML now? (-: Joseph F. Ryan [EMAIL PROTECTED] -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
Re: Embedded foreign syntax (was Re: P6ML?)
Miko O'Sullivan wrote: >Andy Wardley wrote: > >>For example, it might be possible to do something like this: >> >> use Perl6::XML; >> >> >>blah blah >> >> >> use Perl6; >> >>print $thingy.blah; > > > >We already have the ability to embed foreign languages (XML, HTML, >whatever) using here docs: > > $myml = MyXmlParser->new(<< '(MARKUP)'); > > blah blah > > (MARKUP) > Well, P6C has the new ability of inlining code from another parrot- based language. All someone needs to do is write an XML processor that spits out pasm/imcc, and then: use inline 'XML', q[ blah blah ]; or even: use inline 'XML', <<"XML_IS_FUN"; blah blah XML_IS_FUN See how easy that is? Who needs a stinking P6ML now? (-: Joseph F. Ryan [EMAIL PROTECTED] -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
Re: Arrays vs lists; A possible solution?
Erik Steven Harrison wrote: -- On Wed, 12 Feb 2003 17:14:17 Erik Steven Harrison wrote: -- On Wed, 12 Feb 2003 18:29:29 Joseph F. Ryan wrote: As near as I can tell, the only problem with the nice flow of: A I is a piece of data. A I is a variable that holds a literal. A I is a sequence of literals and scalars. An I is a variable that holds a list. is the "Rvalue-assign list", which takes the form of: ($r1, $r2, $r3) = (1, 2, 3); I don't see a problem here. The list on the right is still just value, unmodifiable. It is a list of rvalues. When you use a variable on the right hand side it is a rvalue. Similarly, a list of variables doesn't flatten to it's values - it is the list itself that it is immutable. It's individual members still retain asignibility in rvalue context. Okay, pardon me for replying to myself, but that was _really_ badly worded. An example foreach ($foo, $bar, $baz) { .zoomdingle; } The objects in the list retain full status qua objects even though they are in a list, which is why we can call methods on them. Similarly, the fact that a scalar variable acts as a value on the lefthand side and a rvalue on the right hand side is retained even though it is in a list. It is the list itself which is immutable. Python programmers will grasp this real fast - it's just a tuple. You're completely right. See my last message :-) Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs lists; A possible solution?
Erik Steven Harrison wrote: -- On Wed, 12 Feb 2003 18:29:29 Joseph F. Ryan wrote: As near as I can tell, the only problem with the nice flow of: A I is a piece of data. A I is a variable that holds a literal. A I is a sequence of literals and scalars. An I is a variable that holds a list. is the "Rvalue-assign list", which takes the form of: ($r1, $r2, $r3) = (1, 2, 3); I don't see a problem here. The list on the right is still just value, unmodifiable. It is a list of rvalues. When you use a variable on the right hand side it is a rvalue. Similarly, a list of variables doesn't flatten to it's values - it is the list itself that it is immutable. It's individual members still retain asignibility in rvalue context. -Erik Ah, I'm a compete fool. I meant Lvalue, not Rvalue. If you could do a mental s:e/Rvalue/Lvalue on that last message, I would appreciate it. Joseph F. Ryan [EMAIL PROTECTED]
Arrays vs lists; A possible solution?
As near as I can tell, the only problem with the nice flow of: A I is a piece of data. A I is a variable that holds a literal. A I is a sequence of literals and scalars. An I is a variable that holds a list. is the "Rvalue-assign list", which takes the form of: ($r1, $r2, $r3) = (1, 2, 3); Well, what if an "Rvalue-assign list" is simply decoupled from a normal "data list." The confusion would end. The concepts themselves are separate, so why shouldn't the names be? "data lists" become "The One True List Type", and "Rvalue-assign lists" become something like "Rvalue sequences" (or a catchier name). Peace would reign on earth, or at least p6-lang and p6-doc. (I hope I'm not missing something obvious here, at any rate :) Joseph F. Ryan ryan.311@osu
Re: Arrays vs. Lists
Mark J. Reed wrote: On 2003-02-11 at 17:12:52, Joseph F. Ryan wrote: (@a,@b,@c).pop This doesn't make any sense, since pop modifies the pop-ee. What do you expect should happen here? [@a,@b,@c].pop Same as above. Except that the Perl5 equivalent, ugly as the syntax may be, works fine: pop @{[@a,@b,@c]} It creates an anonymous array, then removes the last element, leaving two elements in the array - which is irrelevant since the array is then discarded completely. I don't see any reason to change this behavior for Perl6. Apologies; when I meant "same as above", I meant "same answer that I gave for: >>>> [1..10].map {... >>>I think this *should* work, although I'm not sure *how*. Meaning that "I think this should be possible, but I'm not sure if that syntax is correct, because it would mean that the arrayrefs would need to be their own class to allow a method to be called on it, and this class would need to be a wrapper around the real array class". Re-reading my original message, I can see the reason for the confusion. In fact, I don't even know what I was thinking when I thought people would make that connection that I wanted, as it doesn't even make sense to me now :-) Hmm... now that I think more about it, making array references their own class and wrapping it around the real array class would make it pretty easy to cause all of the "auto dereferencing when necessary" behaivor that is causing so many problems, since auto-dereferencing wouldn't have to happen, it would only seem that way. Does this sound feasible? Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs. Lists
Michael Lazzaro wrote: On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote: Indeed, this supports the distinction, which I will reiterate: - Arrays are variables. - Lists are values. My hesitation about the 'arrays are variables' part is that Damian corrected me on a similar thing when I was writing about scalars. A variable is more like "a name of a container for a value", e.g. there's three parts to it: - the name (what it's called in the namespace) - the container (a specific container implementation) - the value (what's inside it) So I don't know that arrays are variables, so much as arrays are containers, if we want to get pedantic about it (which I don't, but... documentation... sigh). They're definately variables. The container is a PerlArray, which is a distinctly different object compared to a PerlUndef. Just to clarify... in P6, is this an array reference, or a list reference? [1,2,3] I'd say it is an array reference. What about this? \@array I'd say both of them are array references, but there's no variable associated with the first one -- it's just an anonymous container There should be a variable attached, but just no name attached to the variable. So I'd rewrite the definition to: - Lists are an ordered collection of scalar values - Arrays are containers that store lists (Coupled with Uri's explanations, of course... it's the 'container' part that allows read/write, as opposed to simply read.) Yes/no? Maybe :-) Arrays are things that know about lists. They know how to get a particular element out of a list. They know how to *flatten themselves, interpolating themselves into the surrounding list. They know how to map, grep, sort, splice themselves. They know how to turn themselves into a scalar. Lists don't know how to do these things. But is it OK for a list to be silently promoted to an array when used as an array But this would mean that an implicit anonymous array would need to be created, which isn't always possible in the middle of a statement. So, that would mean the compiler would need to be smart enough to figure out when this will happen, and then create the anonymous array beforehand, and then somehow alias the list contents to the array. Thats a heck of a lot of magic going on there. So that all of the following would work, and not just 50% of them? (1..10).map {...} I think this should be an error. What object is the method getting called on? Is forcing the functional syntax on lists really that horrible? [1..10].map {... I think this *should* work, although I'm not sure *how*. (@a,@b,@c).pop This doesn't make any sense, since pop modifies the pop-ee. What do you expect should happen here? [@a,@b,@c].pop Same as above. Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs. Lists
Deborah Ariel Pickett wrote: While I like the glib "Arrays are variables that hold lists" explanation that worked so well in Perl5, I think that Perl6 is introducing some changes to this that make this less true. Like what? Well, like the builtin switch statement, which was what I was trying to show in my bad example below. What I meant was: In Perl5, pretty much anywhere you have a list, you can write an array variable instead, and get much the same behaviour: @a = (1, 2, 3); func(@a); func(1,2,3); The exceptions appear to be builtin operators like C, functions that have Perl5-prototypes, and using lists/arrays as lvalues. But all of those are caught by the Perl5 parser, and treated specially. Everywhere else, naming an array automatically expands to a list containing the array's contents. It's pretty much a universal, and something which Perl programmers hold dear. In Perl6, where there seems to be even more of a blur between compile-time and runtime, Actually, I think they'll be more separated. In fact, the compiler will just be an extension to the runtime-engine. I don't think it's always going to be possible (i.e., easy) to know where naming an array or providing an actual list would produce the same effect. The switch statement was my example. Apocalypse 4 has a table (page 2 of the perl.com version) which bears this out. Lists have their own entries on this table, separate from arrays. So it's conceivable that a switch statement that switches on a list and a switch statement that switches on an array containing the same list produces different results. I see what you mean now; C topic-alizes what it is, well, given. This would cause it to work differently for variables and "other." Perhaps this just adds the switch statement to the set of Perl constructs that require special compiler attention, like lvalues and builtin operators. I think you might be right; however, it would be nice if this wasn't the case, as then user-defined functions could act similarly. (kinda like how perl5-prototypes allow user-defined functions to act like perl5- bultins, without the yeehh of perl5-prototypes.) (This suggests to me that it won't be possible to implement the switch statement as a pure Perl6 function - as people were trying to do with C - without greater-than-usual assistance from the Perl6 compiler.) It also appears that we'll now be able to pass multiple arrays to functions without the taking-references shenanigans that you have to go through in Perl5. So there's another example where lists and arrays appear to be going their separate ways, with lists almost being their own data type, in a manner of speaking. I dare say that we'll have to wait till Apocalypse 6 for the full story here. (Just going off on a tangent: Is it true that an array slice such as @array[4..8] is syntactically equivalent to this list (@array[4], @array[5], @array[6], @array[7], @array[8]) ? Are array slices always lists in Perl6?) I think so, unless its possible to do crazy things like reference part of an array. Maybe @array[4..8] is a list, and \@array[4..8] acts like an array. Or maybe \@array[4..8] is actually ( \@array[4], \@array[5], \@array[6], \@array[7], \@array[8]), like it is in perl 5. If it keeps that behaivor, then @array[4..8] is always a list. Would there be any truth in this distinction: - lists are ordered sets/bags/etc seen by the Perl parser - arrays are ordered sets/bags/etc seen by the Perl interpreter ? Where s/parser/compiler/, and s/interpretter/runtime engine/? I do believe that's accurate. What joy I'll have explaining that one to my students . . . Better you than me. :-) Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs. Lists
Deborah Ariel Pickett wrote: I'm trying, and failing, to accurately and definitively answer the question "what's the difference between an array and a list in Perl6?" If someone can come up with a simple but accurate definition, it would be helpful. While I like the glib "Arrays are variables that hold lists" explanation that worked so well in Perl5, I think that Perl6 is introducing some changes to this that make this less true. Like what? For instance, the switch statement has different rules for lists and arrays. So these don't necessarily do exactly the same thing in Perl6: # Please excuse syntax errors here, but you know what I mean given (1,2,3) { when $x: and @a = (1, 2, 3); given @a { when $x: ... I don't understand the difference here. Could you elaborate? Would there be any truth in this distinction: - lists are ordered sets/bags/etc seen by the Perl parser - arrays are ordered sets/bags/etc seen by the Perl interpreter ? Where s/parser/compiler/, and s/interpretter/runtime engine/? I do believe that's accurate. Joseph F. Ryan [EMAIL PROTECTED]
Re: Shortcut: ?=
Miko O'Sullivan wrote: SUMMARY C<$var ?= $x : $y> as a shortcut for C<$var = $var ? $x : $y>. DETAILS We have ||=, +=, -=, etc. These shortcuts (I'm sure there's some fancy linguistic term for them) save us a few keystrokes and clean up the code. So, concerning C, I find myself doing this type of thing a lot: $var = $var ? 1 : 0; How 'bout a shortcut for that, something like this: $var ?= 1 : 0; -miko Doesn't the perl6 //= operator already do what you suggest? Joseph F. Ryan [EMAIL PROTECTED]
Re: AW: Sabbatical from the list
Murat Ünalan wrote: It is likely that I will start reading again after A6 and E6 Sorry for uninformedness, but what is "A6" and "E6" ? Any versioning of p6 dev releases ? Murat Apocalypse 6 and Exgenesis 6. Please do a search on perl.com for 1-5.
Re: Ordering is not what distinguish array from associative tables
Stéphane Payrard wrote: On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote: Yes, I would expect that. In my opinion there is no difference between an array and a hash other than the underlying storage and the type-management of the key. I'm increasingly of the opinion that a) there should be no @ vs %, there should be no {} vs [], there should be a keys, values, defined, delete, exists, push, pop, shift, unshift for every container and foreach shouldn't give a damn. I think that arrays and associative tables are very different entities for two reasons: -type of keys. array keys are integers -cost of insertion and deletion operations: O(n) and lower for associative table ( O(1) if you don't care for key ordering, O(log(n)) if you care for ordering). This is enough to warrant different syntaxes for arrays and hash. I'm sure I'll get shot for saying this, but no it doesn't. PHP arrays are simply associative arrays with a integer as the key value. Of course, this doesn't mean I like the idea, but I just wanted to point out that there are some languages that do it this way. However, I hope that we are not going to be one of those. Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays: Default Values
attriel wrote: So ... with the discussion of "what if i really wanted to put an undef in there b/c it's not just that i haven't defined it but rather that it really isn't defined. I KNOW it's not defined, and i'm now explicitly saying it's undefined as opposed to before when i was implicitly suggesting that i didn't know what it was and used a default 'unknown'" discussion ... What we really need is: @a[2] = undef but undef; or, possibly (more tongue-in-cheek-y) @a[2] = undef but seriously; so the ... property? would say "you have a default, maybe, but i don't care. this is REALLY undef" is that possible? aside from it being disturbing to write "undef but undef" :o --attriel (the first suggestion is serious, but the syntax is flawed; the second suggestion has better syntax but is tongue-in-cheek suggested ... ) What about: undef @a[2]; or possibly even (although I would argue that undef should remain a unary operator only): @a[2].undef(); Joseph F. Ryan [EMAIL PROTECTED]
Re: A proposal on if and else
Rafael Garcia-Suarez wrote: Joseph F. Ryan wrote in perl.perl6.language : I think the point of having C as a sub rather than as a separate syntax is so the parser doesn't have to do anything special for special keywords. I think the goal was to simplify the compiler, but with the discussion of recent weeks, it certainly doesn't look like that happened. :) Simplify the compiler, yes; but (with my limited knowledge of Perl 6) I don't expect the tokenizer to be simple. And the hack I just proposed to the tokenizer is mostly stateless. If the final design stays the way it is now, there really won't be a "lexer". Instead, a perl6 grammar parses the data, and builds up a huge match-object as it, well, matches. This match object is then munged into the optree. This means the grammar probably won't be anything resembling simple, since it has to act as both a lexer and a parser at the same time. However, that's not to say your hack couldn't work; in fact, it would be easy to implement during the match-object-munging phase. However, it still treats C as special syntax, which is the real issue at hand.. I question whether treating C as a function rather than as built-in syntax will make the parser any simpler if "special block rules" keep getting added to simply make it work. I'm in favor of keeping a few "special blocks" if it makes things easier to implement/design in the long run. Joseph F. Ryan [EMAIL PROTECTED]
Re: A proposal on if and else
Rafael Garcia-Suarez wrote: Brent Dax wrote in perl.perl6.language : Yes, I know this means that we have 'else if' instead of 'elsif', but it's only two more characters and it makes the grammar cleaner. The tokeniser could send two tokens "else" and "if" whenever it recognizes the keyword "elsif" -- so this isn't a problem. I think the point of having C as a sub rather than as a separate syntax is so the parser doesn't have to do anything special for special keywords. I think the goal was to simplify the compiler, but with the discussion of recent weeks, it certainly doesn't look like that happened. :) Joseph F. Ryan [EMAIL PROTECTED]
Re: Civility, please.
Michael Lazzaro wrote: "Joseph F. Ryan" wrote: Perhaps in the grand scheme of things; however, anyone that is redesigning a system should not be ignorant of how the old system worked (even in the slightest degree), in order to know of what to keep and what to throw away. Oy. One more time. My objection is this: I said C and friends are special compared to normal subroutine syntax, because there isn't a comma after the {...}. It was then stated that C itself is not special, because the '&' in the prototype allows the special case to exist not only in "map", but in anything else prototyped in the same way. True. My error, therefore, was to not properly define what I meant by "normal subroutine syntax", because I thought it was clear from the context what "normal" meant... it meant "compared to having a comma there". But it wasn't clear. This, however, is a Computer Science discussion. Computer Science is one of those fields populated almost exclusively by people who consider any statement devoid of at least three explanatory footnotes to be an act of aggression, and who measure their own genius in large part by their practiced lack of ability to infer meaning from any string of words not emanating from their own head. Thus, a possible response like "I don't agree with your use of the word 'special' to describe this case, because these other cases are identically 'special' too" is transformed without any apparent irony to "since you did not use the precise wording I myself would have used in your two-sentence explanation, that provides conclusive evidence that you therefore don't know Perl5." Yes, in hindsight, I should have responded "I know *why* the specialness exists, you thundering blowhards, I'm just noting that it *is* special compared to how *most* subroutine argument lists look. Quit assuming that every last syntactic nuance will tunnel untouched to Perl6 by the grace of your own unassailable wisdom, and tell me *why* this particular one should." [1] Those sorts of communications can sometimes cross the semantic barrier. Yes, perhaps we should all have our mail proofread by a peer jury before we post, thus attempting universal semantic clarity... or perhaps we can all just practice those human social skills that some of us might have seen on television or in the movies, and Get Over Ourselves. [2] (Note that Damian was the *only* person who, at any point in the discussion, was able to identify the notion that not having the comma there was "different" from having the comma there, and was able to respond with an argument more structured than "because Perl5 does it." _This_ is why his ideas get implemented. Duh.) [3] Any programmer who doesn't know that they are ignorant are almost certainly instead arrogant. Ignorant of what? Surely we shouldn't assume that we're all ignorant of Perl? What I'm trying to avoid is the apparent need for programmers to degrade every conversation into an I'm-smarter-than-you semantic duel. In the entire history of the Perl6 process, there has been noone here to emerge as God's Perfect Gift to Language Design -- I think the design has been improved repeatedly by the collective thoughts of the group. But nobody, individually, has a very good batting average, so I think nobody is in a position to throw stones. MikeL [4] [1] OK, that's definitely not civil. Which is why I didn't originally say it. [2] Er, that's not great either, but probably in the range of acceptable. [3] Note to self -- remove the 'Duh', and it will be fine. [4] And yes, the irony of needing N paragraphs to try to convince programmers of such a profoundly simple concept is not lost on me. Nor is the fact that it will inevitably fail... Sorry, I hope I didn't offend you. In that last remark I was in no way fingering you; I was simply speaking broadly. Joseph F. Ryan [EMAIL PROTECTED]
Re: Civility, please. (was Re: L2R/R2L syntax)
Sam Vilain wrote: On Sat, 18 Jan 2003 15:10, you wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. In the very young field of programming, aren't we all ignorant amateurs? Perhaps in the grand scheme of things; however, anyone that is redesigning a system should not be ignorant of how the old system worked (even in the slightest degree), in order to know of what to keep and what to throw away. Any programmer who doesn't know that they are ignorant are almost certainly instead arrogant. Ignorant of what? Surely we shouldn't assume that we're all ignorant of Perl? Joseph F. Ryan [EMAIL PROTECTED]
Re: L2R/R2L syntax
Mark J. Reed wrote: On 2003-01-17 at 19:00:04, Simon Cozens wrote: This is plainly untrue. See the "perlsub" documentation, which talks about "creating your own syntax" with the & prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. Well, if even some of the people redesigning the language are ignorant of some of its capabilities, that is an argument for making those capabilities easier to discover, and maybe even more intuitive to use, in the new design. I see it more as the people who are ignorant of the features of Perl5 should go RTFM (Research The Features that they are Making?) The fact that a & in a prototype obviates the following comma is a pretty obscure detail; it's not the sort of consistent behavior I'd want to build around going forward. Why not? Its a syntax that everyone (or at least, most people) seem to like. But as I see it, the real problem being solved by the new syntax is that grep and map can exist solely as methods on some class in the inheritance tree of @arrays, no global functions required. That is a Good Thing. In your opinion. I'll still want to be able to write 1-liners and short scripts. I'm sure perl6 will still be used for things other than large applications. Is it such a sin to want the old syntax? Even if the definition for grep lives in a method, why couldn't there also exist a global function that looks like: sub grep(&code,@array) { @array.grep(&code); } Or even if this function does not exist, there's nothing stopping the compiler from simply aliasing: grep {} @array; to: @array.grep({}); Joseph F. Ryan [EMAIL PROTECTED]
Re: AW: nag Exegesis 2
Luke Palmer wrote: > In Perl 5, > > my int ($one = 0, $two = 1, $three = 2); > > is a fatal error. I could argue for this to change, as to support > better readability (and it would). It's obvious WIM, so why doesn't > it DWIM (disclaimer: cannot be used as an argument for arbitrary > features. Is not a slogan. I repeat, is not a slogan. :) ? The problem is that this couldn't work given the current semantics of the assignment operator. The "return-value" of an assignment is the lhs of the assignment, so my int ($one = 0, $two = 1, $three = 2); ends up becoming: my int (0,1,2); Which, of course, is a fatal error (partly because it doesn't make any sense). This is why stuff like: if (defined ($child = fork)) { } Works as expected. The point that I am trying to get at is: just because it is obvious WIM to a human reader doesn't mean that it will be easy for a compiler to figure out, especially when the rest of the language works a different way. List assignment is much easier to read anyways. Joseph F. Ryan [EMAIL PROTECTED] This message was sent using the Webmail System hosted by OARDC Computing Services -- http://webmail.oardc.ohio-state.edu:8080
Re: "my int( 1..31 ) $var" ?
Luke Palmer wrote: >>> From: "Joe Gottman" <[EMAIL PROTECTED]> >>> Date: Fri, 3 Jan 2003 22:25:16 -0500 >>> >>> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes: >>> >>> JG> Speaking of which, is there a run-time test to check if a variable >>> JG> is of >>> JG> integral type? Something like >>> JG> print "date" if ($var is int) && (1 <= $var <= 31); >>> >>> the old standby is: >>> >>> int( $var ) == $var >> >>I'm not sure if this works. >> >> my $var = "0"; # Notice the quotation marks >> print "is integer" if (int($var) == $var); >> >> In the above case int($var) == $var returns true when I would want it to >> return false. Why? It returns true in perl5; 0 certainly is an integer value. > print "date" if $var.isa(int); > print "date" if isa $var: int; > print "date" if $var ~~ int; > > Those should all work. IMO the first reads the best. That will also > work for Cs, as C is a subclass of C (I think). These only determine if $var is of type int or Int. However: my $var = 0; # or my $var = "0"; # or my int $var = 0; # or my num $var = 0; # all 4 cases should print "is integer" print "is integer" if int $var == $var; This should work as a more generic method to test Integer *value*, rather than type, which IMHO is more useful (and more commonly wanted). This message was sent using the Webmail System hosted by OARDC Computing Services -- http://webmail.oardc.ohio-state.edu:8080
Re: Usage of \[oxdb]
Dan Sugalski wrote: At 10:16 PM -0500 12/9/02, Joseph F. Ryan wrote: Dan Sugalski wrote: At 5:11 PM -0700 12/9/02, Luke Palmer wrote: You must remember that the Perl 6 parser is one-pass now. It is? Are you sure? It should be; Doesn't mean it will be. And "should" is an awfully strong word... This is true; however, I don't see where anything would need more than 1 pass, except to reduce complexity in some places. After all, since the parser is to be constructed with regular expressions, then a second pass would only be another use of regular expressions, which means the "second pass" could have been included in the parser in the first place. Of course, the parser isn't close to finish yet; as such, its anyone's guess as to what the final product will be. :) Joseph F. Ryan [EMAIL PROTECTED]
Re: Usage of \[oxdb]
Dan Sugalski wrote: At 5:11 PM -0700 12/9/02, Luke Palmer wrote: You must remember that the Perl 6 parser is one-pass now. It is? Are you sure? It should be; the raw parsed data might be treated with regular expressions in the parse-tree processing stage, but that shouldn't count as a second pass.
Re: Usage of \[oxdb]
Luke Palmer wrote: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Mon, 9 Dec 2002 23:43:44 + Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Content-Disposition: inline From: Nicholas Clark <[EMAIL PROTECTED]> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ On Sun, Dec 08, 2002 at 03:41:22PM +1100, Damian Conway wrote: Nicholas Clark wrote: Well, I was wondering if my function returned "CR", then "\c[$(call_a_func())]" would mean that the "CR" gets run thought the \c[...] conversion and a single byte ("\r") is what ends up in the string. I seriously doubt it. %-) So what will perl6's "" parser do if it is presented with what appears to be a $() interpolation sequence inside some other double quoting construction? 1: Proceed silently (so treating "\c[$(call_a_func())]" as a request for the character literally named '$(call_a_func())'), potentially returning whatever warnings fall out of that second stage 2: Issue a nesting warning when it finds something that seems to be an interpolative construction occurring within another construction, but otherwise carry on 3: Treat it as a syntax error I suspect that the answer is "yes" - ie all of the above, with a warning on nesting interpolative constructions, which can be made fatal, and can be made silent. You must remember that the Perl 6 parser is one-pass now. An interpolating string has a rule set of its own, whose simplified version might look like this: grammar interpolating_string { rule string { " * " } rule string_thing { \$\( \) | \\c \[ .*? \] | } rule character { \\ \\ | \\ " | . } } A fuller version might look like this: (Note that this is with only allowing [] for internal brackets and without accounting for the "balanced-brackets are ok" rule (out of curiousity, is that still allowed?)) grammar Interpolating_String { rule string { $delim := { $delim = %matching{$delim} || $delim } (+) $delim } rule head { (") | qq () ( } rule special_delim { <-[\w\s]> } rule body(Str $delim) { \\ | | | <-[ \\\$\@\%\&$delim ]>* } rule interpolated_variable { * > } rule backslashed_expr { \\Q | \[ > | c \[ \] | \: \[ \] | x \[ >+ \] | x | <[UL]> \[ | 0 | 0 \[ \] | <[ule]> . | . } rule string_set { [ + \] > ]* } rule set($item) { $item [ } rule str_subscript { } rule interpolated_value { \( \) } }
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.
Brent Dax wrote: Joseph F. Ryan: # 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 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. # 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 # # So: # #$var = [1,2,3]; # print "$var"; # print "\n"; # print "$($var.repr)"; # # Might print something like: # # [REF_TO_ARRAY_AT: '0x1245AB'] What's wrong with a Perl 5-esque format for the debugging version? 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 :) # Next, objects: # # Objects should have an AS_STRING method inherited from # UNIVERSAL defined as follows: I'd prefer if we drop the capitals. str() ought to work fine, IMHO. # method AS_STRING() { # return "[CLASS_INSTANCE_OF: '" ~ $self.CLASS() ~ "']"; # } Once again, what's wrong with: 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. Joseph F. Ryan [EMAIL PROTECTED]
Stringification of references and objects.
A big issue that still remains with literals is the stringification of objects and references. In an effort to get the behaviors hammered down, here are a few ideas: First off, references: 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 So: $var = [1,2,3]; print "$var"; print "\n"; print "$($var.repr)"; Might print something like: [REF_TO_ARRAY_AT: '0x1245AB'] [ '1', '2', '3' ] Next, objects: Objects should have an AS_STRING method inherited from UNIVERSAL defined as follows: method AS_STRING() { return "[CLASS_INSTANCE_OF: '" ~ $self.CLASS() ~ "']"; } The AS_STRING method is implicitly called when an object is interpolated within a string. The AS_STRING method can be overloaded within the class if the class's author wants nicer (classier;) output. so: class Normal {} class Special { method AS_STRING() { return qq['one','two',three'] } } my Normal $obj1; my Special $obj2; print $obj1; print "\n"; print $obj2; Should print: [CLASS_INSTANCE_OF: 'Normal'] 'one','two',three'
Re: p6d gatewayed by nntp.perl.org?
Simon Cozens wrote: [EMAIL PROTECTED] (Tim Conrow) writes: I'm not seeing it. My problem, or is it not being mirrored yet? I'm reading it via NNTP. Interestingly, p6d doesn't seem to be listed on lists.perl.org
Re: TERN-discuss mailing list finally available
david wrote: The brazen heresy continues... http://mail.nongnu.org/mailman/listinfo/TERN-discuss Are these people serious? What on earth is the point?
Re: perl6 operator precedence table
Damian Conway wrote: Adam D. Lopresto wrote: Really what I've been wishing for was an operator (or whatever) to let me do an s// without changing the variable. I would hope/expect that that's what the subroutine form of C would do. That is, it takes a string, a pattern, and a replacement string, and returns a new string with substitution performed (without affecting the original string): print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.'; That seems a bit obfuscated; is there any chance the subroutine form could be called C or C?