Re: Angle quotes and pointy brackets
On Sat, 27 Nov 2004 10:28:28 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > On Fri, Nov 26, 2004 at 02:10:06PM -0800, Larry Wall wrote: > : I know everone has their reflexes tuned to type qw currently, but > : how many of you Gentle Readers would feel blighted if we turned it > : into q:w instead? > > Of course, if we wanted to really drive it into the ground, we could > turn qq// into q:q//, and then there's only one quoter. I'm sure if we > tried hard enough we could find someone this appeals to. You don't even have to look very far. This seems like a decent idea to me (although I won't be sad if it doesn't happen). > We also haven't quite detangled the backslash options. Seems there are > four levels of support (using \/ to stand for any terminator character): > > 0) none # <<'' default > 1) \\ and \/# q// default > 2) list # (nothing builtin) > 3) all # qq// default > > We need some way of specifying level 0 for a non-heredoc. We could turn > q// into that, I suppose. If we did, either we'd have to make '' the > same, or let it differ from q//, neither of which quite appeals to me, > but I might let myself be argued into one of them or the other. Actually, I'd like to see '' be a simple, completely raw quoting construct. But if we don't do that, we might be able to take a page out of C#'s book with @"" as the short form of the raw quoting construct. (Or something like that--I suspect C# picked @ because it's otherwise unused.) Actually, if we do something else with backticks, we can steal backticks for totally raw quoting... > I'm open to other ideas, though we must remind > ourselves that this is all very bike-sheddish. Oh, I vote for blue paint on that bike shed. -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker There is no cabal.
Re: Angle quotes and pointy brackets
James Mastros wrote:
Larry Wall wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
: qx:noparse 'echo $VAR' ?
I think we need two more adverbs that add the special features of qx
and qw,
so that you could write that:
q:x/echo $VAR/
where ordinary qx/$cmd/ is short for
qq:x/$cmd/
I think I'd like that much better if we consider execution and
word-splitting to be the primary operations, and interpolation and
noninterpolation the adverbial modifiers then the other way around,
making that qx:q/echo $VAR/ or qx:qq/$cmd/. OTOH, I expect backticks to
be rare enough that I wouldn't mind writing
use Spawn 'spawn';
spawn :capture :wait ($cmd);
spawn :capture :wait ('echo $VAR');
Much more clear, saves ` for other things, and allows for easy
specification of the many adverbs of spawn (weather it returns the
return status, the PID/FH set object, or output, if it waits right
there, or runs in the background (and makes the return value lazy), if
it replaces the current process (exec)...
I'd quite like that. Although I think spawn should be a builtin rather
than in a module, if it was in the core, and we were getting rid of
backticks.
Although I'm masochistic enough that I don't mind the idea of always
having to do execution with qx//, qx:q// or qx:qq// (running with other
suggestions, I'd guess that would be non-interpolating execution, then
the same again more explicitly, then interpolating execution) but I do
like the idea of spawn.
Kind of removes the idea of pulling in the output of other programs as a
fundamental part of the language though, for that it's nice to have an
executing, capturing quote. Perhaps an adverb to qx that makes it behave
like system() - I don't think it'd be a good idea to provide one that
makes it behave like exec(), although perhaps other people do.
qx:r/$cmd/
qx:s/$cmd/ # both of these give back return codes? Which one!
But then
qx:r:qq// might be messy.
Or even
qx:exitcode:interpolate//
Ouch.
This isn't very coherent, I'm just thinking out loud based on what other
people have said that I like.
But there are some things that would be completely ambiguous:
%hash
Bracketing operator.
%hashVery long bracket operator, which quite likely has a syntax error
directly after it.
But might not have... there's a chance that could slip through, and I
don't like that for some reason.
: or maybe even we could see consistant to go after +<< +>> and alike,
and : make old < and > written as +< and +> (and then lt and gt
suddenly could : become ~< and ~> :)
I think people would rise up and slay us if we did that. We're already
getting sufficiently risen up and slain over Perl 6.
Could be worse. They could rise from the grave and eat us!
Who says they won't?
Well, yes, but sometimes the weights change over time, so it doesn't
hurt (much) to reevaluate occasionally. But in this case, I think I
still prefer to attach the "exotic" characters to the exotic behaviors,
and leave the angles with their customary uses.
...of which they have plenty already. Backtick has exactly one, and not
an often-used one at that... I'm fine with axing it. Of course, there
are a lot more people in the world then just me.
I'm fine with it too. I use it a fair bit but I think it's important to
have a very clear mark where you're going to an external program
Re: Angle quotes and pointy brackets
On Sat, Nov 27, 2004 at 08:21:06PM +0100, Juerd wrote:
> James Mastros skribis 2004-11-27 11:36 (+0100):
> > Much more clear, saves ` for other things
>
> I like the idea. But as a earlier thread showed, people find backticks
> ugly. Strangely enough, only when used for something other than
> readpipe.
>
> The idea of being able to write
>
> %hash{'foo'}{'bar'}{$foo}[0]{$bar}
>
> as
>
> %hash`foo`bar`$foo`0`$bar
>
> still works very well for me. At least on all keyboards that I own, it
> is easier to type. And in all fonts that I use for terminals (that'd be
> only misc-fixed and 80x24 text terminals), it improves legibility too.
Doesn't that cause ambiguity between:
%hash{'foo'}{'bar'}{$foo}[0]{$bar}
and
%hash{'foo'}{'bar'}{$foo}{0}{$bar}
^ ^ hash instead of subscript
--
Re: Angle quotes and pointy brackets
On Sun, Nov 28, 2004 at 12:24:08PM -0500, John Macdonald wrote:
> On Sat, Nov 27, 2004 at 08:21:06PM +0100, Juerd wrote:
> > James Mastros skribis 2004-11-27 11:36 (+0100):
> > > Much more clear, saves ` for other things
> >
> > I like the idea. But as a earlier thread showed, people find backticks
> > ugly. Strangely enough, only when used for something other than
> > readpipe.
> >
> > The idea of being able to write
> >
> > %hash{'foo'}{'bar'}{$foo}[0]{$bar}
> >
> > as
> >
> > %hash`foo`bar`$foo`0`$bar
> >
> > still works very well for me. At least on all keyboards that I own, it
> > is easier to type. And in all fonts that I use for terminals (that'd be
> > only misc-fixed and 80x24 text terminals), it improves legibility too.
>
> Doesn't that cause ambiguity between:
>
> %hash{'foo'}{'bar'}{$foo}[0]{$bar}
> and
> %hash{'foo'}{'bar'}{$foo}{0}{$bar}
> ^ ^ hash instead of subscript
Hmm, I guess it is usually not ambiguous, only when it is
causing auto-vivification of the hash-or-array with `0` is
there an ambiguity between whether that means [0] and {'0'}.
--
Re: Angle quotes and pointy brackets
John Macdonald skribis 2004-11-28 12:24 (-0500):
> 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
Re: Angle quotes and pointy brackets and heredocs
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
I notice that in Perl6 thoose funny « and » could be much more common
than other paired brackets. And some people likes how they look, but
nobody likes fact that there's no (and won't!) be a consistent way to type
them in different applications, wether it's hard or easy.
But to swap «» with [] or {} could be real shock for major part of
people..
We also have another ascii pair, < and > . maybe they could be better than
« and » ?:) i'm not that farseeing, but isn't problem of distinguishing <
as a bracket and < as an comparison operator no harder than distinguishing
<< as bracket and as part of heredoc?..
Speaking of heredocs.
Are they really common enough to merit a "two char, absolutely no
whitespace after it" lexical? Especially one that looks a lot like the
left bitshift operator, as well as an ASCII version of a Unicode quoting
and splitting character?
What if instead, we add a different adverb to q// and qq//? something
like :h. That way people can mix and match all the quoting option they
want, and we remove some annoying requirements about when you can and
cannot have /<<\s+/ in your code.
P5:
print <<"END", " done.\n";
line 1
line 2
END
P6:
say qq:h/END/, "done.";
line 1
line 2
END
As for the topic being discussed,
Since < and > are now full class quote-like thingies in P6REs, much to
the chagrin of those of us who parse html on a regular basis, using them
as such in the rest of P6 makes sense as well. Parsing should not be
hindered since one would occur in operator context, and the other in
expression context.
-- Rod Adams
