Angle quotes and pointy brackets
Juerd
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
Larry Wall
: 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
Smylers
> 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
Juerd
> 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
Larry Wall
: But if mixed «>> is allowed, isn't that «<<»syntax error? Or did I
: misinterpret the answer re mixing them?
Uh, I wasn't aware that I'd actually answered the question. :-)
My actual inclination is to disallow it. I was just trying to argue
myself out of that position. Bad habit of mine, thinking out loud.
: > my macro circumfix:«<< >>» is gone;
:
: Perhaps "is gone" is a bit too easy for something that shouldn't be
: done.
Okay, make it "is obliterated_after_grave_consideration_of_the_consequences".
Larry
Smylers
> 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
Alexey Trofimenko
On Thu, 25 Nov 2004 13:45:51 -0800, Larry Wall <la...@wall.org> 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.
Larry Wall
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
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<foo><bar>
%hash<foo><baz()
: 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
Juerd
> 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
Larry Wall
: 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.
I might be happy to remove them, though people will write q:x instead
of qq:x and wonder why it doesn't interpolate. What I think is fun is
qq:x:w, which presumably runs the command and then splits the result
into words.
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?
: 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.
Seems rather unlikely. And presumably tainting should catch it
if it's really a security issue.
Larry
James Mastros
> 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' ?
>
> 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)...
> Likewise a qw/a b/ is short for
>
> q:w/a b/
qw:q/a b/
$fromvar = 'foo bar';
qw:qq/a "something with spaces" b $fromvar/
# ?? -- slightly OT, but is that a, '"something', with, 'spaces"',
# b, 'foo bar', or... um, what? Is qw smart enough to allow
# internal quotes? Does splitting take place before or after
# interpolation if it's interpolating?
> : 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:
We could force whitespace disambugation, possibly -- require that <...>
bracketing have whitespace on the outside and none on the inside. But
that's ugly.
> But there are some things that would be completely ambiguous:
>
> %hash<foo><bar>
Bracketing operator.
> %hash<foo><baz()
Very long bracket operator, which quite likely has a syntax error
directly after it.
> : 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!
> 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.
> If you're a White Russian I suppose the yolk is on me.
In Russia, the yokes throw you!
-=- James Mastros,
theorbtwo
Larry Wall
: I might be happy to remove them, though people will write q:x instead
: of qq:x and wonder why it doesn't interpolate. What I think is fun is
: qq:x:w, which presumably runs the command and then splits the result
: into words.
:
: 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.
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.
I figure :b can mean level 3, and for level 2 :b«nt» could mean
just \n and \t. I suppose :b(0) and :b(1) could mean levels 0 and
1, but that's just plain sucky. Could force 0 and 1 with :b«» and
:b«\\\/» respectively, but that's a bit long-winded. Could use two
different adverbs, or a qh// that defaults to level 0, but those are
also rather yucky. I'm open to other ideas, though we must remind
ourselves that this is all very bike-sheddish.
Larry
Juerd
> 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.
Juerd
Brent 'Dax' Royal-Gordon
> 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 <br...@brentdax.com>
Perl and Parrot hacker
There is no cabal.
Matthew Walton
> 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<foo><bar>
>
> Bracketing operator.
>
>> %hash<foo><baz()
>
> 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
John Macdonald
Doesn't that cause ambiguity between:
%hash{'foo'}{'bar'}{$foo}[0]{$bar}
and
%hash{'foo'}{'bar'}{$foo}{0}{$bar}
^ ^ hash instead of subscript
--
John Macdonald
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'}.
--
Juerd
> Doesn't that cause ambiguity between:
> %hash{'foo'}{'bar'}{$foo}[0]{$bar}
> and
> %hash{'foo'}{'bar'}{$foo}{0}{$bar}
> ^ ^ hash instead of subscript
Not really. $hashref[] can't be used and $arrayref{} can't be used. This
means Perl can easily disambiguate.
Only for types that have both [] and {}, there is a problem. When they
are both possible, just define one to have precedence. I'd pick {}.
Exactly the same rule should apply for autovivification: {}.
Juerd
Rod Adams
>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
Juerd
> 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.
I think this is a very good idea. I too dislike the whitespace
disambiguation thing for this, and was going to propose using unary %
instead of <<. But this is even better, IMO.
> 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.
It would be great if <''> in a rule would be just ''.
rule NotationDecl {
<'<!NOTATION'> <S> <Name> <S> [<ExternalID> | <PublicID>] <S>? <'>'>
}
would then just be
rule NotationDecl {
'<!NOTATION' <S> <Name> <S> [<ExternalID> | <PublicID>] <S>? '>'
}
Which I find much easier to read. (Frankly, <'>'> is just too hard to
type and be parsed by a human.) It also makes all other balanced
delimiter matching rules more readable:
rx/ \[ \w+ \] /
rx/ <'['> \w+ <']'> /
rx/ '[' \w+ ']' /
Juerd
Larry Wall
: What if instead, we add a different adverb to q// and qq//? something
: 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
I think I like it. Let me think about it some more though.
Larry
Jon Ericson
Not when you're writing a quick one-liner. Maybe stdout capturing
backticks should be disallowed when using strict, but allowed on the
command line.[1]
Will system return stdout in string context?
Jon
Footnotes:
[1] I wonder if there is a reason for disliking backticks besides it
being surprising to C and Java programmers?
Luke Palmer
> Matthew Walton <mat...@alledora.co.uk> writes:
>
> > James Mastros wrote:
> >> Larry Wall wrote:
> >>> 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
>
> Not when you're writing a quick one-liner. Maybe stdout capturing
> backticks should be disallowed when using strict, but allowed on the
> command line.[1]
Let me clarify before this thread takes off. We had a long discussion
about the role of backticks back in April. Larry weighed in after a
long, long consideration. Here's the answer:
http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.org&rnum=1clarify before this thread takes off. We had a long discussion about the role of backticks back in April. weighed in after a long, long consideration. Here's the answer:clarify before this thread takes off. We had a long discussion about the role of backticks back in April. weighed in after a long, long consideration. Here's the answer:
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.
You can spare a few extra characters in a command line script. Don't be
afraid. They won't bite.
Oh, and anything you have to say about them has already been said back
in April.
Luke
Juerd
> http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.org&rnum=1clarify
> 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.
Juerd
Luke Palmer
Sorry, I misread.
Luke
Juerd
> 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. Things the module could do:
* introduce `` and qx
* disable the default strict
* enable warnings for things like open, print, close
* introduce shortcuts like mv, cp, cd
Juerd
Alexey Trofimenko
> 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/;
Smylers
> Luke Palmer skribis 2004-11-29 16:10 (-0700):
>
> > It says that backticks won't be used at all in Perl 6.
>
> 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.
Although Larry did end by saying that qx "probably needs to be
completely rethought anyway", so it's quite possible that even though
C<``> have been left on the side they don't actually get used when
putting this thing back together.
Smylers
Alexey Trofimenko
wrote:
> Larry Wall wrote:
>> Likewise a qw/a b/ is short for
>> q:w/a b/
> qw:q/a b/
> $fromvar = 'foo bar';
> qw:qq/a "something with spaces" b $fromvar/
> # ?? -- slightly OT, but is that a, '"something', with, 'spaces"',
> # b, 'foo bar', or... um, what? Is qw smart enough to allow
> # internal quotes? Does splitting take place before or after
> # interpolation if it's interpolating?
I like the idea that q would be the most general quoter, which could be
used (with corresponding adverbs) instead of qq, qw, and heredoc, but qq
and qw still exists in core as handy shortcuts for most frequent variants.
something like (abstract)
&qq ::= &q.assuming(:qq)
(I don't know how to write it correctly - q isn't a function..)
...
:s(0) adverb for specifying "interpolating level" for quoters seems
kinda strange to me. First, it is harder to remember numbers than
something symbolic. Second, there's going to be several interpolation
layers, and some of them are independent of others, so having only one
argument is insufficient.
we would (not) want to interpolate:
variables, functions, methods,
\n \t and alike,
backslashed delimiters
backslashed backslashes
... and something also, i forgot what exactly:)
and someone could want only some of the options..
"heredocness" should be just an adverb for all other type of quotes.
personally I would be very glad to have "shell-like" quoting in qw, as
James Mastros suggests above. It could save many keystrokes in definition
of long lists where one occasional space-containing element happens to
exist.
some other cool variants:
heredoc-qw which would see only \n as elements delimiter, and would
strip leading and ending whitespace (for system)
heredoc-qw for list of lists (\n as a row separator)
heredoc-qq without ending "\n"
I think, some interesting variants of scalars quoting could be borrowed
from YAML(serialization language). think of folded scalars, #comments etc..
hmm.. maybe someone has ideas how to add custom behaviours for q without
rewriting it? I mean, how to define custom :adverb for it..
Brent 'Dax' Royal-Gordon
> > 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 <br...@brentdax.com>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
Alexey Trofimenko
> 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<foo><bar>
> %hash<foo><baz()
>
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 = qw<foo 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 :foo«bar» :bar«baz»
myfunc :array«value1 value2 value3»
myfunc :foo<<bar>> :bar<<baz>> # 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> :bar<baz> :array<value1 value2 value3>
after you type :foo<bar> only three times, you'll acquire internal alarm
on constructs like
myfunc :foo<bar> :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>:bar<10;
4) hash subscripting;
that's a real pain.
rather cute
$var«key1»«key2»[3]«key3»
suddenly becomes an ugly monster:
$var<<key1>><<key2>>[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
$var<key1><key2>[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
$a<foo.. 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 qw<a 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
%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<<key1><key2><key3>>[1] # but that not going to remove MUCH of
linenoise.
or
$var.<key1><key2>[1].<key3> # yikes, but still better than <<>><<>>
...
Smylers
> 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<strict> anyway.
Smylers
Smylers
> 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 even calling the function C<run>, as per Larry's April mail that Luke
referenced.
> 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.
I've got a sufficient Unix background that I find it awkward to use
Windows, and I completely agree with you. Also, there are many
instances of people using backticks or C<qx> when what they meant was
C<system>.
Smylers
Juerd
> delimiters should have corresponding closing character, so it should be
> something like
Please, stop seeing ` as a circumfix operator in this context. What you
do is like saying that after . you expect a capital letter. It's a
programming language, and the only definition useful is the language
itself, disregarding other languages, like Perl 5 and English.
In current Perl, :: is also known as '. And that's not a quoting
character in that context. In an early Apocalypse, Larry said not to
make the same "mistake" again because it would be hard to syntax-colour.
But that doesn't quite count, as matching for editors will have to be
rewritten anyway to support things like "$foo{"bar"}".
> %hash`foo``bar`{$foo}[0]{$bar}=0
> or it would be *much* worse for parser than <>.
Yes, that is indeed awful syntax. But fortunately, my proposal wasn't to
use `` as a postcircumfix operator.
> %hash"key""anotherkey"[1]=0
> %hash'key''anotherkey'[1]=0
> :key"value"
> :key'value'
This is just making parens/curlies optional for more operators than
<<>>.
> $var.<key1><key2>[1].<key3> # yikes, but still better than <<>><<>>
Still hard to type. Simply put, repeated circumfix operators suck,
regardless of whether they are <>, <<>>, "", '', [], {}.
Juerd
Alexey Trofimenko
> Alexey Trofimenko skribis 2004-11-30 9:09 (+0300):
>> delimiters should have corresponding closing character, so it should be
>> something like
>
> Please, stop seeing ` as a circumfix operator in this context. What you
> do is like saying that after . you expect a capital letter. It's a
> programming language, and the only definition useful is the language
> itself, disregarding other languages, like Perl 5 and English.
>
> In current Perl, :: is also known as '. And that's not a quoting
> character in that context. In an early Apocalypse, Larry said not to
> make the same "mistake" again because it would be hard to syntax-colour.
> But that doesn't quite count, as matching for editors will have to be
> rewritten anyway to support things like "$foo{"bar"}".
I have several editors even on windows, and not even specially written for
perl, which do color ' as :: correctly. Personally, I liked that syntax,
it has some similarities to Ireland surnames:) $O'Hara{Scarlett}
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.
so, could you be more explicit, what rules your syntax have?
$a`$b+$c`$d, is it equivalent of
$a[$b+$c][$d] or
$a[$b]+$c[$d] ?
and I think, polymorphic treating of ` as either {} or [] adds some
overhead.. and unstability of your code. Especially in cases like $a`$b,
when compiler just can't see in compiler time, what could be contained in
$b - number or string.
only one variant of that syntax looks for me useful:
$var`Only`Ident`Compatible{$strings}`Here123
as replacement for
$var{'Only'}{'Ident'}{'Compatible'}{$strings}{'Here123'}
so ` works here exactly as Java(ECMA)Script .
no spaces allowed, no expressions, and it is always a HASH subscript.
doesn't lua have that prefix `Quoting behavior already? ( 'text' eq `text
) or it was some other language? If to mimic it, than
$var`Only`Ident`Compatible{$strings}`Here123
could be automatiaclly transformed into
$var'Only''Ident''Compatible'{$strings}'Here123'
Macro definition for it could be very simple, like
macro postfix:«`» is parsed {<ident>} {return "'$0'"} or something like.
>> %hash"key""anotherkey"[1]=0
>> %hash'key''anotherkey'[1]=0
>> :key"value"
>> :key'value'
> This is just making parens/curlies optional for more operators than
> <<>>.
but :key'value' is the same as :key<<value>>.. distinction shown only on
occasional spaces in ''.
>
>> $var.<key1><key2>[1].<key3> # yikes, but still better than <<>><<>>
>
> Still hard to type. Simply put, repeated circumfix operators suck,
> regardless of whether they are <>, <<>>, "", '', [], {}.
hm, I thought something like this long time ago, when I come to perl and
some other languages from pascal, where you could address a 3dimensional
array with a[1,2,3] instead of a[1][2][3]; but there was no problem at
all, it's a matter of habit. now I consider latter more readable and
flexible.
Juerd
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
James Mastros
> 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.
I'd like to apologize for bringing it up (while trying, and apparently
failing, not to).
-=- James Mastros
Brent 'Dax' Royal-Gordon
> 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.
Not to put too fine a point on it, but "everything" includes Larry's
rejection of the idea.
Larry Wall
: Why to introduce (or REintroduce) something if we have something
: similar already?
:
: $captured = system :capture q/cmd../;
By the way, that one happens to be illegal at the moment. To use
pairs as part of an argument list you have to install a comma like this:
$captured = system :capture, q/cmd../;
As it currently stands, you may only omit comma between :pairs. Otherwise
we don't know how to parse this:
print $y / $x :round(2) / 3;
With an assumed comma after the :round(2), the / would be taken as
the start of a pattern.
Possibly we can fix this for :pairs that are the first thing a list, though.
It seems to be a trap that p6l'ers keep falling into.
Larry
Juerd
> > 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.
> Not to put too fine a point on it, but "everything" includes Larry's
> rejection of the idea.
True. There are however some things that "almost everything" does not
include, and evidently there is still the need for some to discuss this
subject.
Juerd
Larry Wall
: When I look at this
: $var<key1><key2>[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.
I rather like it too. I'm glad someone else is thinking along the
same lines. The basic problem with «...» is that most of its uses
were turning out to be more useful that the corresponding <...>.
In fact, I was thinking about all this on the way home from Seattle
yesterday (a 15-hour drive), and I think I'm ready to propose a Great
Angle Bracket Renaming.
Here's the proposal.
First the bad news:
* We accept that the C<< < >> operator requires whitespace
around it, and be prepared to be burned in effigy occasionally.
* We steal angles away from iterators.
Now the ugly news:
* Hyper operators stay the same, »op«.
Now with those out of the way, the good news:
* All other uses of «...» and <...> swap, pretty much.
Now, that has certain interesting outcomes.
* We get <...> as the qw// shorthand where a term is expected.
* Most uses of qw// involve strings and lists, so there's little
visual interference with numeric comparison operators.
* We get the cute, clean and rather more typeable
$var<key1><key2>[3]<key3>
* People can probably get used to reading things like:
$var<key1><key2>[3]<key3> < $var<key1><key2>[4]<key3>
* Though they will certainly carp.
* The ordinary angles do a better job of turning the
literal keys into visual pills than «...» do.
* 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.
* That frees up «...» for Something Else.
* That something else is the requested variant of qw// that allows
interpolation and quoting of arguments in a shell-like manner.
* That means that, roughly, we have this proportion:
'...' : "..." :: <...> : «...»
* Therefore, just as you can use "..." in place of '...' where you
you think it's more readable, you may still use «...» in place
of <...> where that helps readability.
$var«key1»«key2»[3]«key3» < $var«key1»«key2»[4]«key3»
* Both the «...» and <...> forms work as slices when used as hash
subscripts.
* The Texas quotes <<...>> are only needed when you *have* to interpolate.
* 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".
* Multimethed references could be distinghuised either way:
&bark«Tree»
&bark<Dog>
* Match vars become $<foo> instead of $«foo».
* A rule like <ident> now captures, while «ws» or <<ws>> doesn't.
I think I really like that last outcome. Capturing should be the default.
And the low profile of «ws» makes it look like an "oh by the way".
Anyway, feel free to shoot this full of holes.
Larry
David Wheeler
> Correct. The p5-to-p6 translator will turn any
>
> while (<handle>) {...}
>
> into
>
> for @$handle {...}
I assume that each value would be still fetched from the file handle
lazily, yes?
Regards,
David
Brent 'Dax' Royal-Gordon
Larry Wall <la...@wall.org> 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?
Larry Wall
Um, that was the question my "Correct" was answering.
Larry
Rod Adams
>I like this in general. However...
>
>Larry Wall <la...@wall.org> 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
Larry Wall
: So
:
: my @list = <foo bar baz>;
:
: is the equivalent of
:
: my @list = ('foo', 'bar', 'baz');
:
: ?
Yes.
: > * 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.
:
: That's doable. I take it that if I do
:
: for (@$fh) {
: ...
: }
:
: then $fh iterates lazily rather than exploding into an enormous list to
: be processed and chewing up all the RAM.
Correct. The p5-to-p6 translator will turn any
while (<handle>) {...}
into
for @$handle {...}
or whatever we decide is the correctest idiom.
: > * That frees up «...» for Something Else.
: >
: > * That something else is the requested variant of qw// that allows
: > interpolation and quoting of arguments in a shell-like manner.
:
: Mmmm so I can write
:
: my $foo = 'foo';
: my $bar = 'bar';
: my $baz = 'baz';
: my @list = «$foo $bar $baz»;
:
: and get the same @list I got earlier? Mighty cool.
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.
: > * The Texas quotes <<...>> are only needed when you *have* to
: > interpolate.
:
: Does
:
: <<foo bar baz>>
:
: mean
:
: «foo bar baz»
:
: or
:
: ('<foo', 'bar', 'baz>')
:
: ?
The former. The <<...>> workaround is still the same, but needed a lot less.
: > * 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.
: > * Multimethed references could be distinghuised either way:
: >
: > &bark«Tree»
: > &bark<Dog>
:
: Good, so those of us who wish to use as much Unicode as possible can do
: so without having to rewrite the grammar. Excellent ;-)
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.
Larry
Matthew Walton
> I rather like it too. I'm glad someone else is thinking along the
> same lines. The basic problem with «...» is that most of its uses
> were turning out to be more useful that the corresponding <...>.
> In fact, I was thinking about all this on the way home from Seattle
> yesterday (a 15-hour drive), and I think I'm ready to propose a Great
> Angle Bracket Renaming.
Well... this is interesting. I'm wondering, should I recycle my copy of
Perl 6 and Parrot Essentials, or keep it as an historical document for
future generations to look at and marvel over?
Just kidding, I'm surprising myself by liking this. Let's see if I've
understood it.
> Here's the proposal.
>
> First the bad news:
> * We accept that the C<< < >> operator requires whitespace
> around it, and be prepared to be burned in effigy occasionally.
Personally, I always use whitespace around such operators, so it's no
hassle for me for it to be required. Might encourage some more readable
code (definition of 'readable' unfortunately still undecided across the
programming community).
> * We steal angles away from iterators.
Will they miss them? In a way it's nice to have syntax-level support for
iteration, but it's no massive hardship to do without.
> Now the ugly news:
> * Hyper operators stay the same, »op«.
That's not ugly.
> Now with those out of the way, the good news:
> * All other uses of «...» and <...> swap, pretty much.
>
> Now, that has certain interesting outcomes.
>
> * We get <...> as the qw// shorthand where a term is expected.
So
my @list = <foo bar baz>;
is the equivalent of
my @list = ('foo', 'bar', 'baz');
?
> * Most uses of qw// involve strings and lists, so there's little
> visual interference with numeric comparison operators.
Very true.
> * People can probably get used to reading things like:
>
> $var<key1><key2>[3]<key3> < $var<key1><key2>[4]<key3>
>
> * Though they will certainly carp.
They always do.
> * 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.
That's doable. I take it that if I do
for (@$fh) {
...
}
then $fh iterates lazily rather than exploding into an enormous list to
be processed and chewing up all the RAM.
> * That frees up «...» for Something Else.
>
> * That something else is the requested variant of qw// that allows
> interpolation and quoting of arguments in a shell-like manner.
Mmmm so I can write
my $foo = 'foo';
my $bar = 'bar';
my $baz = 'baz';
my @list = «$foo $bar $baz»;
and get the same @list I got earlier? Mighty cool.
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : «...»
Elegance, always good.
> * Therefore, just as you can use "..." in place of '...' where you
> you think it's more readable, you may still use «...» in place
> of <...> where that helps readability.
>
> $var«key1»«key2»[3]«key3» < $var«key1»«key2»[4]«key3»
Fabulouser and fabulouser.
> * Both the «...» and <...> forms work as slices when used as hash
> subscripts.
I don't think I've ever used a hash slice in my life. Is there something
wrong with me?
> * The Texas quotes <<...>> are only needed when you *have* to interpolate.
Does
<<foo bar baz>>
mean
«foo bar baz»
or
('<foo', 'bar', 'baz>')
?
> * 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.
> * Multimethed references could be distinghuised either way:
>
> &bark«Tree»
> &bark<Dog>
Good, so those of us who wish to use as much Unicode as possible can do
so without having to rewrite the grammar. Excellent ;-)
> * Match vars become $<foo> instead of $«foo».
>
> * A rule like <ident> now captures, while «ws» or <<ws>> doesn't.
>
> I think I really like that last outcome. Capturing should be the default.
> And the low profile of «ws» makes it look like an "oh by the way".
Unfortunately the ASCII equivalent doesn't have quite such a low
profile, but I think I can live with that, since I can handle «» on all
my Perl-coding systems. And the alternatives are still there for those
who can't.
In many ways this seems clearer than the old way. I like it.
David Wheeler
> : I assume that each value would be still fetched from the file handle
> : lazily, yes?
>
> Um, that was the question my "Correct" was answering.
D'oh! Sorry.
David
Larry Wall
: I like this in general. However...
:
: Larry Wall <la...@wall.org> 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?
Well, the IO::All folks will have their own ideas. The thing I don't
like about IO::All is the way it overloads angles. So maybe if we have
$foo ← io('myfile')
we also get the unary:
← io('myfile')
Actually, if you buy the metaphor that the filesystem is "below", then
I kinda like:
$foo ↰ io('myfile')
and
↰io('myfile')
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.
Larry
Austin Hastings
> * We get the cute, clean and rather more typeable
>
> $var<key1><key2>[3]<key3>
>
>
No more or less typeable for me, or anyone else who can remap their
keyboard. I'm presuming there's something costly about {} on non-US
keyboards, but how much does it cost? and do those non-US perl hacks use
remapping already?
> * People can probably get used to reading things like:
>
> $var<key1><key2>[3]<key3> < $var<key1><key2>[4]<key3>
>
>
It's just as readable as XML.
> * Though they will certainly carp.
>
>
Carp.
Carp.
Carp.
> * The ordinary angles do a better job of turning the
> literal keys into visual pills than «...» do.
>
>
What're the objectives here again?
Sorry, but <> don't turn ANYTHING into "visual pills". They never have.
(HT|X)ML looks like gobbledygook interspersed with low-slung X's. The
line above reads like a IOCCC loser.
> * 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.
>
>
while ($.fetch)
??
> * That frees up «...» for Something Else.
>
> * That something else is the requested variant of qw// that allows
> interpolation and quoting of arguments in a shell-like manner.
>
>
Sorry, why wouldn't `` work?
How about just having C< system() > return a clever object with .output
and .err methods?
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : «...»
>
>
Have we discussed which quote-like operator is going to stand for "eval"?
There's a number of different post-processing things you can do with
string literals, with interpolation at one end of the spectrum and
execution at the other.
Why not just write this down as "these are all just special cases of XXX
behavior", and then build some handles onto XXX, a la NEXT, LAST, etc.
Then provide "standard bindings" for '', ``, "", and //.
> * Therefore, just as you can use "..." in place of '...' where you
> you think it's more readable, you may still use «...» in place
> of <...> where that helps readability.
>
>
my $foo = `*.c` :post(literal); # *.c
my $bar = /$foo/ :post(glob); # a.c b.c ...
my $cmd = 'echo $foo' :post(interpolate); # echo *.c
my $output = q{$cmd} :post(exec); # *.c
my $files = "$cmd" :post(shell); # a.c b.c ...
> $var«key1»«key2»[3]«key3» < $var«key1»«key2»[4]«key3»
>
>
I'm looking for the goodness, and I'm just preferring the more vertical
{} as parallels with [].
> * The Texas quotes <<...>> are only needed when you *have* to interpolate.
>
>
Not even a little bit sure what this means. If non-interpolation is an
option, put a modifier on it.
> * Multimethed references could be distinghuised either way:
>
> &bark«Tree»
> &bark<Dog>
>
>
At some point, nestled « was considered a short-circuit of the
paren/hash. Is that supposed to stand, or are those quotes?
> * Match vars become $<foo> instead of $«foo».
>
>
Seems independent of the others. Is this just a consistency issue?
> * A rule like <ident> now captures, while «ws» or <<ws>> doesn't.
>
>
So <...>, which is analogous to '...' above, doesn't interpolate but
does capture? While «...», which is analogous to "...", does interpolate
but doesn't capture?
>I think I really like that last outcome. Capturing should be the default.
>And the low profile of «ws» makes it look like an "oh by the way".
>
>
I think that last sentence sums it up: using «ws» is less visually
obvious. For scenarios where we don't want visual obviousness, like
string delimiters, that's probably a win. I really don't want stealth
paint on my data infrastructure, though.
>Larry
>
>
=Austin
Jon Ericson
> The p5-to-p6 translator will turn any
>
> while (<handle>) {...}
>
> into
>
> for @$handle {...}
Including:
while(<>) {...}
to
for @$ {...}
?
Jon
Austin Hastings
> Larry Wall wrote:
And now, Piers is cackling madly at Matt: welcome to "perl6-hightraffic!"
:-)
=Austin
James Mastros
> I'm ready to propose a Great Angle Bracket Renaming.
about half the things I was worried about having to do when programming
perl6. (Not that hard -- I can't think of any more at the moment, but
I'm sure they're there somewhere.)
-=- James Mastros
*I think I just broke two or three commandments.
Brent 'Dax' Royal-Gordon
That kind of breaks the metaphor, unfortunately.
I've been thinking more on this, and I may have a better reason for
not liking this proposal. I'm going to pull a Larry and think out
loud for a minute here. Note that I speak authoritatively here, as if
I'm the language designer; this is just to avoid putting "I would..."
everywhere.
I think my problem with the proposed syntax is metaphor shear. This
example code:
for (@$input) {
...
}
works whether $input is a filehandle or an arrayref. So a user may
decide to do this:
say $input[42];
which I suspect won't work. Even if it does, this code:
for(@$input) {
...
}
say $input[0];
probably wouldn't.
The problem is that filehandles are iterators--which aren't arrays.
An iterator has different characteristics from an array--i.e. it's
accessed more or less sequentially and access is destructive.
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?
If it is, we already have a name for "fetch". In Perl 5, we call a
destructive fetch from the front of an array "shift".
So:
$fh=open "foo.txt";
say $fh.shift;
for $fh.shift($fh.elems) {
...
}
Of course, $fh.shift($fh.elems) deserves a shortcut. Perhaps
$fh.shiftall(), which creates a lazy copy and "empties" the
filehandle.
But .shift looks a bit awkward. I suggest a name change for .shift
and .unshift, so that we have:
push, pop
pull, put
So now we have:
my $fh=open "foo.txt";
say $fh.pull;
for $fh.pullall {
...
}
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; instead, the .pull and
.pullall methods are used for access. .push can be used to append to
it, .put can be used to put an item back on the front. .pop is a bit
useless, but that's not really a problem.
That doesn't mean you *can't* randomly access an iterator--after all,
it's just a lazy array copy. But it might be slower, or otherwise
unwise.
At the point where a filehandle is just an array and you can use most
normal array operations on it, I can see not having a special operator
for reading a file. Without that, though, I think the metaphor shear
of @$fh is too harsh, and the duplication between .fetch and
.[shift|pull] isn't necessary.
James Mastros
> Larry Wall wrote:
>> * We get the cute, clean and rather more typeable
>>
>> $var<key1><key2>[3]<key3>
>
> No more or less typeable for me, or anyone else who can remap their
> keyboard. I'm presuming there's something costly about {} on non-US
> keyboards, but how much does it cost? and do those non-US perl hacks use
> remapping already?
German keyboard, for example:
{ -- right alt, and the 7 key
[ -- right alt, and the 8 key
] -- right alt, and the 9 key
} -- right alt, and the 0 key
German keyboard under xfree86 but not windows:
« -- right alt, z (Well, the key that's z on an American keyboard).
» -- right alt, x
Those are /really/ hard to type, esp }, which comes up a /lot/ in perl,
weather 5 or 6, which is a big reason that I use the American keymap,
which is a constant annoyance to my girlfriend, who uses the British
keymap. (We're an American and a Brit, living in Germany.)
The problem with {} for a hash dereference operator is not it's
typeablility, but rather it's autoquoting behavior from perl5. In
perl5, the contents of {foo} are a string -- except when they aren't.
Quick:
$wheel->{roll} = 3;
$wheel->{shift} = 4;
In perl5, the first is a literal, the second shifts from @_. Whoops.
In perl6, the contents of {} is an expression. The first is an error
unless a function named roll is available (or a method on the topic?).
The second is good old shift (on the topic now).
OTOH, $wheel.<roll> and $wheel.<shift> are both literals. (The dot
there is optional.) (Until a little bit ago, that was $wheel.<<roll>>
or $wheel.«roll». (Note that I had to switch keyboard layouts again to
type that.))
-=- James Mastros
Matt Fowles
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."
-???
Uri Guttman
MW> I don't think I've ever used a hash slice in my life. Is there
MW> something wrong with me?
yes! :)
see http://www.sysarch.com/perl/tutorials/hash_slice.txt for why they
are so cool.
>> * The Texas quotes <<...>> are only needed when you *have* to interpolate.
MW> Does
MW> <<foo bar baz>>
MW> mean
MW> «foo bar baz»
i would hope << and >> always mean the same as their unicode versions. i
will be typing the long asci versions for as long as it takes me to
learn how to key the unicode in emacs (i know people have posted answers
for emacs but it still takes my tiny brane a while to learn new
keystrokes).
>> * Match vars become $<foo> instead of $«foo».
>> * A rule like <ident> now captures, while «ws» or <<ws>> doesn't.
>> I think I really like that last outcome. Capturing should be the
>> default.
>> And the low profile of «ws» makes it look like an "oh by the way".
i thought we had very different capturing and non-capturing syntax? and
with equal key counts as well. but i could be out of date with regard to
rules and grammars. i dread ruining more brane cells reading the recent
updated apocs and such. :)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Larry Wall
: I don't know what argumentless shift does now. It probably works on
: @*ARGS when you're in the main program, but inside a sub... I dunno.
: Maybe it shifts from the slurpy array argument. Shifting on the topic
: seems wrong (since you could use .shift for that).
I'd say it always shifts the slurpy array, and in Main the slurpy array
just happens to be named *@ARGGS.
Larry
Larry Wall
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
Larry Wall
: 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
John Siracusa
> Austin Hastings wrote:
>> Larry Wall wrote:
>>> * We get the cute, clean and rather more typeable
>>>
>>> $var<key1><key2>[3]<key3>
"Cute" maybe (looks like a chain of fish)
> The problem with {} for a hash dereference operator is not it's
> typeablility, but rather it's autoquoting behavior from perl5.
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'}
It's the same number of characters as:
$var<<key1>><<key2>>[3]<<key3>>
and it requires no "funny" characters. I also find it a heck of a lot more
readable than any of the others. The {' '} makes a nice vertical +
whitespace "frame" around the key. The fake doubles << and >> are way too
noisy. The funny quotes look wildly different in different fonts, but
usually end up as indistinct smudges that resemble melted "=" characters.
> OTOH, $wheel.<roll> and $wheel.<shift> are both literals. (The dot
> there is optional.) (Until a little bit ago, that was $wheel.<<roll>>
> or $wheel.«roll». (Note that I had to switch keyboard layouts again to
> type that.))
I agree that $wheel<roll> is an improvement over $wheel«roll» and
$wheel<<roll>> (although I can't decide which of those two is worse), but I
still think $wheel{'roll'} is the clear winner in all respects except
perhaps speed of typing.
-John
Matt Diephouse
> The basic problem with «...» is that most of its uses
> were turning out to be more useful that the corresponding <...>.
> In fact, I was thinking about all this on the way home from Seattle
> yesterday (a 15-hour drive), and I think I'm ready to propose a Great
> Angle Bracket Renaming.
I'm going to be difficult and say I don't actually like this proposal.
I think « and » are much more attractive than < and >, and I don't
mind the extra work to type them.
« and » are more visually distinctive, at least in my mind.
Specifically, I like that they line up with the tops of lower case
letters.
But I doubt that matters much. :-)
use CGI «:standard»;
my @list = «foo bar baz»;
my @other = %hash«several keys here»;
use CGi <:standard>;
my @list = <foo bar baz>;
my @other = %hash<several keys here>;
(Those are written out for my own benefit; consider it a goodbye.)
--
matt diephouse
http://matt.diephouse.com
Brent 'Dax' Royal-Gordon
> 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?
John Siracusa
> 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
Luke Palmer
bandwagon?
Larry Wall writes:
> * We get the cute, clean and rather more typeable
>
> $var<key1><key2>[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:
$var<foo ; 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:
$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<foo><bar>[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
Matt Diephouse
<bren...@gmail.com> wrote:
> John Siracusa <sira...@mindspring.com> 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).
Ashley Winters
> > 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
Smylers
> 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
Smylers
> In article <20041130213...@wall.org>,
> la...@wall.org (Larry Wall) wrote:
>
> > * 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".
>
> Now I'm a bit lost. I would've expected the quotes (") inside a
> different kind of quote («) to be taken literally (just as in 'foo
> "$bar" "@baz"' or qw/foo "$bar" "@baz"/).
> I'm not even sure what those double-quotation marks are doing --
> preventing $bar from being interpolated as a variable, or preventing
> the interpolated value from being white-split?
Look back at how Larry defined the guillemets:
> > * That frees up «...» for Something Else.
> >
> > * That something else is the requested variant of qw// that
> > allows interpolation and quoting of arguments in a shell-like
> > manner.
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. (Post again
if that's the case -- I have to leave for work now, but I'm sure
somebody here will be able to explain.)
Smylers
Smylers
> The basic problem with «...» is that most of its uses were turning out
> to be more useful that the corresponding <...>. ... and I think I'm
> ready to propose a Great Angle Bracket Renaming.
I very much like your proposal. (Though whether you were actually ready
to propose it yet is obviously something only you can decide ...)
> * We steal angles away from iterators.
That means that Apocalypse 2 can be updated by _removing_ an existing
"[Update]" block!
Most of the complaints about non-Ascii characters in Perl relate to the
guillemets. With your proposal they are relegated to much less-commonly
constructs, and people who really don't like them can mostly avoid
having to go anywhere near them.
> * We get <...> as the qw// shorthand where a term is expected.
I like that. When Apocalypse 2 first came out I switched to using
angles as C<qw> delimiters most of the time, such as:
use Some::Module qw<this that>;
in an attempt to get used to them having that meaning, and so there's
less of a jump to Perl 6. Over 3 years later I can report that they
work very well for this.
> * 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.
Good. That is the single thing I find hardest to teach to beginners in
Perl 5; output has an explicit C<print> statement, but the input doesn't
appear to be anywhere in the code -- there's just some brackets in a
C<while> loop, and it doesn't occur to people that brackets might have
the effect of reading from a file.
However, does anything in this proposal conflict with keeping C< <> > as
the special-case token for reading from standard-input-or-the-files-
named-on-the-command-line? That way people who like that super-short
idiom get to keep it, in:
for <> { ... }
while anybody who's gone to the bother of typing out a named stream has
to put a little more effort in to specify that iteration is required.
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : «...»
That makes good sense. It also means that people are free to continue
to ignore the variant they don't like (such as the many people who
prefer to use C<"> quotes in Perl 5 even when no interpolation is
required), which to some extent reduces the validity of any carping.
Bearing in mind how much more can now be done with out unicode (or ugly
C< << > variants) and I think this proposal should result in a nett
carping reduction (especially by people who don't following this mailing
list closely and therefore haven't been getting used to the previous
scheme -- I'm sure it'd be received better by those people who are yet
to meet any Perl 6 at all).
Smylers
David Green
bren...@gmail.com (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
*@$fh.pull ...)
>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
David Green
>First the bad news:
> * We accept that the C<< < >> operator requires whitespace
> around it, and be prepared to be burned in effigy occasionally.
I wouldn't go that far, although when I inevitably get burned by it,
I might let slip some intemperate comparisons regarding whitespace and
programming in Python... =)
> * That means that, roughly, we have this proportion:
> '...' : "..." :: <...> : «...»
I wasn't sure at first, but I think you just sold me. (I'm a sucker
for parallels.)
> * 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".
Now I'm a bit lost. I would've expected the quotes (") inside a
different kind of quote («) to be taken literally (just as in 'foo
"$bar" "@baz"' or qw/foo "$bar" "@baz"/).
I'm not even sure what those double-quotation marks are doing --
preventing $bar from being interpolated as a variable, or preventing
the interpolated value from being white-split?
(Of course, to keep the pattern going, I'd propose < for no
interpolation, << for interpolation (but not subsequent splitting), and
introduce <<< for going whole-hog and interpolating *with* subsequent
splitting. (Not that I'm saying I'd actually ever use <<<triple
quotes>>>, I just wanted to propose them for the parallelism.))
> * A rule like <ident> now captures, while «ws» or <<ws>> doesn't.
>I think I really like that last outcome. Capturing should be the default.
>And the low profile of «ws» makes it look like an "oh by the way".
I don't think I like that as much as you do. I'm not sure I *dislike*
it either... but I would be tempted to say that the double guillemets
should do twice as much (identify AND capture). That might be simply
because I'm not used to it, though. Either way, I know I really like
being able to drop the parentheses when capturing like that.
Overall, I think the new proposal is an improvement.
-David «foo» Green
David Green
Smy...@stripey.com (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
Matthew Walton
> 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.
Matthew Walton
> Matthew Walton skribis 2004-12-01 9:55 (+0000):
>
>>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
>
>
> 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?
Juerd
> Well that depends... are you intending to write programs, or drive the
> world insane?
Yes.
Juerd
Juerd
> 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/.
> 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.
Juerd
Smylers
> Pair notation is, as I understand it, when you get
>
> key => value
That can now also be written as:
:key<value>
or, where value is 1, simply as:
:key
I suspect it was this form that Larry was referring to.
Smylers
John Siracusa
> 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.
> 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!
Even if I don't use it, I'd like it not to be ugly and awkward (or, heaven
forbid, non-ASCII) because I'm likely to have to read and edit it a lot
(just as I have to deal with a lot $of{this} these days...sigh)
Although I like the single/double angle swap in most places, I'm definitely
not a fan of the "fragile fish chain" syntax for hash keys.
-John
Larry Wall
: >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.
Yes, that's the sort of thing I mean. I actually want it for enum defs:
my Scalar enum hex « :zero(0) one two three four five six seven eight nine
:ten<a> eleven twelve thirteen fourteen fifteen »;
: 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.
You can replace the whole darn grammar if you like, so it's certainly
possible. I don't think we'll go out of our way to make it easy
though. Probably requires a lookahead on the identifier rule to
see if the next thing happens to be a => workalike. Alternately,
you have to do syntax tree munging with an infix macro, since by the
time you see an infix macro its left argument is already parsed.
Larry
Jon Ericson
> On Tue, Nov 30, 2004 at 03:03:38PM -0800, Jon Ericson wrote:
> : while(<>) {...}
> You left out the most important phrase:
>
> "or whatever we decide is the correctest idiom."
I saw that, but I didn't know what to make of it. The Perl 5 idiom is
pretty magic and I don't know if it's correcter to make it more or
less explicit:
for *$ARGV {...}
Only I wonder if the magic handle should be called $INPUT or
something.
> 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.
Lovely? But I'm afraid of extra typing. ;-) It looks like the shell
idiom:
for f in *; do ...; done
Jon
Michele Dondi
> I like this in general. However...
>
> Larry Wall <la...@wall.org> 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?
[snip]
> Any other suggestions, people?
I think I will miss angles... well, at least for some time. Of the
proposal above I like best @$fh, since it's the one that most conveys the
idea of syntactic sugar for iteration while still being fundamentally
intuitive.
Michele
--
Se, nella notte in cui concepi' il duce,
Donna Rosa, toccata da divina luce,
avesse dato al fabbro predappiano
invece della fica il deretano,
l'avrebbe presa in culo quella sera
Rosa sola e non l'Italia intera.
- Poesia antifascista
Michele Dondi
> How about just having C< system() > return a clever object with .output and
> .err methods?
interesting...
Michele
--
> Windows shuts down automaticaly giving an count down. what could be
> the problem
Windows?
- "Le TeXnicien de surface" in comp.text.tex
Luke Palmer
> Is all the "Extensible metasyntax (<...>)" being changed to «...» ?
>
> Or is the new rule that <...> is capturing metasyntax, and «...» is
> non-capturing metasyntax?
That's the one.
> You can't really capture anything on an assertion, so
> /^foo .* <( do { say "Got here!" } or 1 )> .* bar$/
> is probably not an issue at all.
>
> How are the results different between these?
>
> /<ident>/
Puts <ident>'s match object in $<ident> (of the current match object).
> /(<ident>)/
Puts <ident>'s match object in $<ident> and its text in $1.
> /(«ident»)/
Puts the text captured by «ident» into $1.
Luke
Larry Wall
: Does / <-<alpha>> / capture to $0{'-<alpha>'} ?
: Or should that be written / <-«alpha»> / ?
At the moment I've got it that only assertions of the form <word> capture.
Anything else you have to do an explicit binding, or use :keepall.
Larry
Brent 'Dax' Royal-Gordon
> Speaking of "at the moment", I just now updated the Synopses at
> dev.perl.org.
The new S2 says:
# Heredocs are no longer written with <<, but with an adverb on any other
# quote construct:
#
# print qq:to/END/
# Give $amount to the man behind curtain number $curtain.
# END
Does "any other quote construct" include rx//? I've wanted that for a
while in Perl 5 (although with anonymous rules, I suppose it's no
longer that important...).
# In order to interpolate an entire hash, it's necessary to subscript with
# empty braces or angles:
#
# print "The associations are:\n%bar{}"
# print "The associations are:\n%bar<>"
Am I to assume you can use empty French/Texas quotes, too? (i.e.
%bar«» or %bar<<>>).
This paragraph also made me realize: am I the only one who foresees
somebody doing this?
$OUT.printf("We produced <b>%d</b> somoflanges this month!\n", $content);
(Granted, the fix is trivial--just replace the double-quotes with
single-quotes, or add some of that optional spacing HTML lets you
splatter around--but it seems like an easy mistake to make.)
Finally, I noticed that the "Files" section only talks about iterating
over all lines. Do you have a decision on single-line reads yet?
[And a note to the editors of dev.perl.org: can we get tables of
contents on these documents? While it's nice to exercise Firefox's
slick find-in-page interface so much on, say, Apocalypse 12, it'd be
more convenient to just have a TOC.]
Larry Wall
: On Thu, Dec 02, 2004 at 02:54:42PM -0700, John Williams wrote:
: : Does / <-<alpha>> / capture to $0{'-<alpha>'} ?
: : Or should that be written / <-«alpha»> / ?
:
: At the moment I've got it that only assertions of the form <word> capture.
Which is a bit odd, insofar as <null> gets captured by that rule...
Speaking of "at the moment", I just now updated the Synopses at
dev.perl.org. The juiciest new bits are probably in S2, though there
are ramifications in any Synopsis marked as having been updated Dec 2.
Anonymous enums are kinda cool now:
%mo = enum «:Jan(1) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec»;
(The Apocalypses aren't updated yet. Tomorrow maybe, unless I get sucked
back into my little pet p5-to-p6 translator project.)
Larry
John Williams
> Here's the proposal.
>
> First the bad news:
> * We accept that the C<< < >> operator requires whitespace
> around it, and be prepared to be burned in effigy occasionally.
My biggest worry about this is that people will be writing
if $x<3
loop( $x=0 ; $x<10 ; $x++ )
more than occasionally.
> * We steal angles away from iterators.
I vote we do that in any case.
> Now, that has certain interesting outcomes.
>
> * We get <...> as the qw// shorthand where a term is expected.
>
> * Most uses of qw// involve strings and lists, so there's little
> visual interference with numeric comparison operators.
>
> * We get the cute, clean and rather more typeable
>
> $var<key1><key2>[3]<key3>
I'm starting to like $var{'key1'}{'key2'}[3]{'key3'} more and more.
And it's the only way to write $var{'key with spaces'}, right?
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : «...»
That's definitely worth a cuteness award.
> Now with those out of the way, the good news:
> * All other uses of «...» and <...> swap, pretty much.
Moving this to the end, because I want to request clarification in the
context of rules.
> * Match vars become $<foo> instead of $«foo».
>
> * A rule like <ident> now captures, while «ws» or <<ws>> doesn't.
Is all the "Extensible metasyntax (<...>)" being changed to «...» ?
Or is the new rule that <...> is capturing metasyntax, and «...» is
non-capturing metasyntax?
Does / <-<alpha>> / capture to $0{'-<alpha>'} ?
Or should that be written / <-«alpha»> / ?
You can't really capture anything on an assertion, so
/^foo .* <( do { say "Got here!" } or 1 )> .* bar$/
is probably not an issue at all.
How are the results different between these?
/<ident>/
/(<ident>)/
/(«ident»)/
~ John Williams
Larry Wall
: Larry Wall <la...@wall.org> wrote:
: > Speaking of "at the moment", I just now updated the Synopses at
: > dev.perl.org.
:
: The new S2 says:
: # Heredocs are no longer written with <<, but with an adverb on any other
: # quote construct:
: #
: # print qq:to/END/
: # Give $amount to the man behind curtain number $curtain.
: # END
:
: Does "any other quote construct" include rx//? I've wanted that for a
: while in Perl 5 (although with anonymous rules, I suppose it's no
: longer that important...).
The rx// construct is not an official quote construct because it
doesn't produce a string via run-time interpolation. But that doesn't
mean you shouldn't get access to :to somehow or other. Either we
hack it into the rx adverbs, or maybe we allow a backdoor into q//
via some kind of :rx adverb. Especially with the extended syntax
being the default, putting your rule over several heredocish lines
seems like a real win.
But we should probably look at the respective adverbs for q and rx to
see if we're setting up any awful cognitive dissonances. I confess I
haven't thought about that yet.
: # In order to interpolate an entire hash, it's necessary to subscript with
: # empty braces or angles:
: #
: # print "The associations are:\n%bar{}"
: # print "The associations are:\n%bar<>"
:
: Am I to assume you can use empty French/Texas quotes, too? (i.e.
: %bar姣 or %bar<<>>).
Yes.
: This paragraph also made me realize: am I the only one who foresees
: somebody doing this?
:
: $OUT.printf("We produced <b>%d</b> somoflanges this month!\n", $content);
:
: (Granted, the fix is trivial--just replace the double-quotes with
: single-quotes, or add some of that optional spacing HTML lets you
: splatter around--but it seems like an easy mistake to make.)
Probably also a fairly easy mistake to catch if we discourage slash as the
first character inside a <...>. So maybe they'd get a warning unless they
wrote < /b > instead. Or maybe even an outright compilation error.
But there's no doubt that there will be occasional interference between *ML
and <> subscripts.
: Finally, I noticed that the "Files" section only talks about iterating
: over all lines. Do you have a decision on single-line reads yet?
Nope, though C<pull> is cute. But we still have this fundamental
underlying question of how much we want to unify array and iterator
notation that hasn't really been resolved. It seems a shame to set
up arrays with all these queue-like operations and then not use that
to describe, for instance, gather/take queues, or other inter-thread
message queues. So what if .[] isn't implemented, or is slow?
If you only ever shift/pull an array, does it matter? And really,
the essence of arrays is ordering: the indexability is only a side
effect of that.
But then are we willing to rename shift/unshift to pull/put? If we're
gonna go that far, we might as well switch all the bracket characters
around. Oh, wait...
I suppose it might be argued that if we present a queue as an array,
someone will index it instead of shifting it, and end up storing the
whole history of the queue in memory. Seems like a weak argument,
though. We already have that problem with arrays bound to infinite
generators.
I guess the only real argument against unifying is that neither of
for *@foo {...}
or
for @foo {...}
indicate destructive readout. Which probably says that *
is the wrong operator to use for that, which undoes our pretty
for * {...}
But "for pull" doesn't read very well. Unfortunately we don't have any
destructive "all" quantifiers in English that I can think of offhand.
I suppose "every" comes about as close as anything.
Well, hey, if we have +<< meaning numeric left shift, how about
for @foo *<< 1 {...}
meaning list left shift? :-) * .999
: [And a note to the editors of dev.perl.org: can we get tables of
: contents on these documents? While it's nice to exercise Firefox's
: slick find-in-page interface so much on, say, Apocalypse 12, it'd be
: more convenient to just have a TOC.]
I miss 'em too, but they're admittedly ugly. Maybe they could be put
at the end, with a TOC link at the front?
Larry
Larry Wall
: I guess the only real argument against unifying is that neither of
:
: for *@foo {...}
:
: or
:
: for @foo {...}
:
: indicate destructive readout. Which probably says that *
: is the wrong operator to use for that, which undoes our pretty
:
: for * {...}
This is all muddled thinking anyway, since *@ARGS would read the arguments,
not the lines from the files contained in the arguments. Despite the
history of ARGV in Perl 5, I wonder if it's a mistake to overload @ARGS
and $ARGS to mean two different things.
On the other hand, it'd be nice if we could end up with something
readable like:
for .lines {...}
where the implicit invocant of Main knows how to iterate magically through
the lines of @ARGS. I suppose that implicit invocant could be named $ARGS.
The magic still consists of making a bunch of filenames look like a single
filehandle. A method like .lines could work either on a filehandle, or
on a string representing a filename, or an array of filehandles, or an
array of strings representing filenames.
We also potentially get things like
for .slurp {...}
for .paragraphs {...}
But we have to be careful with things like
for "foo".bytes {...}
since "foo".bytes returns 3, not the bytes of file "foo". So there
needs to be some intermediate method to say that you mean io. Taking a
page fro IO::All, I suppose we could have "foo".io.bytes or some such.
But $ARGS would already be an io object, so people presumably wouldn't
have to always say
for .io.lines {...}
As I've said before, I like the idea of IO:All, except for the
overloading of < and >. Perhaps we could go with <== and ==> instead.
Larry
Herbert Snorrason
best about Perl is the amazing simplicity of the <> input construct.
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. Neither the conceptual "input operator" nor the extremely
handy idiom for "behave like a Unixy filter" should go. Please.
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.
--
Schwäche zeigen heißt verlieren;
härte heißt regieren.
- "Glas und Tränen", Megaherz
Larry Wall
: 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
Matt Diephouse
> 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<tie>, 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
Smylers
> But then are we willing to rename shift/unshift to pull/put?
Yes. C<unshift> 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
Larry Wall
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 =@handlelist {...}
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
Larry Wall
: 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
David Green
mdd...@gmail.com (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<for $iter1, $iter2,
$iter3 {...}> only loops through the *list* of iterators, not through
each object itself.
So maybe we do need Larry's new =@iters 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<for
*$iter1, *$iter2, *$iter3 {...}> would do it, but I'm not sure about
C<for *@ARGS {...}>. (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
Herbert Snorrason
> for =$*IN {...}
> for =$*ARGS {...}
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 =@*ARGS {...}', then?
Matt Diephouse
> In article <198c873804120...@mail.gmail.com>,
> mdd...@gmail.com (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<does 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.
Rod Adams
> 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 =@handlelist {...}
> 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 =@handlelist= {...}
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