Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-09-27

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:12 flaviu1 Is there any better way to do name ~ [a-zA-Z]<name tmp>; <name tmp> ~ [a-zA-Z0-9_]+; ?
00:13 jeffreykegler Nope
00:14 jeffreykegler Opinions may vary re whether you want to introduce a new symbol name ...
00:14 jeffreykegler or whether you want to use some of the Perl or POSIX character classes,
00:15 jeffreykegler but basically that's a elegant as it gets.
00:15 flaviu1 Ok, just making sure. I don't really mind, I can just put them on the same line to make it obvious they are part of the same rule
00:16 jeffreykegler I deliberately left that kind of style cholce up to the user.  Note that the semi-colon is not needed.
00:16 jeffreykegler Though you may want it for clarity
00:17 flaviu1 I think it's really nice the semicolons are not required. The objective is clarity, as you said.
00:57 ronsavage joined #marpa
01:16 ronsavage flaviu1 It's something we all have to face. As in:
01:16 ronsavage generic_id_prefix~ [a-zA-Z\200-\377_]
01:16 ronsavage generic_id_suffix~ [a-zA-Z\200-\377_0-9]*
01:16 ronsavage generic_id~ <generic_id_prefix>generic_id_suffix
08:13 lwa joined #marpa
10:55 flaviu1 joined #marpa
15:10 flaviu1 the first link in https://metacpan.org/pod/Marpa::R2​::Semantics#Quantified-rule-nodes doesn't actually go anywhere useful
16:26 flaviu1 I'm using the loosen symbol to reduce ambiguity, but `let a = 2` parses as `(let a) = 2`, even though there is a rule with a much higher precedence that will also match it.
16:26 flaviu1 I suppose I could figure out a way to prevent keywords from being matched as a name, but I really have no clue why this is happening.
16:27 jeffreykegler joined #marpa
16:29 jeffreykegler flaviu1: re  http://irclog.perlgeek.de/​marpa/2014-09-27#i_9420819 --   Fixed in commit 35912fe -- Thanks!
16:30 jeffreykegler flaviu1 -- one way to differentiate keywords is to use lexeme priorities -- https://metacpan.org/pod/distribution/​Marpa-R2/pod/Scanless/DSL.pod#priority
16:31 flaviu1 Ah, my spelling is so bad I didn't notice it was just a typo or I would have fixed it myself :p
16:35 flaviu1 Ah, priorities work wonderfully! Thanks!
17:20 idiosyncrat joined #marpa
17:22 idiosyncrat left #marpa
17:46 lwa joined #marpa
17:46 shadowpaste joined #marpa
20:40 flaviu1 joined #marpa
21:32 jeffreykegler joined #marpa
21:33 jeffreykegler I've finished two new POD pages for the Marpa::R2 SLIF documentation:
21:33 jeffreykegler https://github.com/jeffreykegler/Marp​a--R2/blob/master/cpan/pod/Event.pod -- about SLIF parse events; and
21:34 jeffreykegler https://github.com/jeffreykegler/Marpa-​-R2/blob/master/cpan/pod/Exhaustion.pod -- a monograph on parse exhaustion and the SLIF
21:34 jeffreykegler These are (I hope) my most complete, coherent and accurate accounts of these two subjects yet.
21:36 jeffreykegler They are in finished draft status, waiting to go into a developer's release, so it's a good time for other eyes to look at them.
21:39 jeffreykegler They are reference docs, and not tutorials, not by any means.
22:26 flaviu1 Has anyone done python-style indentation parsing? I could probably figure something out with events - great timing with those pod pages - but I'd like to avoid duplicating work if someone else has already figured something out.
22:28 jeffreykegler You'll also want to look carefully at using LATM along with lexeme priorities and special lexemes -- for example to make certain end-of-lines have different meanings from others.
22:29 jeffreykegler Off the top of my head, I think (as usual) of jdurand's stuff.  In particular, ECMAScript's whitespace handling is unusual -- it's not the same as Python, but involves similar issues ...
22:30 jeffreykegler and jdurand and I worked out a scheme for dealing with it, rather nicely IIRC.
22:30 jeffreykegler Events are the most general way, but events are callbacks into Perl, and heavy use of them is expensive.
22:31 jeffreykegler Once we bring Lua into the picture, I hope events will become much cheaper.
22:33 flaviu1 Ok, I'm investigating jdurand's ECMAScript parser
22:41 flaviu1 https://groups.google.com/d/msg/mar​pa-parser/7yk2JhPvp5Y/4a5FFY1i5hMJ
22:46 flaviu1 http://irclog.perlgeek.de/​marpa/2014-01-13#i_8110729
22:46 flaviu1 Just for reference if someone comes across this in the future
22:59 jeffreykegler flaviu1: re http://irclog.perlgeek.de/​marpa/2014-09-27#i_9422173 -- Thanks for doing that -- among the people who will find it handy is me.
23:00 flaviu Since I don't really feel like being too adventurous, the best approach for me would be just having events on newline. I'll worry about performance later.
23:00 flaviu However, LWA's question at http://irclog.perlgeek.de/​marpa/2014-01-13#i_8114456 brings up the point of whether an indentation stack would be safe?
23:02 jeffreykegler flaviu: Sticking with events and making performance a 2nd pass is certainly a rational approach.  For many applications, that 2nd pass is optional.
23:03 jeffreykegler flaviu: Re LWA's question -- yes if your grammar is ambiguous, you've got to take into account all possibilities ...\
23:03 jeffreykegler my general approach is to make sure the grammar is not ambiguous, or failing that ...
23:04 jeffreykegler make sure the ambiguity is strictly limited, and such as to present no problem.
23:06 jeffreykegler This is usually a good idea, anyway, to make sure things stay linear, or O(n).
23:06 flaviu Right, only an ambiguous grammar will cause issues. Since any ambiguity is purely accidental for my application, I think I'll take that approach. Thanks for the help!
23:07 jeffreykegler And of course there is the new $slr->ambiguous() method, which will check if your parse is ambiguous -- it's used automatically by the $slg->parse() method.
23:08 jeffreykegler Btw, for those readers not aware, the general problem of whether a *grammar* is ambiguous is undecidable, but ...
23:08 jeffreykegler it is trivial to check is a parse *parse* (that is, a grammar plus an *input*) is ambiguous.
23:09 jeffreykegler *-> "is a parse" -> "if a parse"
23:11 flaviu I was considering just generating taking some tokens and creating random programs, that could give me a pretty good probability of non-ambiguity. However, I'm not an expert in this field, I'll see how it pans out once I actually get to it.
23:12 jeffreykegler In that case, the $slr->ambiguous() method may prove very handy. :-)
23:35 ronsavage joined #marpa
23:44 jeffreykegler Some good news, by the way, with my documentation project.  Often when I do this, making careful to document all the corner cases, I'll find a misfeature or two in the corner cases, ...
23:44 jeffreykegler so that a certain number of bug fixes have often been part of any major documentation overhaul ...
23:45 jeffreykegler but this overhaul is (I hope) nearly done and, while there were lots of corner cases, there were no misfeatures --
23:45 jeffreykegler everything works as expected and intended.
23:58 flaviu I have a "Ambiguous symch" in my grammer, but I can't track it down. Is there some desugaring possibly involved here? My BNF does not contain `Expression ::= Expression`, although it is one of the symches

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary