Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, 3 Dec 2004, Larry Wall wrote: On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote: : This whole issue kind of makes me go 'ugh'. One of the things I like : best about Perl is the amazing simplicity of the input construct. Hmm. while () {...} for .lines {...} Looks like a wash to me. Partly it does. The point is that not only the is simple, but that it is also visually distinctive, which is important IMHO. Obviously the new proposal of unary C= is just as good from this point of view... : Replacing that with something that not only is object oriented, but on : top of that also LOOKS object oriented is bound to be a loss. It's : going to be that bit longer to write, and not the least bit easier to : understand. Really? I dare you to show those two lines to any random computer-literate but non-Perl-speaking stranger and see which one they understand better. Of course they'd understand better the latter, but I think that there's a limit to non-Perl-speaking-people-friendship. After all this may be useful for learning perl, but learning it to a good degree would always involve getting acquainted with quite a lot of typical idioms, so this does not make much of a point IMHO, provided that when a typical user becomes familiar with those idioms he can perceive (i) how good they look in source code (ii) how useful they result in practice. It's all cargo cult at that level anyway, so whether it looks OO or not is really completely immaterial to its usability. Indeed it's not *purely* a matter of looking OO, but of looking yet another more-or-less alphabetic string (yes, even with a prepended point: it's just not as markedly distinctive!). As I said, is deeply etched in Perl programmers' cortex as an input operator. In other words it may well be cargo cult, but not in a totally negative acceptation: I mean... till it works, and works well as it currently does! And I don't buy the nuclear blackmail argument either. I'll start worrying about people switching to Python and Ruby when those languages get a clue about how natural languages work. As far as I know, there's OTOH, as a side note, but not a totally unrelated one, I guess, one should pay some attention not to exaggerate following natural languages principles in designing programming languages: granted, I appreciate their pervasiveness in (current) perl and indeed probably this is one of the reasons I love it. But I think that there are some natural limits to this as well: AFAIK any attempt to overcome them was basically a failure. We want the *right* mixture of conciseness, intutivity, clarity instead. In this sense a construct like while () { ... } really doesn't resamble any natural language construct as far as I can see, but indeed it's an idiom that perl programmers easily become familiar with and like to use... well, I think so! Michele -- I hold a square measuring 10x10 metres away from a person who is standing 100 metres away. I ask them to shoot the square with a high-accuracy gun. Don't stand there holding the square when they are shooting... - Robert Israel in sci.math, Re: Scaling
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Austin Hastings wrote: I'll guess that you're pointing at .:send_one($_); Which supposedly uses topic to resolve .:send_one into $this.send_one. If that works, then I'm happy -- I like being able to control topic and $_ differently. But if Cfor changes topic, then what? OUTER::.:send_one($_); Yuck. I believe it needs to be method send ($self: [EMAIL PROTECTED]) { $self.:send_one(BEGIN); for @data { $self.:send_one($_); } $self.:send_one(END); } While that works (I think it works anyway), its debatable if it's nice or not. The first and last calls to .:send_one shouldn't need the $self, but I put it there because if you use the $self inside the for in a method that short, it's nice and clear to have it outside it as well. I suspect the original example expands the for loop into the equivalent of: for @data - $item { $item.:send_one($item); } And it doesn't take a $larry to figure out that this isn't going to make the compiler very happy, as it's most likely a violation of class access control, I would have thought. So Luke, am I right?
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, 06 Dec 2004 12:22:22 GMT, Smylers [EMAIL PROTECTED] wrote: David Green writes: I guess we could always use prepend/append, pull/pop. No! Cpush and Cpop are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Yeah. Cpush and Cpop are old and glorious ones (asm comes to mind), and Cshift is too (even DOS .bat files used it, AFAIR), and it's a one of the most used perl5 CORE:: ops (it's more common than other three) .. And I like to shift :) the only doubtful word for me is unshift. Althought I would be pretty happy if we leave it as is, Cput is nice and short. but please don't swap meanings of old ops! if old push suddenly would try to unshift something, it could bring some perl5 programmers to hospital.
Re: iteration (was Re: Angle quotes and pointy brackets)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Matt Diephouse) wrote: On Sat, 04 Dec 2004 08:59:24 -0700, David Green [EMAIL PROTECTED] wrote: Cdoes Iterate signifies a role named Iterate. Roles are sort of a mix of interfaces and mixins (as I understand it -- I'm still waiting for E12). So saying a class fulfills a role just means that it provides certain methods. In this case, I was saying class with the Iterate role would provide a C.next method. I thought of that at first, but I don't want to have to call my iterating method next any more than I want to *have* to call my constructor new. But there is a difference in that new is called by some user who is supposed to have read the documentation, whereas next needs to get implicitly called by for. So maybe it really should be a Role. (One can always provide methods with better names that simply call the real .next, .prev, .final, etc. for increased user-friendliness.) eof := final;# is that how to create an alias for a sub/method? We've got while for looping, .next for iterating, and for for doing both in one convenient little shortcut. But for needs to know if it has an iterator or a list. You don't want it iterating over things you didn't want it iterating. In this case, I was suggesting making an, though I suppose something like C$sth.execute could just return one. Well, I was looking at lists as being kinds of iterators. If you want to for over an iterator without actually iterating it, I guess you'd have to make a reference to it or put it inside a list (so the list would be iterated instead). - David iterate: to go around and around, like my head Green
Re: pull put (Was: Angle quotes and pointy brackets)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Luke Palmer) wrote: But what we'd really like to do is: given the user knows what push/pop do, what would they *guess* to mean shift (I tend to think that this is a very good technique for naming). And, well, I'm thinking pull. So it's a toss-up between shift/unshift and put/pull. I think push and pull fairly naturally could be taken to refer to the front of an array; you might even argue that the natural direction for something to pop is away from you (i.e. off the back) The problem I have with push/pull referring to opposite ends is that the same person is doing the pushing and the pulling, so both words ought to apply to the same end of the array (the front end), which violates the comp-sci-y expectations. (And although normally I'm happy to chuck CS jargon out the window, because so much of it is really bad, the push/pop thing goes pretty deep.) Not to mention everyone coming from Perl 6. Though if we had push without pop, that wouldn't be as bad. I guess we could always use prepend/append, pull/pop. You might not guess what they meant, but once you know, I think the meanings are reasonably obvious. (Dislike typing though I may, I'm hesitant to suggest prep and app.) Hm, actually counting letters, prepend is no longer than unshift (and if not a real word, is at least used as one more often than unshift is). In fact, prepend/append/pull/pop altogether are only one letter more than push/pop/shift/unshift. So those are now officially my preferred replacements. But if we want something that makes it immediately obvious what end of the array we're messing with.. something visually obvious... ooh, this sounds like a job for Unicode!! (Just kidding. Sort of.) We've already got those lovely pipe operators to build on, and they can already do assignment; if you can go from = to +=, why not from == to +==? @a == $foo, $bar; # @a=($foo, $bar) $foo, $bar == @a; # ditto @a +== $foo, $bar; # push @a, $foo, $bar $foo, $bar ==+ @a; # unshift @a, $foo, $bar @a -== $foo, $bar; # ($bar, $foo) = (pop @a, pop @a) $foo, $bar ==- @a; # ($foo, $bar) = (shift @a, shift @a) The + or - tells you whether you're adding on or taking away, and the arrow points to (or from) the end of the array you're doing it to. (I know some people will hate four symbols in a row. That's why we have seven-letter alternatives like prepend.) I was going to say an advantage over old-fashioned pop/shift is that you could remove more than one element at a time, but there isn't any reason for their P6 versions not to return as many items as are want()ed, is there? The bad news (assuming anyone actually thinks there's anything good in the above suggestion) is that since +== and friends are assignment operators, you can't just do foobar( @a-==, $x, $y). Um, unless -== could be made to work as a unary operator. Which even I don't think I like. =) So we should keep the wordy versions too. -David pull goes the weasel Green
Re: pull put (Was: Angle quotes and pointy brackets)
David Green writes: I guess we could always use prepend/append, pull/pop. No! Cpush and Cpop are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Smylers
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Larry Wall wrote: But here's the kicker. The null filename can again represent the standard filter input, so we end up with Perl 5's while () {...} turning into for = {...} Two more issues: idiom, and topification = Topification: There are cases in P5 when I *don't* want while () {...} but prefer while ($input = ) {...} so that I can have something else be the topic. Every example to date has used Cfor: for .lines {...} but that sets the topic. I'm a little fuzzy on this, but doesn't Cfor play topic games even in this? for .lines - $input { ... $input ... } That is, even though $_ remains unaffected, doesn't this affect smartmatch etc.? = Idiom: The other concern is idiom. Using Cfor suggests start at the beginning, continue to the end. OTOH, using Cwhile is a little weaker -- keep doing this until it's time to stop. Obviously they'll usually be used in the same way: for = {...} vs. while () {...} This seems a subtle concern, and maybe it's just my latent fear of change making me uncomfortable, but I actually *think* in english -- not that it does much good -- and this isn't how I think. Can we ditch Cfor in the examples in favor of Cwhile, for a while? :) =Austin
Re: pull put (Was: Angle quotes and pointy brackets)
Smylers wrote: Larry Wall writes: But then are we willing to rename shift/unshift to pull/put? Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. No! But I'd be willing to rename them to get/put. 'Pull' is the opposite of 'push', but 'pop' already works. Given the nature of many of the other changes in Perl 6, completely changing regexps for example, renaming a couple of functions seems minor. Agreed. Smylers =Austin
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote: for = {...} I dub the...the fish operator! :-) David
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Mon, Dec 06, 2004 at 09:06:22AM -0800, David Wheeler wrote: : On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote: : :for = {...} : : I dub the...the fish operator! : : :-) Mmm. Next thing you'll know, people will name their files oddly just so they can write things like: for =///º {...} for =|||' {...} for =###* {...} for =]]]° {...} for =)))º {...} Larry
Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : Two more issues: idiom, and topification : : = Topification: : : There are cases in P5 when I *don't* want : : while () {...} : : but prefer : : while ($input = ) {...} : : so that I can have something else be the topic. Every example to date : has used Cfor: : : for .lines {...} : : but that sets the topic. I'm a little fuzzy on this, but doesn't Cfor : play topic games even in this? : : for .lines - $input { ... $input ... } : : That is, even though $_ remains unaffected, doesn't this affect : smartmatch etc.? Currently it does. There have been some rumblings in the design team that maybe it shouldn't. But it occurs to me that this might be another spot to have our cake and eat it to. We could say that for @foo - $input { ... $input ... } doesn't set the topic in the block by default. However, methods do set the topic (though there have been rumblings about that too). So we could simply say that pointy subs can also be pointy methods if you specify an invocant: for @foo - $input: { ... $input and $_ ... } I think I like that, but it needs to be thunk about some more. The downside is that it's rather subtle. The upside is that it falls out of existing rules, and lets - map more naturally in the way people expect. I don't think people will naturally expect - to clobber $_. Larry
while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : = Idiom: : : The other concern is idiom. Using Cfor suggests start at the : beginning, continue to the end. OTOH, using Cwhile is a little : weaker -- keep doing this until it's time to stop. Obviously they'll : usually be used in the same way: : : for = {...} vs. while () {...} : : This seems a subtle concern, and maybe it's just my latent fear of : change making me uncomfortable, but I actually *think* in english -- not : that it does much good -- and this isn't how I think. : : Can we ditch Cfor in the examples in favor of Cwhile, for a while? :) Okay. Have an example: while =$IN - $line {...} I think that works. I'm back to thinking unary = in scalar context iterates like p5's , and you should use extraordinary means to get extraordinary results: while file $IN - $blob {...} while slurp $IN - $bigblob {...} Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Or even the dead fish operator: while =###x - $net {...} And here's a flounder: while =: Larry
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: : But I'd be willing to rename them to get/put. If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
David Wheeler wrote: On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote: for = {...} I dub the...the fish operator! :-) Back before there was a WWW, I used an editor called tgif. It was written in france, and part of the idiom was to have two GUI buttons showing respectively the head ( * ) and tail ( ( ) parts of a fish. This were graphical images, please forgive my poor ascii drawing. It took me a while to figure it out, but it was a cute bit of bilingualism. (Or perhaps it was a bit of bilingual cute-ism...) =Austin
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Larry Wall writes: Currently it does. There have been some rumblings in the design team that maybe it shouldn't. But it occurs to me that this might be another spot to have our cake and eat it to. We could say that for @foo - $input { ... $input ... } doesn't set the topic in the block by default. However, methods do set the topic (though there have been rumblings about that too). So we could simply say that pointy subs can also be pointy methods if you specify an invocant: for @foo - $input: { ... $input and $_ ... } I think I like that, but it needs to be thunk about some more. The downside is that it's rather subtle. The upside is that it falls out of existing rules, and lets - map more naturally in the way people expect. I don't think people will naturally expect - to clobber $_. Considering that I was the rumbler, I'll try to stay concise. Don't think that this is anything more than a stormy brain, though. I really like the fact that for always topicalizes. I like it because it forces refactors where they ought to be happening. I always get confused when I see: for (@array) { for my $row (@{$data-[$_]}) { for my $element (@$row) { foobar($_) if $element; } } } It works that way in natural languages too. If you try to use it too remotely, you just confuse everybody. In particular: For each element in @array, look up the corresponding $row in $data, and for each $element in the $row, call foobar on it if $element is true. Call foobar on what? The remaining problem is what to do about unary dot. Repeated here for the, er, benefit? of p6l: class Duple { has $.left; has $.right; method perform (oper) { oper($.left); oper($.right); } } Let's change that into a Tuple class: class Tuple { has @.elems; method perform (oper) { for @.elems { .perform($_); } } } Can you find the mistake? Luke
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote: On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : Can we ditch Cfor in the examples in favor of Cwhile, for a while? :) Okay. Have an example: while =$IN - $line {...} I think that works. I'm back to thinking unary = in scalar context iterates like p5's What would these do? while =$IN - $l1,$l2 {...} while =$IN - @x {...} That first one seems particularly useful. I'm not exactly sure what the second one should do, but it seems like it should be similar to { my @x = $IN.slurp; ... } Can it be that unary = in n-ary context iterates like p5's except when n == Inf or n == 0 (which are list and void context I guess) ? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: pull put (Was: Angle quotes and pointy brackets)
If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. But get has too strong a class accessor connotation in most OO. unpull? ;-)
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote: : On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote: : On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : : Can we ditch Cfor in the examples in favor of Cwhile, for a while? :) : : Okay. Have an example: : : while =$IN - $line {...} : : I think that works. I'm back to thinking unary = in scalar context iterates : like p5's : : What would these do? : : while =$IN - $l1,$l2 {...} : while =$IN - @x {...} : : That first one seems particularly useful. I'm not exactly sure what : the second one should do, but it seems like it should be similar to : { my @x = $IN.slurp; ... } The Cwhile statement is not an arbiter of lists. It want a scalar value that can play the bool role. Assuming that $IN is really $*IN, they would both fail because you're trying to bind a scalar string to a signature that doesn't accept a single scalar string. It would be exactly like sub foo($I1, $I2) {...} foo(#!/usr/bin/perl\n); # missing $I2 sub bar(@x) {...} bar(#!/usr/bin/perl\n); # Trying to bind non-string to @x That being said, if =$iterator returns a list of array references, the second one would work. I don't see any way to make the first one work. : Can it be that unary = in n-ary context iterates like p5's except : when n == Inf or n == 0 (which are list and void context I guess) ? You mean slurps all the values and then throws away all but n of them? That's how p5's currently behaves. Or did you mean scalar ? In any event, I don't think Cwhile is ever going to provide an n-ary context to whatever it wants a boolean value from. That's what Cfor is for. Larry
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:59:18AM -0800, Larry Wall wrote: On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote: : On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote: : On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : : Can we ditch Cfor in the examples in favor of Cwhile, for a while? :) : : Okay. Have an example: : : while =$IN - $line {...} : : I think that works. I'm back to thinking unary = in scalar context iterates : like p5's : : What would these do? : : while =$IN - $l1,$l2 {...} : while =$IN - @x {...} : : That first one seems particularly useful. I'm not exactly sure what : the second one should do, but it seems like it should be similar to : { my @x = $IN.slurp; ... } The Cwhile statement is not an arbiter of lists. Okie. In any event, I don't think Cwhile is ever going to provide an n-ary context to whatever it wants a boolean value from. That's what Cfor is for. Somehow I knew you were going to say that. I'm just being reluctant to use Cfor for something I've been using Cwhile for all this time. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: pull put (Was: Angle quotes and pointy brackets)
Dan Brian wrote: If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. But get has too strong a class accessor connotation in most OO. unpull? ;-) pushf/popf. f is for front. But I still don't see anything wrong with shift/unshift. I'd prefer to avoid having a group of words that all mean about the same thing, but keeping them straight requires some memory trick. I program in too many languages to keep my mnemonics straight. There's going to be enough fun with is/has/does/but. For reference, I always have to do a 'perldoc perlvar' when I need a P5 $punct. -- Rod Adams
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 01:25:29PM -0600, Rod Adams wrote: Dan Brian wrote: If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. But get has too strong a class accessor connotation in most OO. unpull? ;-) pushf/popf. f is for front. Ew! I'd prefer :head/:tail modifiers to push/pop over that. But ... But I still don't see anything wrong with shift/unshift. Neither do I. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : If I went with get, the opposite would be unget for both historical : and huffmaniacal reasons. : : But get has too strong a class accessor connotation in most OO. : : unpull? ;-) Given the existence of a unary = for abbreviated use, I'd probably stick with shift/unshift. (Presumably changing the semantics of shift from p5 to be list/scalar/n-ary context sensitive, so you'd have to write scalar shift to get Perl 5's shift semantics in list context.) Though it's awfully tempting to fill in the holes in the periodic table: ($a, $b, $c) = @foo * 3; And then just say all the corresponding unaries default to 1 (or the arity of the left): $bit = + $number; # $number + 1 $graph = ~ $string; # chip()/chimp() $whether = ? $boolean;# presumably clears $boolean $elem = * $iterator; # shift $iterator That would mean that we couldn't use those unaries in front of ... though. I suppose unary * would mean pop. Blurch. Let's stick with the binaries, if we add 'em at all. I do think foo( @bar * 3 ) foo( @bar * 3 ) might actually be clearer than foo( splice(@bar,0,3) ) foo( splice(@bar,-3,3) ) Also, note that neither of the latter examples means the same as foo( pop(@bar,3) ) since pop would presumably pop them in reverse order from splice. We also get all the rotates if we allow * and *. On the other hand, if anyone suggests a list xor: @foo *^ @bar I'll ask whether they mean @foo »+^« @bar @foo »~^« @bar @foo »?^« @bar @foo »*^« @bar Larry
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote: The remaining problem is what to do about unary dot. Repeated here for the, er, benefit? of p6l: class Duple { has $.left; has $.right; method perform (oper) { oper($.left); oper($.right); } } Let's change that into a Tuple class: class Tuple { has @.elems; method perform (oper) { for @.elems { .perform($_); } } } Can you find the mistake? Well it's not using oper on the elems anymore. method perform (oper) { for @.elems { oper($_); } } But I don't think that was the mistake you were talking about. And I don't see what it has to do with unary dot either, because you don't need to use unary dot to implement that method. Unless each member of @.elems is a Duple, in which case the class isn't one I'd call Tuple. Sorry, nitpicking level seems to be set to 9 at the moment. What did you mean?
Re: pull put (Was: Angle quotes and pointy brackets)
Larry Wall wrote: On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : If I went with get, the opposite would be unget for both historical : and huffmaniacal reasons. Why? (I get the huffman, not the history.) Is it just a nod to unshift? Given the existence of a unary = for abbreviated use, I'd probably stick with shift/unshift. (Presumably changing the semantics of shift from p5 to be list/scalar/n-ary context sensitive, so you'd have to write scalar shift to get Perl 5's shift semantics in list context.) What about add/remove? sub unshift(@a, [EMAIL PROTECTED]) { @a.add(@items); } We could add :head and :tail, with :head the default, and let push|pop be equivalent to (add|remove).assuming(tail = 1) As a side note, other than historical consistency, is there a good reason for push/pop to use the end of the array? I'd argue that for a stack, you only want to know one address: @stack[0] -- the 'top' of the stack -- and if you ever iterate a stack you're inclined to see the items in distance-from-top order, making 0..Inf the right array sequence. If we're going to reorg the function space, let's huffmanize the stack stuff (push/pop/0) and let the other stuff go hang. =Austin
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 03:50:42PM -0500, Austin Hastings wrote: : Larry Wall wrote: : : On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : : If I went with get, the opposite would be unget for both historical : : and huffmaniacal reasons. : : : Why? (I get the huffman, not the history.) Is it just a nod to unshift? Try man ungetc. : Given the existence of a unary = for abbreviated use, I'd probably : stick with shift/unshift. (Presumably changing the semantics of : shift from p5 to be list/scalar/n-ary context sensitive, so you'd : have to write scalar shift to get Perl 5's shift semantics : in list context.) : : : What about add/remove? Backwards Huffman, considering removal happens more often. : sub unshift(@a, [EMAIL PROTECTED]) : { : @a.add(@items); : } : : We could add :head and :tail, with :head the default, and let push|pop : be equivalent to (add|remove).assuming(tail = 1) remove is a transitive verb. I think people would take remove to be remove any occurrences of, and in the absence of any obvious direct object, remove this array, or remove the list of files in this array. : As a side note, other than historical consistency, is there a good : reason for push/pop to use the end of the array? I'd argue that for a : stack, you only want to know one address: @stack[0] -- the 'top' of : the stack -- and if you ever iterate a stack you're inclined to see the : items in distance-from-top order, making 0..Inf the right array : sequence. If we're going to reorg the function space, let's huffmanize : the stack stuff (push/pop/0) and let the other stuff go hang. For indexable arrays, the front is what you want to nail down, but that means it's difficult to make unshift efficient. Swapping push/pop for shift/unshift would make push/pop rather inefficient. And the top of your stack can just as easily be @stack[-1] as it is now. I don't see much reason to change what we have currently unless we decided shift was too long, and it isn't if we have unary = for interators, and real function args to take away most of my $arg = shift;. Appearances to the contrary notwithstanding, I'm not trying to break Perl 5 constructs just for the heck of it. Larry
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Matthew Walton writes: Luke Palmer wrote: The remaining problem is what to do about unary dot. Repeated here for the, er, benefit? of p6l: class Duple { has $.left; has $.right; method perform (oper) { oper($.left); oper($.right); } } Let's change that into a Tuple class: class Tuple { has @.elems; method perform (oper) { for @.elems { .perform($_); } } } Can you find the mistake? Well it's not using oper on the elems anymore. That's mostly because I really screwed up the example. Mind, it was very, very early in the morning when I wrote this. Let's try again. (This is a pretty trivial example, but the problem only gets worse as we approach real life). class MyStream { has $.stream; method :send_one ($item) { $.stream.send($item); } method send ([EMAIL PROTECTED]) { .:send_one(BEGIN); for @data { .:send_one($_); } .:send_one(END); } } Luke
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote: class MyStream { has $.stream; method :send_one ($item) { $.stream.send($item); } method send ([EMAIL PROTECTED]) { .:send_one(BEGIN); for @data { .:send_one($_); } .:send_one(END); } } I'll guess that you're pointing at .:send_one($_); Which supposedly uses topic to resolve .:send_one into $this.send_one. If that works, then I'm happy -- I like being able to control topic and $_ differently. But if Cfor changes topic, then what? OUTER::.:send_one($_); Yuck. =Austin
Re: pull put (Was: Angle quotes and pointy brackets)
stuff grab :-) -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: : But I'd be willing to rename them to get/put. If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. Larry
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall [EMAIL PROTECTED] wrote: Though it's awfully tempting to fill in the holes in the periodic table: ($a, $b, $c) = @foo * 3; And then just say all the corresponding unaries default to 1 (or the arity of the left): $bit = + $number; # $number + 1 $graph = ~ $string; # chip()/chimp() $whether = ? $boolean;# presumably clears $boolean $elem = * $iterator; # shift $iterator Well, that's interesting. I suppose unary * would mean pop. Blurch. Let's stick with the binaries, if we add 'em at all. I do think foo( @bar * 3 ) foo( @bar * 3 ) Hrm... if you're thinking of going that way, I'd rather have a lazy-assignment/destructive-pipe operator of some sort: ($a,$b) == [EMAIL PROTECTED]; # splice(@bar, 0, 2) ($a, $b) == [EMAIL PROTECTED] # splice(@bar, 0, 0, $a, $b) [EMAIL PROTECTED] == ($a, $b); # splice(@bar, -2) [EMAIL PROTECTED] == ($a, $b); # splice(@bar, @bar, 0, $a, $b); Of course, with something indicating the desire to modify the array. I don't know that [EMAIL PROTECTED] would be right for that, but I dunno. Just an idea. I'd want some way of telling the array to lazily add/remove elements as part of the pipe operator, which would make: foo == [EMAIL PROTECTED]; # REMOVE however many elements from the front of @bar as foo() wants However, this would lead to me thinking about this sequence: [EMAIL PROTECTED] == map == grep == @whatever; as: while pop @this { ... unshift @that, $_ } Which would be interesting (bad) for performance Ashley
Re: pull put (Was: Angle quotes and pointy brackets)
Dan Brian writes: If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. When it comes to adding and removing elements, shouldn't there be semantic opposition for functions that operate on the same end? I don't think that's a good time. It kills the array-as-stack idiom, which, well, everybody uses all the time. I don't mind the linguistic nonopposition of pull/put. The main thing I don't like is the alliteration between push/pop. That makes for very difficult mnemonics. Obviously, the CS-literate can just remember that they're the nonstack ops, but many Perlers are Shellers and Adminers, without being CSers. I've actually been happy with shift/unshift. But what we'd really like to do is: given the user knows what push/pop do, what would they *guess* to mean shift (I tend to think that this is a very good technique for naming). And, well, I'm thinking pull. So it's a toss-up between shift/unshift and put/pull. Luke
Re: Angle quotes and pointy brackets
On Thursday, December 2, 2004, 10:08:31 AM, you (mailto:[EMAIL PROTECTED]) wrote: On Tue, 30 Nov 2004, Austin Hastings wrote: How about just having C system() return a clever object with .output and .err methods? interesting... Michele Prior art of this on Windows... http://msdn.microsoft.com/library/en-us/script56/html/wslrfExecMethod.asp (the respective properties on the returned WshScriptExec instance being .StdOut and .StdErr.) -- Richard mailto:[EMAIL PROTECTED]
Re: pull put (Was: Angle quotes and pointy brackets)
If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending shell heritage. That actively opposes sixty years of computer science terminology setting push and pop in opposition. I'm not objecting to pop, but pull in opposition to push, on the other side of the array.
Re: pull put (Was: Angle quotes and pointy brackets)
Dan Brian writes: Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. Now instead of a piano imagine one of those conveyor belts that you get at supermarket checkouts: you push your goods on one-end, and the cashier pulls them off the other. When the cashier pulls one item off that unbreaks the light beam to the sensor, which triggers the motor, and all the other items get pulled along too, moving one place along. Smylers
Re: pull put (Was: Angle quotes and pointy brackets)
It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. As a mnemonic for remembering which side push/pull operate on, I agree. (A stalled car etc.) It would be nice if the corresponding functions could similarly be opposed without the potential confusion for beginners, but I realize that may not be possible, and your example is at least convincing that it's better than shift/unshift.
Re: pull put (Was: Angle quotes and pointy brackets)
Larry Wall writes: But then are we willing to rename shift/unshift to pull/put? Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. Given the nature of many of the other changes in Perl 6, completely changing regexps for example, renaming a couple of functions seems minor. Smylers
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Okay, maybe I should have gone to bed, but I kept thinking about this. I'm starting to suspect it's time to haul out the operator I've been holding in reserve for lo these many years now, the unary =. Suppose we say that it iterates iterators, but also it recognizes certain things that aren't iterators and turns them into iterators and iterates them. So you can say for =$*IN {...} for =$*ARGS {...} if you like, but it also recognizes filenames, and lists of filehandles, and lists of filenames, and in list context turns them into lists of lines: for =foo.c {...} for =foo.c foo.h {...} for =«$foo.c $foo.h» {...} for =['foo.c', 'foo.h'] {...} for =['.myrc', @*ARGS] {...} for [EMAIL PROTECTED] {...} You can think of the = as a picture of the lines in the file, and read it lines of. Well, in list context anyway. In scalar context, it would do a slurp: $file = =foo.c; But here's the kicker. The null filename can again represent the standard filter input, so we end up with Perl 5's while () {...} turning into for = {...} It's just all the magic is done by the = operator rather than the , which is just a plain old ordinary null string inside newfangled angle quotes. I suppose =() or =[] or = would work just as well, but somehow = is what I expect convention to settle on, for certain values of hysterical and raisins. And yes, I've looked at every other character on the keyboard, and several that aren't on the keyboard. And no, I don't think it'll cause many parsing difficulties since we changed the parsing rules on methods to require parentheses if there are arguments. It's only a problem after 0-or-1-ary operators, and not really a problem there, since the default is to look for a term, and there aren't many 0-or-1-ary operators you'd want to assign to anyway. In particular, you can say things like: print =foo.c; And I don't think it'll be visually confusing to people who put spaces on both sides of their assignment operators. Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote: : Might even just be a global multi sub that defaults to $*ARGS: : : multi sub *lines (IO ?$handle = $*ARGS) {...} : multi sub *lines (Str $filename) {...} : multi sub *lines (IO @handle) {...} : multi sub *lines (Str @filenames) {...} : : Then the filter call would be quite hypoallergenic: : : for lines {...} Except that won't parse right, drat it. It won't know whether to expect a term or an operator at the left bracket. Can't use a 0-or-1-ary as the last thing in the list. That was the advantage of .lines, which we could tell had no arguments, since methods with arguments must use parens. Don't wanna go back to bare * either; I've since made it a synonym for Any. Plus it also suffers the 0-or-1 problem. It would still work as a unary, if we can figure out something really short to mean $*ARGS. [Much bogus random brainstorming deleted.] Well, I just need to think about it some more. I've already believed six impossible things after dinner, so maybe I'd better go to bed. Larry
Re: iteration (was Re: Angle quotes and pointy brackets)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Matt Diephouse) wrote: What I mean is that Perl takes an array and makes an iterator out of it. Sure, you probably don't think about it like that, but the behavior is the same (who says arrays need to iterate starting at element zero?). I probably didn't, but over the last couple of days I've been thinking about it like that more and more. The odd thing is that here we are designing Perl 6, and we're trying to take an iterator and make it into an array so that we can turn it back into an iterator again. It seems like we should just use it as an iterator:: for $iterator - $elem { ... } Yes! Supposing class Filehandle does Iterate; # Iterate or Iterator? we have an easy way to create new iterators. I'm not sure how useful they would be in Perl 6 Maybe the class doesn't do it, but one of its methods does? Then you can call it whatever makes sense. class Filehandle { method next is iterator {...} } class Monarch { method succeed is iterator {} } class Blockbuster { method sequel is iterator { $.title++; return $self; } } (how do iterators compare to lazy lists?) Aren't lazy lists a funny kind of iterator? Ones that memoise their results. And supply an indexing method []. Which be even cuter like this (I think): for iter($sth.execute) - $results { ... } where iter creates an Iterator object that just knows to call C.next on its argument. That still seems too cumbersome to me. Isn't it for that knows to call .next (or .sequel, whatever)? I'm thinking that that is the point of for $foo, which should be approximately the same as while $foo.next. We've got while for looping, .next for iterating, and for for doing both in one convenient little shortcut. So lists and arrays would be iterators, although they may not flaunt it in public. But you could always explicitly call their .next method if you wanted to. For example, for @lines { if s/\\$// # ends with a backslash = continued on next line { $_ ~= @lines.next; redo; } # now process our joined line ... } Of course, that's just the example for redo from the Camel, except using an array instead of . A P5 array wouldn't have worked, because there's no way to get the next iteration of an array in the way that you can use a scalar to read the next line of the file. (Though there ought to be a better way of referring to the object of the for -- I had to refer to it by name here, but I couldn't do that if it were a list; and $_ is already taken. @_ strikes me as reasonable (for a not necessarily very large value of reasonable).) I'm not sure how much extra syntax is needed. Something that's expected to iterate (like a filehandle) should just iterate naturally when used in scalar context, or list context, or both. (But a filehandle might stringify to the filename in string context, and return the filehandle object itself when being passed to a function looking for a filehandle.) Something that isn't typically expected to iterate (like an array) could use its .next method, which is a tad wordy, but that's good because that makes it clear and obvious that we are explicitly iterating. Presumably you could slurp up all the iterations at once using * or ** to flatten them. That still doesn't get us the magical because it's really a double iteration (over the filenames in @ARGS and then over the contents of each file). In fact, that's just a specific case of wanting to loop through several iterators -- Cfor $iter1, $iter2, $iter3 {...} only loops through the *list* of iterators, not through each object itself. So maybe we do need Larry's new [EMAIL PROTECTED] to get that kind of double-iteration (without having to nest for loops, ugh!). Hm. Unless the flattening operator will take care of that. Cfor *$iter1, *$iter2, *$iter3 {...} would do it, but I'm not sure about Cfor [EMAIL PROTECTED] {...}. (It would definitely do *something*, of that I'm fairly confident!) But I'm starting to think I may have just been thinking the original problem all along, only inside-out Hoping I haven't removed all doubt of my foolishness, I'm hoping this reply reassures you. - David at risk of removing all doubts of mine Green
Re: iteration (was Re: Angle quotes and pointy brackets)
On Sat, 04 Dec 2004 08:59:24 -0700, David Green [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Matt Diephouse) wrote: Supposing class Filehandle does Iterate; # Iterate or Iterator? we have an easy way to create new iterators. I'm not sure how useful they would be in Perl 6 Maybe the class doesn't do it, but one of its methods does? Then you can call it whatever makes sense. Cdoes Iterate signifies a role named Iterate. Roles are sort of a mix of interfaces and mixins (as I understand it -- I'm still waiting for E12). So saying a class fulfills a role just means that it provides certain methods. In this case, I was saying class with the Iterate role would provide a C.next method. Which be even cuter like this (I think): for iter($sth.execute) - $results { ... } where iter creates an Iterator object that just knows to call C.next on its argument. That still seems too cumbersome to me. Isn't it for that knows to call .next (or .sequel, whatever)? I'm thinking that that is the point of for $foo, which should be approximately the same as while $foo.next. We've got while for looping, .next for iterating, and for for doing both in one convenient little shortcut. But for needs to know if it has an iterator or a list. You don't want it iterating over things you didn't want it iterating. In this case, I was suggesting making an, though I suppose something like C$sth.execute could just return one. Hoping I haven't removed all doubt of my foolishness, I'm hoping this reply reassures you. Thanks. -- matt diephouse http://matt.diephouse.com
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 4 Dec 2004 01:37:00 -0800, Larry Wall [EMAIL PROTECTED] wrote: for =$*IN {...} for =$*ARGS {...} Yay. A generalised form of the input operator, which can create even handier idioms for simple file processing. Maybe I wasn't clear enough. My issue wasn't specifically with '.lines' for filter behaviour -- as a replacement solely for the while () { ... } idiom, it would be quite adequate. But as a replacement for OPENEDFILE, it is (IMO) sub-par, and definitely does add to the length of the whole. As for the nuclear blackmail argument: One of the prime reasons I like Perl is that different things look different. When everything starts looking like a method call, that distinction rapidly drops away. $file = =foo.c; Huh. That's really kinda neat. But here's the kicker. The null filename can again represent the standard filter input, so we end up with Perl 5's while () {...} turning into for = {...} Which is really short for 'for [EMAIL PROTECTED] {...}', then? -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Larry Wall wrote: So you can say for =$*IN {...} for =$*ARGS {...} for =foo.c {...} for =foo.c foo.h {...} for =«$foo.c $foo.h» {...} for =['foo.c', 'foo.h'] {...} for =['.myrc', @*ARGS] {...} for [EMAIL PROTECTED] {...} for = {...} The simplicity is nice, but the visual message is, well, icky. It might be salvageable by having the ='s balance, yielding: for =$*IN= {...} for =$*ARGS= {...} for =foo.c= {...} for =foo.c foo.h= {...} for =«$foo.c $foo.h»= {...} for =['foo.c', 'foo.h']= {...} for =['.myrc', @*ARGS]= {...} for [EMAIL PROTECTED] {...} for == {...} That looks better. Might even make the trailing = mean something useful like auto-chomp. And I don't think it'll be visually confusing to people who put spaces on both sides of their assignment operators. But those of us who often use the horizontal ws to break up the terms on a line will moderately often not put spaces around our assignments and less thans. Okay, this rant is more about the \s\s than \s=\s. To me, it is easier to understand the grouping of line 1 than line 2 below: if( $a$b $c$d ) {...} if( $a $b $c $d ) {...} In line2, my mind has to stop and ask: is that ($a $b) ($c $d), or $a ($b $c) $d. It quickly comes to the right answer, but the question never comes up in the first line. If I wanted to use more parens for clarity, I'd use LISP. -- Rod Adams
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Rod Adams writes: Okay, this rant is more about the \s\s than \s=\s. To me, it is easier to understand the grouping of line 1 than line 2 below: if( $a$b $c$d ) {...} if( $a $b $c $d ) {...} In line2, my mind has to stop and ask: is that ($a $b) ($c $d), or $a ($b $c) $d. It quickly comes to the right answer, but the question never comes up in the first line. If I wanted to use more parens for clarity, I'd use LISP. This is Perl. TMTOWTCI (Clarify It). if ($a $b) ($c $d) {...} if $a $b and $c $d{...} if $a $b$c $d {...} In particular, you need to ask yourself which you'd rather have: $a$b with %hkey $a $b with %hkey But you might actually have to ask yourself. I'm still not sure... (and I'm not even paying attention to the left side). Luke
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote: On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote: : This whole issue kind of makes me go 'ugh'. One of the things I like : best about Perl is the amazing simplicity of the input construct. Hmm. while () {...} for .lines {...} Looks like a wash to me. This is a neat win, keyboards favorise alphabetic characters that are less excentred. Moreover, in some non qwerty layout, to make place for diacritic characters, some non alphabetic characters are less accessible, shift or alt-gr is necessary to type them. Having being used to qwerty keyboards, on a french keyboard, I switch from azerty to qwerty to program in C or Perl because of their heavy ratio nonalpha/alpha. But most programmers use their native keyboard layout. -- stef
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote: Larry Wall wrote: for =$*IN {...} for =$*ARGS {...} for =foo.c {...} for =foo.c foo.h {...} for =$foo.c $foo.h {...} for =['foo.c', 'foo.h'] {...} for =['.myrc', @*ARGS] {...} for [EMAIL PROTECTED] {...} for = {...} The simplicity is nice, but the visual message is, well, icky. It might be salvageable by having the ='s balance, yielding: for =$*IN= {...} for =$*ARGS= {...} hm. we have short and strange FH, for input.. (and for some reason, it is bracketing! there's no sense at all in it) ..but we have long (and even looking slightly OOish, in perl5 sense) print FH for output, and noone complained. We still aint going to have funny syntax for output, and we not going to keep old syntax for input. Why to reintroduce even more strangeness with that unary =, which is actually a simple list operator, which doesn't desire for huffmanizing? I don't think that would hurt anyone for lines file1 file2 file3 {...} # or for files file1 file2 file3 {...} # or for lines @*ARGS {...} # or just that special case: for lines {...} but actually everybody just miss that short and strange while () {...} and how all other handles would be accessed is much less concern. it's just a bad and beloved habit, IMHO. maybe we could make a special case.. (C programmers would be shocked) for () {...}
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote: Okay, this rant is more about the \s\s than \s=\s. To me, it is easier to understand the grouping of line 1 than line 2 below: if( $a$b $c$d ) {...} if( $a $b $c $d ) {...} In line2, my mind has to stop and ask: is that ($a $b) ($c $d), or $a ($b $c) $d. It quickly comes to the right answer, but the question never comes up in the first line. If I wanted to use more parens for clarity, I'd use LISP. I've got used to write it as if( $a $b and $c $d) {...} already. if it could help.. :)
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, Dec 04, 2004 at 11:02:38PM +0300, Alexey Trofimenko wrote: : hm. we have short and strange FH, for input.. (and for some reason, it : is bracketing! there's no sense at all in it) : ..but we have long (and even looking slightly OOish, in perl5 sense) print : FH for output, and noone complained. We still aint going to have funny : syntax for output, and we not going to keep old syntax for input. Why to : reintroduce even more strangeness with that unary =, which is actually a : simple list operator, which doesn't desire for huffmanizing? True, except for the fact that it *is* unary rather than list, so it doesn't require parens to interpolate =$fh into a list. I had been thinking that there should be a long form as well, just as we have both !/not, and ?/true. : I don't think that would hurt anyone : for lines file1 file2 file3 {...} : # or : for files file1 file2 file3 {...} : # or : for lines @*ARGS {...} : # or just that special case: : : for lines {...} But that last one is the one that *doesn't* work if lines is a list operator. List operators always expect a term, and {...} is recognized as a statement block only where an operator is expected. It would be parsed as: for lines({...}) ??? : but actually everybody just miss that short and strange : while () {...} : and how all other handles would be accessed is much less concern. : it's just a bad and beloved habit, IMHO. Definitely beloved. Bad? I dunno. It's definitely visually distinct, and that's why I put it into Perl that way in the first place. The data flow of your program is only partially related to the control flow, and something that is producing asynchronous data needs to stand out. : maybe we could make a special case.. (C programmers would be shocked) : for () {...} I think that should just do nothing, so that a code generator can spit it out without worrying about the special case. I still think the special case is either of for = {...} or for lines {...} at the writer's discretion. But I do like your lines/files distinction, which = doesn't make. Probably if we distinguish them as list operators, we make the unary = only do lines. Then in scalar context it just gives you the next line, which will be more familiar to people coming from FH think. I suppose we could also have for words {...} for tokens {...} for paragraphs {...} for chunks(, :delim(/^^===+\h*\n/)) {...} etc. On the other hand, if we follow the Perl 5 model, maybe = always means chunks, and the filehandle just defaults to chunking into lines like Perl 5's in the absence of a $/ redefinition. Presumably words/tokens/lines/paragraphs/files would just synonyms for chunks in that case. And maybe records/rows for people who don't like chunks. :-) But I think people would expect something like words to override the filehandle's natural chunking proclivities at least temporarily in the case of a scalar input. So I think =$fh means chunks($fh), the natural chunking of the filehandle (defaulting to lines), while the words/files/paragraphs do temporary override of chunking policy. Presumably there are also :words, :files, and :paragraphs adverbs on the opening of the filehandle to set the default chunking. No reason to make them different words. Or maybe they're all args to a single :bywords adverb. And perhaps that also turns on autochomping. Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, Dec 04, 2004 at 11:08:38PM +0300, Alexey Trofimenko wrote: On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote: Okay, this rant is more about the \s\s than \s=\s. To me, it is easier to understand the grouping of line 1 than line 2 below: if( $a$b $c$d ) {...} if( $a $b $c $d ) {...} In line2, my mind has to stop and ask: is that ($a $b) ($c $d), or $a ($b $c) $d. It quickly comes to the right answer, but the question never comes up in the first line. If I wanted to use more parens for clarity, I'd use LISP. I've got used to write it as if( $a $b and $c $d) {...} already. if it could help.. :) I agree with Rod - it is much more readable when there are no blanks around the and there are blanks around the . Typing is not the problem as much as reading, however, I choose the spacing for readability when I type it, deciding what the base chunks are and putting blanks aound the base chunks but not within them. Having a few operators that require spacing will be an extra gotcha to consider in that process, so it will occassionably lead to syntax errors when I don't consider the special rule; but it will still lead to less readable code when I do remember the rule and leave the extra spaces. --
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, Dec 04, 2004 at 01:24:41PM -0800, Larry Wall wrote: : I suppose we could also have : : for words {...} : for tokens {...} : for paragraphs {...} : for chunks(, :delim(/^^===+\h*\n/)) {...} : : etc. I see a problem with for words {...} since there's likely to be a words method on strings. Maybe we want: for fwords {...} Er...on second thought, we probably just have to write: for words = {...} or for words(lines()) {...} instead. And of course, tokens() is silly unless you have defined a lexer. Which leaves paragraphs(), which is not really common enough to do as other than a mod to the filehandle. So it comes back to lines/chunks/files. Larry
Re: iteration (was Re: Angle quotes and pointy brackets)
David Green [EMAIL PROTECTED] wrote: Aren't lazy lists a funny kind of iterator? Ones that memoise their results. And supply an indexing method []. As I mentioned the other day, I fail to see any material difference between an iterator and a lazy list, except that a few operations are allowed on a lazy list that aren't on an iterator. (And all of those could be emulated, albeit inefficiently, with one; even with a pipe, if the user does $pipe[1024], there's no technical reason you can't store the first thousand-odd lines and return the one they asked for.) Also note that there's no difference between iterating over a lazy copy of an array, and iterating over a lazy copy of a lazy copy of an array, except for the amount of indirection; thus, there would be no need for for() to distinguish between Cfor $array and Cfor $iter (though both of those forms might need a splat). -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: pull put (Was: Angle quotes and pointy brackets)
Smylers [EMAIL PROTECTED] wrote: Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. Cunshift's only virtue, IMHO, is that it's clearly the inverse of Cshift. But I think the spelling and aural relationship between Cpush, Cpop, Cpull, and Cput is clear enough to negate that. But then, I'm a little biased. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: pull put (Was: Angle quotes and pointy brackets)
Brent 'Dax' Royal-Gordon wrote: Smylers [EMAIL PROTECTED] wrote: Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. Cunshift's only virtue, IMHO, is that it's clearly the inverse of Cshift. But I think the spelling and aural relationship between Cpush, Cpop, Cpull, and Cput is clear enough to negate that. But then, I'm a little biased. Except that push and pull are logical opposites linguistically, but not in standard CS parlance. could be very confusing. There's a possibility of using Cenq and Cdeq for enqueue/dequeue, except that Cdeq == Cpop in standard implementations. So Cenq and Cshift? yeck. -- Rod Adams
Re: pull put (Was: Angle quotes and pointy brackets)
Cunshift's only virtue, IMHO, is that it's clearly the inverse of Cshift. But I think the spelling and aural relationship between Cpush, Cpop, Cpull, and Cput is clear enough to negate that. But then, I'm a little biased. Except that push and pull are logical opposites linguistically, but not in standard CS parlance. could be very confusing. There's a possibility of using Cenq and Cdeq for enqueue/dequeue, except that Cdeq == Cpop in standard implementations. So Cenq and Cshift? yeck. If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. When it comes to adding and removing elements, shouldn't there be semantic opposition for functions that operate on the same end? (I realize that take is already ... taken, for control structures.)
Re: pull put (Was: Angle quotes and pointy brackets)
On Sat, 4 Dec 2004 23:33:24 -0700, Dan Brian [EMAIL PROTECTED] wrote: If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending shell heritage. That actively opposes sixty years of computer science terminology setting push and pop in opposition. (Well, maybe not *sixty* years, but you get the idea.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote: : This whole issue kind of makes me go 'ugh'. One of the things I like : best about Perl is the amazing simplicity of the input construct. Hmm. while () {...} for .lines {...} Looks like a wash to me. : Replacing that with something that not only is object oriented, but on : top of that also LOOKS object oriented is bound to be a loss. It's : going to be that bit longer to write, and not the least bit easier to : understand. Really? I dare you to show those two lines to any random computer-literate but non-Perl-speaking stranger and see which one they understand better. And actually, .lines *wins* on keystrokes if you count shift keys. : Neither the conceptual input operator nor the extremely : handy idiom for behave like a Unixy filter should go. Please. It's all cargo cult at that level anyway, so whether it looks OO or not is really completely immaterial to its usability. If .lines loses out, it won't be because of any of your arguments, but because $*ARGS maybe shouldn't be the topic of Main. But $*ARGS is most certainly an object of some sort, whether or not we hide that fact from the cargo culters. : If you don't like the angles doing it, by all means take them. But : don't push that far into OO land. There's a reason we aren't all using : Python and Ruby by now. Sounds to me like you're just allergic to dots. And I don't buy the nuclear blackmail argument either. I'll start worrying about people switching to Python and Ruby when those languages get a clue about how natural languages work. As far as I know, there's little notion of topics in those languages as of yet. (Though I wouldn't be surprised if other languages eventually adopt our invocantless .foo notation. For the price of one character, we document exactly which functions default to $_. In Perl 5 you just have to memorize the list.) But as I say, I'm not yet convinced $*ARGS should be the topic. It would only be the topic outside of the main loop, and people would wonder why .lines gives them a different answer in another location. That's the real problem with it. So you'll probably get your wish of some non-OO-looking syntactic sugar. Might even just be a global multi sub that defaults to $*ARGS: multi sub *lines (IO ?$handle = $*ARGS) {...} multi sub *lines (Str $filename) {...} multi sub *lines (IO @handle) {...} multi sub *lines (Str @filenames) {...} Then the filter call would be quite hypoallergenic: for lines {...} Interestingly, though, you can also call it as $fh.lines if you like. Or even if you don't. Larry
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 14:58:13 -0800, Larry Wall [EMAIL PROTECTED] wrote: But then it's not a general iterator iterator. Plus it has the Unicode taint... Back to reality, another thought to weave in here is that something like for $iterator.each - $x {...} might specify that there may be ordering dependencies from loop iteration to loop iteration, whereas (since junctions are inherently unordered) saying: for $iterator.all - $x {...} explicitly tells the system it can parallelize the loop without worrying about interation between iterations. I've been thinking about it, and this strikes me as really odd. Perl 5 is full of nice shortcuts. One of them is: for (@array) { which takes the place of for (my $i = 0; $i @array; $i++) { which is what you'd have to do in a lot of other languages. What I mean is that Perl takes an array and makes an iterator out of it. Sure, you probably don't think about it like that, but the behavior is the same (who says arrays need to iterate starting at element zero?). Java just introduced something similar in 1.5. The odd thing is that here we are designing Perl 6, and we're trying to take an iterator and make it into an array so that we can turn it back into an iterator again. It seems like we should just use it as an iterator:: for $iterator - $elem { ... } Your message leads me to believe that for all(1, 2, 3) - $num { ... } is already a special case that will or can be recognized and optimized. If so, having special behavior for an iterator shouldn't be much more difficult (though I'm not sure of the correctness or full ramifications of this statement). That would have the added benefit of letting me write this: for open($filename) or die - $line { ... } which I like. A method could be used for retrieving the next line/char/byte/whatever: my $fh = open $filename or die; my $line = $fh.next where C.next splits on the input record separator. C.next_byte and family could be implemented on top of that as well. The biggest problem I see (and I may just be blind) is that for $iterator - $x { ... } is slightly ambiguous to the programmer, which makes me want angle brackets back. Other syntax could be used (though we seem to be drawing a blank there), but I don't like the idea of using a method (see Iterator-Array-Iterator above). I also like the idea of general iterators. Really like it. Perl 5 had it via Ctie, but it wasn't so pretty. Supposing class Filehandle does Iterate; # Iterate or Iterator? we have an easy way to create new iterators. I'm not sure how useful they would be in Perl 6 (how do iterators compare to lazy lists?), but I can see if being useful. For instance, perhaps a more idiomatic DBI could be written like this: my $sth = $dbh.prepare('SELECT * FROM foo'); for $sth.execute.iter - $results { ... } Which be even cuter like this (I think): for iter($sth.execute) - $results { ... } where iter creates an Iterator object that just knows to call C.next on its argument. Anyway, take it for what its worth. I'm aware of how ridiculous many of the things we (that includes me) say are, but perhaps I've said something useful. Hoping I haven't removed all doubt of my foolishness, -- matt diephouse http://matt.diephouse.com
Iteration Again (was «Re: Angle quotes and pointy brackets»)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Brent 'Dax' Royal-Gordon) wrote: I'm going to pull a Larry and think out loud for a minute here. Note that I speak authoritatively here, Noted. Or not. =) Treating it like an array is wrong. On the other hand, what if a filehandle *is* an array? What if you can access it randomly and non-destructively? I like this line of thought -- sure, arrays and iterators are different, but they're also similar, so they ought to look similar in at least some ways. We already think of files in a somewhat-array- like manner (Gimme line 42 of this file) rather than mere iterators (Get the first 41 lines of this file, throw them away, and then gimme the next one), so why shouldn't Perl reflect that? Keeping the easy things trivial and all... An iterator can also be quite unlike an array (for instance a pipe, where you can't jump back to the beginning, even inefficiently), but I think those differences apply at a slightly higher level, conceptually. (Or they would if we weren't forced by the language to think of them differently at the lower level.) After all, if you know you're dealing with a pipe, it would probably never even occur to you to try accessing it randomly; on the other hand, if you don't know whether your object is an array or a file or a pipe to begin with, you're already in trouble. But .shift looks a bit awkward. I suggest a name change for .shift and .unshift, so that we have: push, pop pull, put Hm, I like that, the parallelisms with the number of letters, and the way they all begin with P. Plus the meanings make sense (you pull something towards you -- that's the front end -- but when something pops off, it goes flying away from you -- that's the back). So now we have: my $fh=open foo.txt; say $fh.pull; for $fh.pullall { I'm not crazy about pullall. If the idea is we want to slurp up the file right now, can't we use our flattening splatter? (for [EMAIL PROTECTED] ...) And what about iterators in general? Well, if we can do it to filehandles, why not all iterators? An iterator is simply a lazy array copy that isn't accessed randomly; Or maybe a lazy array is just an iterator (with some extra abilities added on). But I'm all for taking advantage of the commonalities. -David which is related to another kind of laziness Green
Re: Angle quotes and pointy brackets
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Smylers) wrote: David Green writes: I'm not even sure what those double-quotation marks are doing -- [...] Look back at how Larry defined the guillemets: [...] So the double-quotes in there are shell-like, though I guess if you don't have a Unix background that doesn't mean much to you. Ah, of course. I read that straight in one eye and out the other. =) -David getting carried away with parallelogies that aren't quite there, but I like the new definition anyway Green
Re: Angle quotes and pointy brackets
Larry Wall wrote: I thought so. : I don't think I've ever used a hash slice in my life. Is there something : wrong with me? No, a lot of people are naturally monoindexous. I like that word. : * The :w splitting happens after interpolation. So : : « foo $bar @baz » : : can end up with lots of words, while : : « foo $bar @baz » : : is guaranteed to end up with three words. : : See the comment about 'fabulouser' above and add another 'and : fabulouser' to the end. I neglected to mention that the smart quoter should also recognize pair notation and handle it. I've been trying to get my brain round that, but I can't quite figure out what you mean. Pair notation is, as I understand it, when you get key = value to construct a pair. Assuming that's me remembering correctly, then where does the smart quoter have to deal with pair notation? Are you considering allowing something like: « key1 = flop key2 = floop » Which would be hash(key1 = flop, key2 = floop); or am I completely off my rocker? I hope I am, because that's kind of ugly. The only other thing I can think of is if you're just talking about *implementing* infix:=, in which case just ignore the above because of course the autoquoter needs to recognise its left-hand-side. As an aside, is it possible for us to define our own autoquoting operators? I assume it will be, but I'm feeling insecure and need reassurance. I neglected to mention that we also naturally get both of: circumfix:« » circumfix:« » in addition to circumfix:{'',''} circumfix:{'«','»'} Have to be careful with circumfix:«{ }» though, since {...} interpolates these days. Yes, that would be fun... almost worth throwing out a compiler warning for that, especially if we've still got use warnings. Something like Warning: «{ }» creates empty list or even Warning: circumfix:«{ }» creates empty operator that one could be an error in fact. or if you're feeling really nasty Syntax error Because I'm sure it should be wrong to create empty circumfix operators. Or am I too prescriptive? My inner Haskell programmer is showing through.
Re: Angle quotes and pointy brackets
Juerd wrote: Matthew Walton skribis 2004-12-01 9:55 (+): Yes, that would be fun... almost worth throwing out a compiler warning for that, especially if we've still got use warnings. Something like Warning: «{ }» creates empty list It should generate a warning similar to the warning of interpolating an undefined value, but with s/undefined variable/empty list/. Yes, that would make sense. Because I'm sure it should be wrong to create empty circumfix operators. You have to admit that zero width circumfix operators would be VERY NEAT. Well that depends... are you intending to write programs, or drive the world insane?
Re: Angle quotes and pointy brackets
Matthew Walton skribis 2004-12-01 10:11 (+): Well that depends... are you intending to write programs, or drive the world insane? Yes. Juerd
Re: Angle quotes and pointy brackets
A request to everyone who wants to discuss this again: please, read the Backticks thread. Almost everything that can be said about this subject has already been said before. It is a huge thread, and let's not copy everything here. Alexey Trofimenko skribis 2004-11-30 14:34 (+0300): but it puts big restrictions on what can be part of the name (actually, thoose which match to ident only), so $package'$varname won't work. I meant only that your ` can't be replacement to « » because latter allows MUCH more freedom in key names. Actually, only space has special meaning here. I suggest that you re-read the Backticks thread of April this year. Summarized in reaction to above snippet: it would not be the only place where Perl's syntax is optimized for the most common use, but has an alternative available. I don't recall ever having said that %hash`key was a *replacement* for %hash«key». so, could you be more explicit, what rules your syntax have? I cannot be much more explicit than in referenced thread, but since you ask specific questions, I will answer them. $a`$b+$c`$d, is it equivalent of $a[$b+$c][$d] or $a[$b]+$c[$d] ? The latter. I intended whetever is seen as a string in Perl 5 $hash{key} to be valid. In general, that is: any valid identifier (except it may start with a digit, and optionally have a - before it). Should you want to play with the syntax, then use Matthijs' patch for Perl 5, which enables the backticks for hash element selection. and I think, polymorphic treating of ` as either {} or [] adds some overhead.. and unstability of your code. Then have it just for hashes. I don't think it is at all true, though. Especially in cases like $a`$b, when compiler just can't see in compiler time, what could be contained in $b - number or string. I suggested deciding based on the value of the RHS once, but no longer support that. The decision should be based on the LHS alone, and if the LHS supports both postcircumfix:«{ }» and postcircumfix:«[ ]», then the {} wins. no spaces allowed, no expressions, and it is always a HASH subscript. No expressions, but a simple atomic scalar variable should be allowed, as is true for methods too: $foo.bar $foo.$bar Re spaces, I don't see any reason to disallow them on either side. They're allowed around . too. Juerd
Re: Angle quotes and pointy brackets
Brent 'Dax' Royal-Gordon wrote: I like this in general. However... Larry Wall [EMAIL PROTECTED] wrote: * Since we already stole angles from iterators, «$fh» is not how you make iterators iterate. Instead we use $fh.fetch (or whatever) in scalar context, and $fh.fetch or @$fh or $fh[] or *$fh in list context. I believe you tried this one a couple years ago, and people freaked out. As an alternative, could we get a different operator for this? I propose one of: $fh - $fh» (and $fh) $fh All three have connotations of the next thing. The first one might interfere with pointy subs, though, and the last two would be whitespace-sensitive. (But it looks like that isn't a bad thing anymore...) Any other suggestions, people? ++$fh
Re: Angle quotes and pointy brackets
Austin~ On Tue, 30 Nov 2004 18:15:54 -0500, Austin Hastings [EMAIL PROTECTED] wrote: Austin Hastings wrote: Larry Wall wrote: And now, Piers is cackling madly at Matt: welcome to perl6-hightraffic! :-) Even if he wasn't cackling, I admit to feeling it. I don't even use the qx/qq/qw stuff in perl5. I always got by with . Although I must admit to liking python's C r... meaning absolutely raw string (useful for avoiding double escape problems with their regular expressions). Left me thinking it was short for regex and not raw for a little while... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Angle quotes and pointy brackets
AH == Austin Hastings [EMAIL PROTECTED] writes: AH Larry Wall wrote: * We get the cute, clean and rather more typeable $varkey1key2[3]key3 AH No more or less typeable for me, or anyone else who can remap their AH keyboard. I'm presuming there's something costly about {} on non-US AH keyboards, but how much does it cost? and do those non-US perl hacks AH use remapping already? i think the diff between $hash and $hash{} is that autoquotes (and only allows) single words and {} requires quote words or expressions. so $hashfoo is the same as $hash{'foo'}. $hash{foo} is either a syntax error or something i can't figure out (foo is a bareword which is illegal IIRC). * People can probably get used to reading things like: $varkey1key2[3]key3 $varkey1key2[4]key3 AH It's just as readable as XML. it is only for fixed token keys and who actually writes hash accesses that deep and very often? i would assign the midlevel hashes to a scalar and work from there if this was common code. AH Carp. AH Carp. AH Carp. main::Carp can't be found. Perhaps you forgot to use the Carp qw(no_carping_at_larry)? :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Angle quotes and pointy brackets
On Tue, Nov 30, 2004 at 02:26:06PM -0800, Brent 'Dax' Royal-Gordon wrote: : Larry Wall [EMAIL PROTECTED] wrote: : * Since we already stole angles from iterators, «$fh» is not : how you make iterators iterate. Instead we use $fh.fetch (or : whatever) in scalar context, and $fh.fetch or @$fh or $fh[] : or *$fh in list context. : : I believe you tried this one a couple years ago, and people freaked : out. As an alternative, could we get a different operator for this? : I propose one of: : : $fh - : $fh» (and $fh) : $fh : : All three have connotations of the next thing. The first one might : interfere with pointy subs, though, and the last two would be : whitespace-sensitive. (But it looks like that isn't a bad thing : anymore...) In lines with the '...' ... and ... ... progressions, the following progression has a nice symmetry: $iter --#extract next (one) element from iterator $iter $iter ==#pipeline all elements (lazy) in turn from iterator $iter However, I haven't been paying a lot of attention, to the current state of affairs, so it is probably broken in some way. --
Re: Angle quotes and pointy brackets
On Tue, Nov 30, 2004 at 06:27:55PM -0500, Matt Fowles wrote: : Even if he wasn't cackling, I admit to feeling it. I don't even use : the qx/qq/qw stuff in perl5. I always got by with . : : Although I must admit to liking python's C r... meaning : absolutely raw string (useful for avoiding double escape problems with : their regular expressions). Left me thinking it was short for regex : and not raw for a little while... Actually, I was thinking about a raw option, so q:r could be it. And it might actually turn out to be useful for quoting rules if for some reason you really don't want to write an rx//. And oddly, it might end up with a qr// shorthand. So we might end up with qr:here'END' for the Perl 6 equivalent to 'END'. Larry
Re: Angle quotes and pointy brackets
On Tue, Nov 30, 2004 at 03:03:38PM -0800, Jon Ericson wrote: : Larry Wall [EMAIL PROTECTED] writes: : : The p5-to-p6 translator will turn any : : while (handle) {...} : : into : : for @$handle {...} : : Including: : : while() {...} : : to : : for @$ {...} : : ? You left out the most important phrase: or whatever we decide is the correctest idiom. So if, as has been pointed out, @$handle is too much role shear, then we probably go with something like for *$handle {...} in which case, if there's no handle, it seems to degrade to for * {...} which seems amazingly something or other. Larry
Re: Angle quotes and pointy brackets
On 11/30/04 9:54 PM, Matt Diephouse wrote: use CGI «:standard»; [...] use CGi :standard; Who is doing this? I'm just saying... use CGI ':standard'; It really ain't all that broke, is it? -John
Re: Angle quotes and pointy brackets
John Siracusa [EMAIL PROTECTED] wrote: On 11/30/04 9:54 PM, Matt Diephouse wrote: use CGI «:standard»; [...] use CGi :standard; Who is doing this? I'm just saying... use CGI ':standard'; And won't we just be doing: use CGI :standard; anyway? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
All the cool kids are thinking aloud these days. Why not jump on the bandwagon? Larry Wall writes: * We get the cute, clean and rather more typeable $varkey1key2[3]key3 It looks like if you shook that up and down a bit, it would break in half. I wonder what would happen if we made a little smarter, as in: * foo ; bar acts as a multidimensional subscript (* but what for @array = foo ; bar?) * +42 returns a number instead of a string. Then: $varfoo ; bar ; +3 ; baz Which is certainly less noisy than the kitkat above. Problems: * -foo is common for options; don't want to force a number. Then again, you don't see -6 as an option too often. * Doesn't solve anything in the practical scenario where some of your keys are not constant. But we'd, of course, do the same thing to . However, there's a problem with : it doesn't generalize to non-string keys (since $foo can reasonably only stringify). That is: $varfoo ; $bar ; +3 Doesn't work if $bar is something unstringly that happens to be the key type of the second dimension. Not to mention that if we allowed semicolon, would be the common one again, and we'd be in for another switcheroo. Anyway, I think there's something wrong with: $varfoobar[3]baz It doesn't hold together visually. This might have some relation to the other problem on my mind: the difference between $, @, and % these days. The rest of the proposal is pretty snazzy, though. Luke
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 19:10:48 -0800, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: John Siracusa [EMAIL PROTECTED] wrote: Who is doing this? I'm just saying... use CGI ':standard'; I normally use qw// when use-ing. *shrug* And won't we just be doing: use CGI :standard; anyway? Yeah, we will; I forgot. :-) I don't use Perl 6 very often (yet). -- matt diephouse http://matt.diephouse.com
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 19:10:48 -0800, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: John Siracusa [EMAIL PROTECTED] wrote: On 11/30/04 9:54 PM, Matt Diephouse wrote: use CGI «:standard»; [...] use CGi :standard; Who is doing this? I'm just saying... use CGI ':standard'; And won't we just be doing: use CGI :standard; anyway? Indeed. Also, someone *ahem* will make the following work, with or without the C. %hash.:foo:bar:baz = 10; Ashley Winters
Re: Angle quotes and pointy brackets
John Siracusa writes: Call me crazy, but at this point I'm prone to stick with what I've done in Perl 5 for years: $var{'key1'}{'key2'}[3]{'key3'} In which case do that, since it'll still work in Perl 6. Actually, it works 'better' in Perl 6, since it doesn't mislead in any way. I've encountered several Perl programmers who feel 'uneasy' about the auto-quoting rules of hash keys, so choose not to bother with them and put all the quotes in as you do above. The trouble with that in Perl 5 is that it gives the impression that the quotes are actually doing something. That then leads to bugs like writing: $log{time} = $msg; where because the programmer has explicitly _not_ used quotes and want to invoke a function rather than use the literal string time. But because in fact the quotes weren't doing anything, removing them doesn't change anything. That awkwardness is fixed in Perl 6: because the quotes _are_ now needed with the C $hash{'key'} syntax when you want to quote, you can not have quotes when you don't want to quote (and Perl will automatically not quote it for you!). So life is better for people who like writing hash subscripts as you do. But for those who like autoquoting, there's now a different syntax, one that doesn't interfere with the above syntax at all. You don't have to use it if you don't want to, and everybody's happy! Smylers
Re: Backticks (was: Angle quotes and pointy brackets)
Juerd writes: Luke Palmer skribis 2004-11-29 16:10 (-0700): http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.orgrnum=1clarify It says that backticks won't be used at all in Perl 6. That's (the) one key of the keyboard that we're leaving to user-definition. It says that, but after saying Leaving aside the use of C`` as a term And that use of backticks is what this subthread appears to be about. As I interpret it, backsticks for qx, unless elsewhere declared gone, are still there. Sorry, I misread. Luke
Re: Angle quotes and pointy brackets
Matthew Walton wrote: James Mastros wrote: Larry Wall wrote: On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote: : ah, I forget, how could I do qx'echo $VAR' in Perl6? something like : qx:noparse 'echo $VAR' ? I think we need two more adverbs that add the special features of qx and qw, so that you could write that: q:x/echo $VAR/ where ordinary qx/$cmd/ is short for qq:x/$cmd/ I think I'd like that much better if we consider execution and word-splitting to be the primary operations, and interpolation and noninterpolation the adverbial modifiers then the other way around, making that qx:q/echo $VAR/ or qx:qq/$cmd/. especially because adverbs are meant to say how to do rather than what to do, aren't they? OTOH, I expect backticks to be rare enough that I wouldn't mind writing use Spawn 'spawn'; spawn :capture :wait ($cmd); spawn :capture :wait ('echo $VAR'); Although I'm masochistic enough that I don't mind the idea of always having to do execution with qx//, qx:q// or qx:qq// (running with other suggestions, I'd guess that would be non-interpolating execution, then the same again more explicitly, then interpolating execution) but I do like the idea of spawn. hm.. qx:q// qx:qq// ...compare with: qx q// qx qq// so there's no need in adverbs. But we have no need in qx either. Why to introduce (or REintroduce) something if we have something similar already? $captured = system :capture q/cmd../; or maybe even: (code=$code, out=$captured, err=$err) = system qq/cmd/; or maybe even(!) $captured = slurp qq/$cmd |/; Kind of removes the idea of pulling in the output of other programs as a fundamental part of the language though, for that it's nice to have an executing, capturing quote. Perhaps an adverb to qx that makes it behave like system() - I don't think it'd be a good idea to provide one that makes it behave like exec(), although perhaps other people do. I haven't that long unix background, and spawning processes is a very *fat* operation for me.. maybe after year or two I'll change my point of view, but for now I would be pretty happy with a 'slurp' variant. IMHO, spawning processes has nothing to do with other quoters, and perl already went far away from shells. but talking about oneliners and short shell-like scripts, where `` is pretty useful.. hm.. things good for oneliners are rarely as good for larger programs, and vice versa. Of course, Perl5 proves opposite, but Perl6 tends to be a little more verbose, and even in Perl5 we use quite different toolbox and style for mentioned above. Why not to make an average sized module of various shortcut grammars, with a very short name (x, f.e.), with defaults to export :all, so we could just do perl -Mx -e 'print `echo this is a perl5qx`' even if `` would be taken for something more useful in Perl6, and still be able to import only something useful for our larger program with use x qw/:perl5qx/;
Re: Angle quotes and pointy brackets
Juerd [EMAIL PROTECTED] wrote: but talking about oneliners and short shell-like scripts, where `` is pretty useful.. hm.. things good for oneliners are rarely as good for larger programs, and vice versa. Of course, Perl5 proves opposite, but Perl6 tends to be a little more verbose, and even in Perl5 we use quite different toolbox and style for mentioned above. Why not to make an average sized module of various shortcut grammars, with a very short name (x, f.e.), with defaults to export :all, so we could just do perl -Mx -e 'print `echo this is a perl5qx`' For oneliners, I think I'd appreciate using -o for that. The module itself can be Perl::OneLiner. module e { module *::Main { # Or whatever we'd need to do to switch to the top-level Main close $*CODE;# if there is such a thing no strict; no warnings; my macro circumfix:` ` (String $cmd) is parsed(/ [^`\\]* [ \\ . [^`\\]*: ] * /) { { run :capture $cmd } } use File::Copy qw(mv cp); ... # I do hope we get something better than #line. eval #line 1 '-me'\n ~ @ARGS.shift; } } perl -me 'say This is my one-liner!' One-liners with no specific support in the core--and it's different from Perl 5, so we can detect old one-liners. How's that for orthagonal? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
On Fri, 26 Nov 2004 09:33:49 -0800, Larry Wall [EMAIL PROTECTED] wrote: On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote: : I notice that in Perl6 thoose funny and could be much more common : than other paired brackets. And some people likes how they look, but : nobody likes the fact that there's no (and won't!) be a consistent way to : type them in different applications, wether it's hard or easy. ... : We also have another ascii pair, and . maybe they could be better : than and ?:) i'm not that farseeing, but isn't problem of : distinguishing as a bracket and as an comparison operator no harder : than distinguishing as bracket and as part of heredoc?.. It would get very confusing visually, even if the computer could sort it out: @a = @b @a = @b But there are some things that would be completely ambiguous: %hashfoobar %hashfoobaz() I not meant to replace it everywhere. But problem still exists. I know about only four uses of and . Tell me if there's more? 1) hyperoperators; @a = @b * @c @a.method @a = @b * @c @a.method (and, of course, mentioned in the past supercool 7-chars =:= operator!) hm.. IMO, hyperoperations are fat enough to be fat even in code. I wonder only if whitespace allowed there: @a = @b * @c @a .method 2) qw//-like construct; @array = foo bar baz @array = foo bar baz @array = qwfoo bar baz once again, there's nothing wrong. Although, using just foo bar baz would confuse Perl6 no more than globs and filehandles confuses Perl5. want an operator/want a term rule applies here. 3) pair(adverb) value quoting; myfunc :foobar :barbaz myfunc :arrayvalue1 value2 value3 myfunc :foobar :barbaz # this certainly suck myfunc :foo(bar) :bar(baz) # I'm going to use that if it works(?). # still this suck less: myfunc :array value1 value2 value3 # ..than: myfunc :array(value1, value2, value3) but replacement of with plain here is a no-problem: myfunc :foobar :barbaz :arrayvalue1 value2 value3 after you type :foobar only three times, you'll acquire internal alarm on constructs like myfunc :foobar :bar10; which are rather obfuscating already. IMHO, mandatory whitespace between :bar and 10 here won't make anybody sick. I wonder how many people would like to write it myfunc:foobar:bar10; 4) hash subscripting; that's a real pain. rather cute $varkey1key2[3]key3 suddenly becomes an ugly monster: $varkey1key2[3]key3 of course we could write: $var{'key1'}{'key2'}[3]{'key3'} and I would prefer this one to previous variant.. but it adds noise too. and it prevent us to logicaly recognize 'key1' and 'key2' not as strings but as something more like struct elements, like we got used in perl5 When I look at this $varkey1key2[3]key3 then I think that it's a *very* cute, nice, and clean syntax... I really like it! (and I would sacrifice something for that to happen, if I would be Larry :) ) but there's a problem for people and parser too. is a comparison *operator* and hash subscript is *operator* too, and there's no way to distinguish them at all. Term rule won't help here. + and + for comparison is plain sickness, of course. But we have some whitespace rules already. One of them is that subscripts shouldn't have whitespace to the left of them. We could add one more - to always PUT whitespace before comparison. so $afoo.. is a start of subscript and $a foo.. is always a comparison. Personally I'm not lazy to put spaces because of my little Forth experience. but I don't want to be lynched by mad horde of programmers in white robes, who will discover that while $a$b {...} for qwa b c {...} and even foo()bar()... do something completelly wrong, and parser just unable to catch this.. (hm.. bad examples.. maybe it could be made able to?) *sigh.. I'll write my own grammar:) I only afraid that it would take a half of all my remaining lifetime (because of addiction) But I'll return to topic. I've seen proposal by Juerd, somewhere it this thread, to use `` for autoquoting subscripting. but proposed %hash`foo`bar`$foo`0`$bar=0 not going to work delimiters should have corresponding closing character, so it should be something like %hash`foo``bar`{$foo}[0]{$bar}=0 or it would be *much* worse for parser than . actually, (countrary to [] and {} which could have arbitrary complex nested expressions in it) autoquoting subscript shouldn't neccessarily be a paired string. Any character could be used for it without any ambiguity. Even perl4 style ' or even Same with :pairs %hashkeyanotherkey[1]=0 %hash'key''anotherkey'[1]=0 :keyvalue :key'value' ah, using here would cause difficulties to interpolation of hello, $world so what about ' or ` (or whatever you could imagine)? P.S. I also considered shorcuts like $varkey1key2key3[1] # but that not going to remove MUCH of linenoise. or $var.key1key2[1].key3 #
Re: Angle quotes and pointy brackets
Juerd writes: For oneliners, I think I'd appreciate using -o for that. The module itself can be Perl::OneLiner. Things the module could do: * disable the default strict The C-e flag indicating the one-liner disables Cstrict anyway. Smylers
Re: Angle quotes and pointy brackets
On Sat, 27 Nov 2004 10:28:28 -0800, Larry Wall [EMAIL PROTECTED] wrote: On Fri, Nov 26, 2004 at 02:10:06PM -0800, Larry Wall wrote: : I know everone has their reflexes tuned to type qw currently, but : how many of you Gentle Readers would feel blighted if we turned it : into q:w instead? Of course, if we wanted to really drive it into the ground, we could turn qq// into q:q//, and then there's only one quoter. I'm sure if we tried hard enough we could find someone this appeals to. You don't even have to look very far. This seems like a decent idea to me (although I won't be sad if it doesn't happen). We also haven't quite detangled the backslash options. Seems there are four levels of support (using \/ to stand for any terminator character): 0) none # '' default 1) \\ and \/# q// default 2) list # (nothing builtin) 3) all # qq// default We need some way of specifying level 0 for a non-heredoc. We could turn q// into that, I suppose. If we did, either we'd have to make '' the same, or let it differ from q//, neither of which quite appeals to me, but I might let myself be argued into one of them or the other. Actually, I'd like to see '' be a simple, completely raw quoting construct. But if we don't do that, we might be able to take a page out of C#'s book with @ as the short form of the raw quoting construct. (Or something like that--I suspect C# picked @ because it's otherwise unused.) Actually, if we do something else with backticks, we can steal backticks for totally raw quoting... I'm open to other ideas, though we must remind ourselves that this is all very bike-sheddish. Oh, I vote for blue paint on that bike shed. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: Angle quotes and pointy brackets
James Mastros wrote: Larry Wall wrote: On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote: : ah, I forget, how could I do qx'echo $VAR' in Perl6? something like : qx:noparse 'echo $VAR' ? I think we need two more adverbs that add the special features of qx and qw, so that you could write that: q:x/echo $VAR/ where ordinary qx/$cmd/ is short for qq:x/$cmd/ I think I'd like that much better if we consider execution and word-splitting to be the primary operations, and interpolation and noninterpolation the adverbial modifiers then the other way around, making that qx:q/echo $VAR/ or qx:qq/$cmd/. OTOH, I expect backticks to be rare enough that I wouldn't mind writing use Spawn 'spawn'; spawn :capture :wait ($cmd); spawn :capture :wait ('echo $VAR'); Much more clear, saves ` for other things, and allows for easy specification of the many adverbs of spawn (weather it returns the return status, the PID/FH set object, or output, if it waits right there, or runs in the background (and makes the return value lazy), if it replaces the current process (exec)... I'd quite like that. Although I think spawn should be a builtin rather than in a module, if it was in the core, and we were getting rid of backticks. Although I'm masochistic enough that I don't mind the idea of always having to do execution with qx//, qx:q// or qx:qq// (running with other suggestions, I'd guess that would be non-interpolating execution, then the same again more explicitly, then interpolating execution) but I do like the idea of spawn. Kind of removes the idea of pulling in the output of other programs as a fundamental part of the language though, for that it's nice to have an executing, capturing quote. Perhaps an adverb to qx that makes it behave like system() - I don't think it'd be a good idea to provide one that makes it behave like exec(), although perhaps other people do. qx:r/$cmd/ qx:s/$cmd/ # both of these give back return codes? Which one! But then qx:r:qq// might be messy. Or even qx:exitcode:interpolate// Ouch. This isn't very coherent, I'm just thinking out loud based on what other people have said that I like. But there are some things that would be completely ambiguous: %hashfoobar Bracketing operator. %hashfoobaz() Very long bracket operator, which quite likely has a syntax error directly after it. But might not have... there's a chance that could slip through, and I don't like that for some reason. : or maybe even we could see consistant to go after + + and alike, and : make old and written as + and + (and then lt and gt suddenly could : become ~ and ~ :) I think people would rise up and slay us if we did that. We're already getting sufficiently risen up and slain over Perl 6. Could be worse. They could rise from the grave and eat us! Who says they won't? Well, yes, but sometimes the weights change over time, so it doesn't hurt (much) to reevaluate occasionally. But in this case, I think I still prefer to attach the exotic characters to the exotic behaviors, and leave the angles with their customary uses. ...of which they have plenty already. Backtick has exactly one, and not an often-used one at that... I'm fine with axing it. Of course, there are a lot more people in the world then just me. I'm fine with it too. I use it a fair bit but I think it's important to have a very clear mark where you're going to an external program
Re: Angle quotes and pointy brackets
On Sat, Nov 27, 2004 at 08:21:06PM +0100, Juerd wrote: James Mastros skribis 2004-11-27 11:36 (+0100): Much more clear, saves ` for other things I like the idea. But as a earlier thread showed, people find backticks ugly. Strangely enough, only when used for something other than readpipe. The idea of being able to write %hash{'foo'}{'bar'}{$foo}[0]{$bar} as %hash`foo`bar`$foo`0`$bar still works very well for me. At least on all keyboards that I own, it is easier to type. And in all fonts that I use for terminals (that'd be only misc-fixed and 80x24 text terminals), it improves legibility too. Doesn't that cause ambiguity between: %hash{'foo'}{'bar'}{$foo}[0]{$bar} and %hash{'foo'}{'bar'}{$foo}{0}{$bar} ^ ^ hash instead of subscript --
Re: Angle quotes and pointy brackets
On Sun, Nov 28, 2004 at 12:24:08PM -0500, John Macdonald wrote: On Sat, Nov 27, 2004 at 08:21:06PM +0100, Juerd wrote: James Mastros skribis 2004-11-27 11:36 (+0100): Much more clear, saves ` for other things I like the idea. But as a earlier thread showed, people find backticks ugly. Strangely enough, only when used for something other than readpipe. The idea of being able to write %hash{'foo'}{'bar'}{$foo}[0]{$bar} as %hash`foo`bar`$foo`0`$bar still works very well for me. At least on all keyboards that I own, it is easier to type. And in all fonts that I use for terminals (that'd be only misc-fixed and 80x24 text terminals), it improves legibility too. Doesn't that cause ambiguity between: %hash{'foo'}{'bar'}{$foo}[0]{$bar} and %hash{'foo'}{'bar'}{$foo}{0}{$bar} ^ ^ hash instead of subscript Hmm, I guess it is usually not ambiguous, only when it is causing auto-vivification of the hash-or-array with `0` is there an ambiguity between whether that means [0] and {'0'}. --
Re: Angle quotes and pointy brackets and heredocs
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote: I notice that in Perl6 thoose funny « and » could be much more common than other paired brackets. And some people likes how they look, but nobody likes fact that there's no (and won't!) be a consistent way to type them in different applications, wether it's hard or easy. But to swap «» with [] or {} could be real shock for major part of people.. We also have another ascii pair, and . maybe they could be better than « and » ?:) i'm not that farseeing, but isn't problem of distinguishing as a bracket and as an comparison operator no harder than distinguishing as bracket and as part of heredoc?.. Speaking of heredocs. Are they really common enough to merit a two char, absolutely no whitespace after it lexical? Especially one that looks a lot like the left bitshift operator, as well as an ASCII version of a Unicode quoting and splitting character? What if instead, we add a different adverb to q// and qq//? something like :h. That way people can mix and match all the quoting option they want, and we remove some annoying requirements about when you can and cannot have /\s+/ in your code. P5: print END, done.\n; line 1 line 2 END P6: say qq:h/END/, done.; line 1 line 2 END As for the topic being discussed, Since and are now full class quote-like thingies in P6REs, much to the chagrin of those of us who parse html on a regular basis, using them as such in the rest of P6 makes sense as well. Parsing should not be hindered since one would occur in operator context, and the other in expression context. -- Rod Adams
Re: Angle quotes and pointy brackets
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote: : ah, I forget, how could I do qx'echo $VAR' in Perl6? something like : qx:noparse 'echo $VAR' ? Hmm, well, with the currently defined adverbs you'd have to say qx:s(0)'echo $VAR' but that doesn't give you protection from other kinds of interpolation. I think we need two more adverbs that add the special features of qx and qw, so that you could write that: q:x/echo $VAR/ where ordinary qx/$cmd/ is short for qq:x/$cmd/ Likewise a qw/a b/ is short for q:w/a b/ : (Note: I like thoose adverbs.. I could imagine that in Perl6 if you want : to have something done in some_other_way, you just should insert : :some_other_way adverb, and that is! perl will DWIM happily :) Well, that's perhaps a bit underspecified from the computer's point of view. : I notice that in Perl6 thoose funny « and » could be much more common : than other paired brackets. And some people likes how they look, but : nobody likes fact that there's no (and won't!) be a consistent way to type : them in different applications, wether it's hard or easy. : : But to swap «» with [] or {} could be real shock for major part of : people.. : We also have another ascii pair, and . maybe they could be better than : « and » ?:) i'm not that farseeing, but isn't problem of distinguishing : as a bracket and as an comparison operator no harder than distinguishing : as bracket and as part of heredoc?.. It would get very confusing visually, even if the computer could sort it out: @a = @b @a = @b But there are some things that would be completely ambiguous: %hashfoobar %hashfoobaz() : or maybe even we could see consistant to go after + + and alike, and : make old and written as + and + (and then lt and gt suddenly could : become ~ and ~ :) I think people would rise up and slay us if we did that. We're already getting sufficiently risen up and slain over Perl 6. : But I certain, Larry already weighted exact that solution years ago.. Well, yes, but sometimes the weights change over time, so it doesn't hurt (much) to reevaluate occasionally. But in this case, I think I still prefer to attach the exotic characters to the exotic behaviors, and leave the angles with their customary uses. : P.S. If you have an urgent need to throw spoiled eggs at me, consider all : above as very late or very early fools day joke.. or you could try, but : i've never heard about ballistic transcontinental eggs. If you're a White Russian I suppose the yolk is on me. Larry
Re: Angle quotes and pointy brackets
Larry Wall skribis 2004-11-26 9:33 (-0800): but that doesn't give you protection from other kinds of interpolation. I think we need two more adverbs that add the special features of qx and qw, so that you could write that: q:x/echo $VAR/ where ordinary qx/$cmd/ is short for qq:x/$cmd/ Likewise a qw/a b/ is short for q:w/a b/ With x and w as adverbs to q and qq, are qx and qw still worth keeping? It's only one character less, qx isn't used terribly often and qw will probably be written mostly as anyway. And perhaps qq:x is a bit too dangerous. Suppose someone meant to type qq:z[$foo] (where z is a defined adverb that does something useful to the return value, but has no side effects) and mistypes it as qq:x[$foo]. Instant hard-to-spot security danger. Juerd
Angle quotes and pointy brackets
As we now know, in many situations, and « mean the same thing. In exactly those situations, the same is true for and ». However, sometimes, « cannot be used where can. Here-docs are an example. «» (or , if you wish) quotes. I am assuming that «» is a shorthand for qw«», except where special syntax is used with hash slices and :-pairs, just like //, which is short for m//, for qq, etcetera. But as « foo bar » and foo bar are the same thing, I wonder what qw foo bar means. Is that qw/ foo bar / or is that qw/foo bar/? And is this consistent with other operators, i.e. rx«» versus rx? Another question comes to mind as I am typing this message. Can « and be used together, or does « always need » and need ? If a matching pair is required, then does the same hold true for vector ops with anqle quotes on both sides (i.e. is that seen as a quoted operator, or as an operator that happens to have two vectorizing symbols)? One last question for now: how hard will it be to implement a grammar with certain not otherwise specified language features *removed*? Juerd
Re: Angle quotes and pointy brackets
Juerd writes: As we now know, in many situations, and « mean the same thing. In exactly those situations, the same is true for and ». However, sometimes, « cannot be used where can. Here-docs are an example. Why can't « be used for here-docs? I thought Larry had said they were completely interchangeable. But as « foo bar » and foo bar are the same thing, I wonder what qw foo bar means. Is that qw/ foo bar / or is that qw/foo bar/? I'd hope it's the former -- that is, that « can be substituted for anywhere that is a single operator, not just somewhere that those two characters happen to be adjacent to each other in the source, and » likewise. Otherwise you could have ridiculous things like: mfoo0 which parses as: m/foo/ 0 being written as: mfoo»0 And that's blatantly of no use to anybody. Smylers
Re: Angle quotes and pointy brackets
On Thu, Nov 25, 2004 at 09:55:54PM +0100, Juerd wrote: : As we now know, in many situations, and « mean the same thing. In : exactly those situations, the same is true for and ». However, : sometimes, « cannot be used where can. Here-docs are an example. : : «» (or , if you wish) quotes. I am assuming that «» is a shorthand : for qw«», except where special syntax is used with hash slices and : :-pairs, just like //, which is short for m//, for qq, etcetera. Hmm, I would say that is short for qq//, not qq. Quote characters lose their identity when used with generalized quotes. (I realize this is not always true with Perl 5, but that can be construed as a mistake.) So «» is not really short for qw«» unless you take the delimiters of the latter construct as simple characters without any «» baggage, including the need to have a workaround. So I'd rather say «» is short for qw//. : But as « foo bar » and foo bar are the same thing, I wonder what : qw foo bar means. Is that qw/ foo bar / or is that qw/foo bar/? : And is this consistent with other operators, i.e. rx«» versus rx? It means qw/ foo bar/, and yes, that's consistent. : Another question comes to mind as I am typing this message. Can « and : be used together, or does « always need » and need ? If a matching : pair is required, then does the same hold true for vector ops with anqle : quotes on both sides (i.e. is that seen as a quoted operator, or as an : operator that happens to have two vectorizing symbols)? I don't see that it's terribly important either to allow that or to disallow it. I do think we should discourage asymmetry, but I can well imagine that someone who doesn't have easy «» access might end up replacing one end without replacing the other. It should be easy for someone in this fix to translate the line to the «» form. Perhaps perl itself ought to offer to do the translation for you. Basically, the sooner we can get code into a canonical form, the less trouble we'll have overall. This approach doesn't help the person who can't even *display* «», but that problem will be solved before the input problem is. For instance, PerlMonks has no problem displaying «», but I haven't a clue how to type it into my browser yet. Some people might actually prefer to have the form illegal, not because they don't want to type it in that way, but because they want to be forced to translate to «» before the semi-bogus forms enter The Record. : One last question for now: how hard will it be to implement a grammar : with certain not otherwise specified language features *removed*? So you want to violate Liskov substitutability on grammars, eh? :-) While one can certainly redefine rule methods to pitch a fit if called, the real way you cut down the language is by not referring to those rules in the first place from elsewhere. Which means you have to override those referring rules, after which it almost doesn't matter if the previously referred to rules are somehow cancelled or not. The other part of it is that some of the constructs are catalogued in hashes and arrays rather than in rule alternatives. When you derive a grammar you can certainly copy over a part of the hash or array and leave out other parts. These hashes and arrays are loaded up in the first place via the various syntactic categories we go on about. So maybe we have some way of cancelling syntax. BEGIN { undef circumfix:« »; } or maybe even: my macro circumfix:« » is gone; That would have the effect of removing the '' key from the term hash, or for a lexical declaration, making a copy of the term hash without that key, so that when we hit the end of this lexical scope. we can restore the old hash. Larry
Re: Angle quotes and pointy brackets
Larry Wall skribis 2004-11-25 13:45 (-0800): Hmm, I would say that is short for qq//, not qq. Quote characters lose their identity when used with generalized quotes. (I realize this is not always true with Perl 5, but that can be construed as a mistake.) So «» is not really short for qw«» unless you take the delimiters of the latter construct as simple characters without any «» baggage, including the need to have a workaround. So I'd rather say «» is short for qw//. I'm happy to read this. Perl 5's semantics with qx|m|qr|s and '' probably made me translate to qq instead of qq//, or qq{} as perlop lists it. : But as « foo bar » and foo bar are the same thing, I wonder what : qw foo bar means. Is that qw/ foo bar / or is that qw/foo bar/? : And is this consistent with other operators, i.e. rx«» versus rx? It means qw/ foo bar/, and yes, that's consistent. That's a relief :) This approach doesn't help the person who can't even *display* «», but that problem will be solved before the input problem is. For instance, PerlMonks has no problem displaying «», but I haven't a clue how to type it into my browser yet. Should you happen to use X with the Xkb extension, it is a matter of assigning a key to Multi_key and then typing Multi_key . I have assigned my rightmost Windows key (the Menu key) with: xmodmap -e keysym Menu = Multi_key So you want to violate Liskov substitutability on grammars, eh? :-) I'd even violate gravity, if I could! While one can certainly redefine rule methods to pitch a fit if called, the real way you cut down the language is by not referring to those rules in the first place from elsewhere. Which means you have to override those referring rules, after which it almost doesn't matter if the previously referred to rules are somehow cancelled or not. I was afraid that that'd be the answer. The other part of it is that some of the constructs are catalogued in hashes and arrays rather than in rule alternatives. When you derive a grammar you can certainly copy over a part of the hash or array and leave out other parts. These hashes and arrays are loaded up in the first place via the various syntactic categories we go on about. So maybe we have some way of cancelling syntax. That's better news :) BEGIN { undef circumfix:« »; } But if mixed « is allowed, isn't that «»syntax error? Or did I misinterpret the answer re mixing them? my macro circumfix:« » is gone; Perhaps is gone is a bit too easy for something that shouldn't be done. Juerd
Re: Angle quotes and pointy brackets
Larry Wall writes: PerlMonks has no problem displaying «», but I haven't a clue how to type it into my browser yet. If your browser is using Gnome then holding down Ctrl+Shift while typing AB (for «) or BB (for ») might work. (This is also working for me typing this in 'Vim' in a 'Gnome Terminal', but isn't as nice as the 'Vim' digraphs.) Smylers
Re: Angle quotes and pointy brackets
On Thu, 25 Nov 2004 13:45:51 -0800, Larry Wall [EMAIL PROTECTED] wrote: ... Hmm, I would say that is short for qq//, not qq. Quote characters lose their identity when used with generalized quotes. (I realize this is not always true with Perl 5, but that can be construed as a mistake.) So is not really short for qw unless you take the delimiters of the latter construct as simple characters without any baggage, including the need to have a workaround. So I'd rather say is short for qw//. ... ah, I forget, how could I do qx'echo $VAR' in Perl6? something like qx:noparse 'echo $VAR' ? (Note: I like thoose adverbs.. I could imagine that in Perl6 if you want to have something done in some_other_way, you just should insert :some_other_way adverb, and that is! perl will DWIM happily :) ... This approach doesn't help the person who can't even *display* , but that problem will be solved before the input problem is. For instance, PerlMonks has no problem displaying , but I haven't a clue how to type it into my browser yet. ... I notice that in Perl6 thoose funny and could be much more common than other paired brackets. And some people likes how they look, but nobody likes fact that there's no (and won't!) be a consistent way to type them in different applications, wether it's hard or easy. But to swap with [] or {} could be real shock for major part of people.. We also have another ascii pair, and . maybe they could be better than and ?:) i'm not that farseeing, but isn't problem of distinguishing as a bracket and as an comparison operator no harder than distinguishing as bracket and as part of heredoc?.. or maybe even we could see consistant to go after + + and alike, and make old and written as + and + (and then lt and gt suddenly could become ~ and ~ :) But I certain, Larry already weighted exact that solution years ago.. P.S. If you have an urgent need to throw spoiled eggs at me, consider all above as very late or very early fools day joke.. or you could try, but i've never heard about ballistic transcontinental eggs.