Re: Lexing requires execution (was Re: Will _anything_ be able to
It's quite a disappointment in some ways, but we've lived with it in Perl 5, and I'm sure we can live with it in Perl 6. And I still think Perl 6 will have fewer cases in which it's completely impossible for not-Perl to parse it. Unfortunately, fewer still implies some, and some is still a problem. Frankly, as the only person who has managed to get together a guessing lexer that is sufficiently accurate to be something other than useless, I see nothing in Perl 6 that makes it any easier than Perl 5. In fact, my reason for starting this thread in the first place is because I was increasingly getting the feeling there would be MORE problems. The prototype and operator/operand content problem is still there. PPI works around it with quite a bit of hackery (look ahead, look behind, look ahead again, and shake it all about. Do the hokey pokie etc etc) For the relevant code, look for '47' in http://search.cpan.org/src/ADAMK/PPI-0.831/lib/PPI/Token/Whitespace.pm This can still be easily tricked if you are trying to (see Randal's examples again), but usually gets most real world code right. Then again, I avoid the whole problem of attaching params to sub calls by not doing it at all. The closest I can get is to list a set of tokens within a statement. Perl 6 has the same problems, and then also adds a higher likelyhood of encountering custom grammars than in Perl 5, where source filters are considered largely bad form. The fundamentals would appear to be the same. As a side note, I may have used parse erroneously. What PPI attempts to do is to be a tokenizer and a lexer, without understanding its function as code. So perhaps a syntax lexer is a closer term. The ability to read in and work with code based purely on syntax, without needing to know what it means. Adam
Re: Angle quotes and pointy brackets and heredocs
Rod Adams skribis 2004-11-29 1:56 (-0600):
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
Re: Lexing requires execution (was Re: Will _anything_ be able to
Adam Kennedy wrote: Frankly, as the only person who has managed to get together a guessing lexer that is sufficiently accurate to be something other than useless, Hm. I must confess that I don't consider Text::Balanced's Cextract_codeblock subroutine to be entirely useless. And presumably neither do the thousands of people who use it every day to parse all kinds of Perl code inside their Parse::RecDescent grammars, and in many other embedded code applications as well. So maybe you're not the *only* person to have built a useful guessing lexer? Though I'm happy to concede that yours might well be the best. I see nothing in Perl 6 that makes it any easier than Perl 5. What? Not even the runtime-accessible Perl parsing grammar embedded directly in the Perl 6 language itself? When the language can accurately parse itself, a guessing lexer would seem no longer to be necessary. And even if it is still desirable, it will be vastly easier to construct in Perl 6, by deriving a simplified parser from the standard Perl grammar. As a side note, I may have used parse erroneously. What PPI attempts to do is to be a tokenizer and a lexer, without understanding its function as code. So perhaps a syntax lexer is a closer term. The ability to read in and work with code based purely on syntax, without needing to know what it means. ...is simply not possible with Perl. Any more than it's possible to create a tokenizer and lexer for English text, without understanding that text's function as language. Perl is sufficiently complex that you just cannot lex it without the contextual information provided by parsing it (and sometime evaluating it). We're not going to fix that...because it's not broken. It's an enormously powerful *feature*. Unfortunately it's a feature that, by its very nature, precludes the feature that you want (i.e. simple static lexing). I'm sorry about that. But not *very* sorry, because whenever you optimize for static lexability you end up with a language with all the nuanced expressive power and syntactic flexibility of, say, Pascal or Java. :-( Damian
Backticks (was: Angle quotes and pointy brackets)
Matthew Walton [EMAIL PROTECTED] 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] 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?
Re: S13: Deep operators
On Thu, 2004-11-25 at 05:29, Michele Dondi wrote:
OT
On Wed, 24 Nov 2004, David Ross wrote:
I have been studying PERL 5 core and modules to identify options and
issues for meta-architectures and automated code generation. PERL 6
documents and discussion provide insight essential to effectively using
PERL 5 and preparing for PERL 6.
[snip]
developing in PERL struggling to catch up. The conceptual and concrete
Funny to notice how you could study PERL{5,6} so much still failing to
realize that there's not such a thing as PERL. See
perldoc -q 'difference between perl and Perl'
Thanks for pointing that out. Its been a long time since I have looked
at that part of the documentation. If I was asked to name one thing that
maOur fearless leader's :-) training in linquistics. Its all about
context.
I just read the output from perldoc, proably for the first time. It
makes perfect sense, but I help liking anything pathologically eclectic
... better.
No offense intended,
Michele
Non-taken. Its not uncommon for me to make entertaining errors. I am a
spell checker junky. Details are important, if you want to avoid the
devil(s) hiding there in.
I did say I was struggling to catch up and was not even certain my
comment/question would be considered relevant. Having some confirmation
that I am getting it is good.
david
email:[EMAIL PROTECTED]
Re: Backticks (was: Angle quotes and pointy brackets)
Jon Ericson writes: Matthew Walton [EMAIL PROTECTED] 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.orgrnum=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
Re: Backticks (was: Angle quotes and pointy brackets)
Luke Palmer skribis 2004-11-29 16:10 (-0700): http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.orgrnum=1clarify It says that backticks won't be used at all in Perl 6. That's (the) one key of the keyboard that we're leaving to user-definition. It says that, but after saying Leaving aside the use of C`` as a term And that use of backticks is what this subthread appears to be about. As I interpret it, backsticks for qx, unless elsewhere declared gone, are still there. Juerd
Re: Backticks (was: Angle quotes and pointy brackets)
Juerd writes: Luke Palmer skribis 2004-11-29 16:10 (-0700): http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.orgrnum=1clarify It says that backticks won't be used at all in Perl 6. That's (the) one key of the keyboard that we're leaving to user-definition. It says that, but after saying Leaving aside the use of C`` as a term And that use of backticks is what this subthread appears to be about. As I interpret it, backsticks for qx, unless elsewhere declared gone, are still there. Sorry, I misread. Luke
Re: Backticks (was: Angle quotes and pointy brackets)
Juerd writes: 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
Re: Angle quotes and pointy brackets
Matthew Walton wrote:
James Mastros wrote:
Larry Wall wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
: qx:noparse 'echo $VAR' ?
I think we need two more adverbs that add the special features of qx
and qw,
so that you could write that:
q:x/echo $VAR/
where ordinary qx/$cmd/ is short for
qq:x/$cmd/
I think I'd like that much better if we consider execution and
word-splitting to be the primary operations, and interpolation and
noninterpolation the adverbial modifiers then the other way around,
making that qx:q/echo $VAR/ or qx:qq/$cmd/.
especially because adverbs are meant to say how to do rather than what
to do, aren't they?
OTOH, I expect backticks to be rare enough that I wouldn't mind writing
use Spawn 'spawn';
spawn :capture :wait ($cmd);
spawn :capture :wait ('echo $VAR');
Although I'm masochistic enough that I don't mind the idea of always
having to do execution with qx//, qx:q// or qx:qq// (running with other
suggestions, I'd guess that would be non-interpolating execution, then
the same again more explicitly, then interpolating execution) but I do
like the idea of spawn.
hm.. qx:q// qx:qq//
...compare with:
qx q// qx qq//
so there's no need in adverbs. But we have no need in qx either. Why to
introduce (or REintroduce) something if we have something similar already?
$captured = system :capture q/cmd../;
or maybe even:
(code=$code, out=$captured, err=$err) = system qq/cmd/;
or maybe even(!)
$captured = slurp qq/$cmd |/;
Kind of removes the idea of pulling in the output of other programs as a
fundamental part of the language though, for that it's nice to have an
executing, capturing quote. Perhaps an adverb to qx that makes it behave
like system() - I don't think it'd be a good idea to provide one that
makes it behave like exec(), although perhaps other people do.
I haven't that long unix background, and spawning processes is a very
*fat* operation for me.. maybe after year or two I'll change my point of
view, but for now I would be pretty happy with a 'slurp' variant. IMHO,
spawning processes has nothing to do with other quoters, and perl already
went far away from shells.
but talking about oneliners and short shell-like scripts, where `` is
pretty useful.. hm.. things good for oneliners are rarely as good for
larger programs, and vice versa. Of course, Perl5 proves opposite, but
Perl6 tends to be a little more verbose, and even in Perl5 we use quite
different toolbox and style for mentioned above. Why not to make an
average sized module of various shortcut grammars, with a very short
name (x, f.e.), with defaults to export :all, so we could just do
perl -Mx -e 'print `echo this is a perl5qx`'
even if `` would be taken for something more useful in Perl6,
and still be able to import only something useful for our larger program
with
use x qw/:perl5qx/;
Re: Angle quotes and pointy brackets
Alexey Trofimenko skribis 2004-11-30 3:17 (+0300): 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
Re: Angle quotes and pointy brackets
On Sat, 27 Nov 2004 11:36:14 +0100, James Mastros [EMAIL PROTECTED] 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..
Re: $ @ and %
P.P.P.S. If answer on my why? would be just because! I would take it silently. yes, answer was as I predicted above. I promised.. ..but: As far as I understood, arrays and hashes, and references them are much more similar in Perl6 than it was in Perl5. F.e. we have @a and $a = [EMAIL PROTECTED]; the same: push @a,1,2,3 push $a, 1,2,3 $b = @a $b = $a (?) say @a[] say $a[] (?) myfunc( [EMAIL PROTECTED])myfunc ( *$a) ... were all thoose right? hm.. i'm not so competent to continue that list.. could anyone kind make a comparison table? yes, please! I think, answer could be very informative for other readers too. and even could make it's way to perl6 documentation. So, where's @a and [EMAIL PROTECTED] are the same, and where they aren't? in all other places where they work different, we could use @$a in place of @a, right? if @ in @a is a part of name, would @$b work? and what's that @ here, behind the scenes? operator? macro? ... P.P.P.P.S open $file, filename; print @file; ... ..er, in that case: open $file, filename; print @$file; i mean, what about using objects(files, iterators, etc) as arrays? AFAIK, we will have custom subscripting defined on our objects, so $file[10] could be made to work, but what about @$file, or @($file) or $file[] (um, maybe $file[*], I forgot) would it make any sense? and, one more question: if we would have both tying (arrays which call hidden object methods) and objects which could act as array references, where's a difference between them? could it be THE same? Should it? could we write my $a = new ArrayLikeClass; my @b := @$a; or my @b := $a; (which one is right?)
Perl 6 Summary for 2004-11-22 through 2004-11-29
Perl 6 Summary for 2004-11-22 through 2004-11-29 All~ Rather than try to do something witty about the strange music I am listening to, or the stuffed animals who are assisting me. I will start this summary off with an entirely self-serving request. abuseA while ago I saw the quote Computer Science is merely the post-Turing Decline of Formal Systems Theory. without an attribution. I have tried to find an attribution for it, but have been unable to find one. If any of you know it, that information would be appreciated./abuse With that out of the way, I bring you Perl 6 Language Deep Operators Last week, Matthew Walton wondered about Deep Operators and if they would work as he expected. As I tentatively predicted, the answer came back and was yes. Then the thread got side tracked with context and Perl vs perl vs PERL concerns. http://xrl.us/d6wj gather to separate bins Dave Whipp wanted to know if he could use gather/take with multiple bins. Michele Dondi suggested using adverbs for it. Rod Adams pointed out that as gather is inherently lazy the two binned approach could cause strange results (like churning for a while filling one bin trying to get an element for the other). Of course, not being able to do it would mean possibly having to compute an expensive generate function more than necessary, unless it is memoized... http://xrl.us/d6wk « in here-docs Thomas Seiler has decided to test my copy-paste-fu by starting a discuss on characters that don't appear on my keyboard. His question was if «END could start a here-doc. The answer appears to be no. http://xrl.us/d6wm -- here-doc « != The above thread led to a discussion of the various quoting operators, and the differences between «» and . This led to much discussion on the finer points of qw, qx, and qq (among others). Juerd suggested scrapping qx and qw in favor of qq:x and qq:w, which Larry liked. Rod Adams suggested scrapping END in favor of qq:h/END/, which I like. http://xrl.us/d6wn unifying namespaces Alexey Trofimenko wondered about unifying the $, @, and % namespaces. Larry told him that this ship sailed long ago and that it was not changing. http://xrl.us/d6wo Lexing/Parsing Perl6 without executing code Adam Kennedy wants to be able to syntax color (and possible perform basic programatic manipulations of perl6 code). Anyone who has used a good IDE like Visual Studio, Eclipse, or IntelliJ probably understands where he is coming from. He does not, however, want to execute arbitrary code in the process of doing this. Much discussion ensued, but it does not look like he will be able to do this. Quite the tragedy, but perl is simply too dynamic to be docilly lexed like static languages. http://xrl.us/d6wp Perl6 Compiler Nice Work Nick Glencross has the honor of the only message on p6c this week. But his sentiment is shared by all. Nice work, Patrick. http://xrl.us/d6wq Parrot Internals Parrot_compreg.sig Bernhard Schmalhofer noticed that Parrot_compreg had a different signature then documented, so he submitted a patch to fix it. Leo applied it. http://xrl.us/d6wr opcode numbering Leo added a TODO ticker for opcode numbering. http://xrl.us/d6ws tests pass, but create core files I reported that on my machine all of the tests claim to pass, but core files appear in the parrot directory. Dan confirmed my suspicion that this was a real problem. I tried to supply helpful information like backtrace, but Warnock applies. http://xrl.us/d6wt -- initial message http://xrl.us/d6wu -- squeeky wheel gets the kick? pcc cleanup Leo removed the recently deprecated P0, P1, P2 usage. Relatively few tests break as a result. http://xrl.us/d6wv Namespace-sub invocation Luke Palmer wanted to know if there was syntax for calling subs from a particular namespace. Leo provided the answer, call it as a method on the namespace PMC. http://xrl.us/d6ww Reserved Words Annoy Luke Palmer wondered if he could define a .sub new to get around reserved word problems. Leo added the support, but warned him not to use spaces or such. http://xrl.us/d6wx Lexicals, Continuations, Register Allocation, and ascii art This thread (and the ones that preceded it) have made me wish that gmail and google groups had a fixed width font option. Sadly, this summary will probably not get me it, as it did not get me p6c either :-( Ah well. The problems associated with lexicals and continuations churned. There was a plea for guidance from Dan. Hopefully he will guide us shortly. http://xrl.us/d6wy -- one thread about it http://xrl.us/d6wz - and another (with plea) old Parrot question Bloves had a question about
Re: Angle quotes and pointy brackets
Juerd [EMAIL PROTECTED] wrote:
but talking about oneliners and short shell-like scripts, where `` is
pretty useful.. hm.. things good for oneliners are rarely as good for
larger programs, and vice versa. Of course, Perl5 proves opposite, but
Perl6 tends to be a little more verbose, and even in Perl5 we use quite
different toolbox and style for mentioned above. Why not to make an
average sized module of various shortcut grammars, with a very short
name (x, f.e.), with defaults to export :all, so we could just do
perl -Mx -e 'print `echo this is a perl5qx`'
For oneliners, I think I'd appreciate using -o for that. The module
itself can be Perl::OneLiner.
module e {
module *::Main {
# Or whatever we'd need to do to switch to the top-level Main
close $*CODE;# if there is such a thing
no strict;
no warnings;
my macro circumfix:` ` (String $cmd)
is parsed(/ [^`\\]* [ \\ . [^`\\]*: ] * /) {
{ run :capture $cmd }
}
use File::Copy qw(mv cp);
...
# I do hope we get something better than #line.
eval #line 1 '-me'\n ~ @ARGS.shift;
}
}
perl -me 'say This is my one-liner!'
One-liners with no specific support in the core--and it's different
from Perl 5, so we can detect old one-liners. How's that for
orthagonal?
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I might be an idiot, but not a stupid one.
--c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
On Fri, 26 Nov 2004 09:33:49 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: I notice that in Perl6 thoose funny and could be much more common
: than other paired brackets. And some people likes how they look, but
: nobody likes the fact that there's no (and won't!) be a consistent way
to : type them in different applications, wether it's hard or easy.
...
: We also have another ascii pair, and . maybe they could be better
: than and ?:) i'm not that farseeing, but isn't problem of :
distinguishing as a bracket and as an comparison operator no harder
: than distinguishing as bracket and as part of heredoc?..
It would get very confusing visually, even if the computer could sort it
out:
@a = @b
@a = @b
But there are some things that would be completely ambiguous:
%hashfoobar
%hashfoobaz()
I not meant to replace it everywhere. But problem still exists.
I know about only four uses of and . Tell me if there's more?
1) hyperoperators;
@a = @b * @c @a.method
@a = @b * @c @a.method
(and, of course, mentioned in the past supercool 7-chars =:=
operator!)
hm.. IMO, hyperoperations are fat enough to be fat even in code. I
wonder only if whitespace allowed there:
@a = @b * @c @a .method
2) qw//-like construct;
@array = foo bar baz
@array = foo bar baz
@array = qwfoo bar baz
once again, there's nothing wrong. Although, using just foo bar baz
would confuse Perl6 no more than globs and filehandles confuses Perl5.
want an operator/want a term rule applies here.
3) pair(adverb) value quoting;
myfunc :foobar :barbaz
myfunc :arrayvalue1 value2 value3
myfunc :foobar :barbaz # this certainly suck
myfunc :foo(bar) :bar(baz) # I'm going to use that if it works(?).
# still this suck less:
myfunc :array value1 value2 value3
# ..than:
myfunc :array(value1, value2, value3)
but replacement of with plain here is a no-problem:
myfunc :foobar :barbaz :arrayvalue1 value2 value3
after you type :foobar only three times, you'll acquire internal alarm
on constructs like
myfunc :foobar :bar10;
which are rather obfuscating already.
IMHO, mandatory whitespace between :bar and 10 here won't make anybody
sick.
I wonder how many people would like to write it
myfunc:foobar:bar10;
4) hash subscripting;
that's a real pain.
rather cute
$varkey1key2[3]key3
suddenly becomes an ugly monster:
$varkey1key2[3]key3
of course we could write:
$var{'key1'}{'key2'}[3]{'key3'}
and I would prefer this one to previous variant..
but it adds noise too. and it prevent us to logicaly recognize 'key1' and
'key2' not as strings but as something more like struct elements, like we
got used in perl5
When I look at this
$varkey1key2[3]key3
then I think that it's a *very* cute, nice, and clean syntax... I really
like it!
(and I would sacrifice something for that to happen, if I would be Larry
:) )
but there's a problem for people and parser too. is a comparison
*operator* and hash subscript is *operator* too, and there's no way to
distinguish them at all. Term rule won't help here.
+ and + for comparison is plain sickness, of course. But we have some
whitespace rules already. One of them is that subscripts shouldn't have
whitespace to the left of them. We could add one more - to always PUT
whitespace before comparison. so
$afoo.. is a start of subscript and
$a foo.. is always a comparison.
Personally I'm not lazy to put spaces because of my little Forth
experience.
but I don't want to be lynched by mad horde of programmers in white robes,
who will discover that
while $a$b {...}
for qwa b c {...}
and even
foo()bar()...
do something completelly wrong, and parser just unable to catch this..
(hm.. bad examples.. maybe it could be made able to?)
*sigh.. I'll write my own grammar:) I only afraid that it would take a
half of all my remaining lifetime (because of addiction)
But I'll return to topic.
I've seen proposal by Juerd, somewhere it this thread, to use `` for
autoquoting subscripting.
but proposed
%hash`foo`bar`$foo`0`$bar=0
not going to work
delimiters should have corresponding closing character, so it should be
something like
%hash`foo``bar`{$foo}[0]{$bar}=0
or it would be *much* worse for parser than .
actually, (countrary to [] and {} which could have arbitrary complex
nested expressions in it) autoquoting subscript shouldn't neccessarily
be a paired string. Any character could be used for it without any
ambiguity. Even perl4 style ' or even
Same with :pairs
%hashkeyanotherkey[1]=0
%hash'key''anotherkey'[1]=0
:keyvalue
:key'value'
ah, using here would cause difficulties to interpolation of hello,
$world
so what about ' or ` (or whatever you could imagine)?
P.S. I also considered shorcuts like
$varkey1key2key3[1] # but that not going to remove MUCH of
linenoise.
or
$var.key1key2[1].key3 #
Re: Angle quotes and pointy brackets
Alexey Trofimenko writes: 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 Crun, 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 Cqx when what they meant was Csystem. Smylers
Re: Angle quotes and pointy brackets
Juerd writes: For oneliners, I think I'd appreciate using -o for that. The module itself can be Perl::OneLiner. Things the module could do: * disable the default strict The C-e flag indicating the one-liner disables Cstrict anyway. Smylers
