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: >C 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: 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: 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 C and C (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: 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.
C 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: 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 -- C 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. C would do it, but I'm not sure about
C. (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: 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 C, 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
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
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
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
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
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
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: 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
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
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 > > $var[3] 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: * acts as a multidimensional subscript (* but what for @array = ?) * <+42> returns a number instead of a string. Then: $var 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: $varÂfoo ; $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: $var[3] 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
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
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
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 () {...}
: >
: > 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 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 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
> "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
AH> Larry Wall wrote:
>> * We get the cute, clean and rather more typeable
>>
>> $var[3]
>>
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
$hash 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:
>>
>> $var[3] < $var[4]
>>
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
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
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
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 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
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 C anyway. Smylers
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:
%hash
%hash
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 = <>
@array = qw
once again, there's nothing wrong. Although, using just
would confuse Perl6 no more than and confuses Perl5.
"want an operator/want a term" rule applies here.
3) pair(adverb) value quoting;
myfunc :fooÂbar :barÂbazÂ
myfunc :arrayÂvalue1 value2 value3Â
myfunc :foo<> :bar<> # 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 :foo :bar :array
after you type :foo only three times, you'll acquire internal alarm
on constructs like
myfunc :foo :bar<10;
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:foo:bar<10;
4) hash subscripting;
that's a real pain.
rather cute
$varÂkey1ÂÂkey2Â[3]Âkey3Â
suddenly becomes an ugly monster:
$var<><>[3]<>
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
$var[3]
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
$a
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 qw {...}
and even
foo()
*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
%hash"key""anotherkey"[1]=0
%hash'key''anotherkey'[1]=0
:key"value"
: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
$var<>[1] # but that not going to remove MUCH of
linenoise.
or
$var.[1]. # yikes, but still better than <<>><<>>
...
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
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 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 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
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
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:
%hash
Bracketing operator.
%hashVery 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, 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
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
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:
%hash
%hash> 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
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.
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
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
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
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: m>foo>>0 which parses as: m/foo/ > 0 being written as: m>foo»0 And that's blatantly of no use to anybody. Smylers
