Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-01-04

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

All times shown according to UTC.

Time Nick Message
00:02 sirdancealot good evening racers
00:03 ronsavage Good morning from Melbourne.
00:31 jeffreykegler joined #marpa
02:17 ronsavage I've uploaded MarpaX :: Languages :: Perl :: PackUnpack to CPAN!
04:00 jeffreykegler joined #marpa
04:01 jeffreykegler ronsavage: Good work!
04:02 jeffreykegler "Papers we love" is a github community which keeps a repository of Comp. Sci. papers they love.
04:03 jeffreykegler http://paperswelove.org/
04:03 jeffreykegler Apparently nobody loves parsing papers :-(
04:06 hobbs it's a meetup too. I'm subscribed to the NY one, although sad to say I haven't actually *gone* to it just yet :)
04:07 hobbs someone actually did _The Derivative of a One-Hole Type is its Type of One-Hole Contexts_
04:07 hobbs blarg
04:08 hobbs _The Derivative of a Regular Type is its Type of One-Hole Contexts_
04:14 hobbs and someone in Dallas did Lamport's "clocks" paper, which I definitely would have gone to see in person if it was local. Hopefully it was recorded and the video just isn't up yet :)
04:14 ronsavage joined #marpa
04:18 ronsavage jeffreykegler: Thanx
05:13 ronsavage joined #marpa
05:18 jeffreykegler https://www.youtube.com/watch?v=​SQmA8w6TOgU&feature=youtu.be
05:19 jeffreykegler The Barcelona.pm talk on Marpa, by Jose Luis Perez Diez (‎jluis‎) is at 1:31:00 in this
05:19 jeffreykegler The youtube video is the full conference -- 9 hours.
05:20 jeffreykegler Jose's talk is 30 minutes or so.
05:22 ronsavage Is it in Spanish?
05:23 jeffreykegler There's a cliff-hanger at the beginning, where Jose leaves that to a vote by the audience ...
05:23 jeffreykegler which went for English.
05:24 jeffreykegler The conference itself was tri-lingual -- Spanish/Catalan/English
05:26 Aria Oh that's awesome!
05:29 ronsavage No wonder it was 9 hours. Hahaha.
05:39 jeffreykegler In the talk, Jose uses my balanced delimiter program, and I was sorry to notice that my comments were full of typos.
05:40 jeffreykegler Too late for his talk, but I've just fixed a bunch of these: https://gist.github.com/jeffr​eykegler/b6bfeeadfcedeade6519
05:49 koo5 joined #marpa
05:53 jeffreykegler Good night!
05:55 ronsavage joined #marpa
06:00 sirdancealot joined #marpa
07:28 ronsavage joined #marpa
09:01 lwa joined #marpa
09:56 lwa1 joined #marpa
10:36 pczarn joined #marpa
15:01 rns joined #marpa
15:22 rns jeffreykegler: Actually, I find these words — http://irclog.perlgeek.de/​marpa/2015-01-03#i_9882929 (sad but true) — and these words — http://irclog.perlgeek.de/​marpa/2014-12-08#i_9775675 — very inspring.
15:22 rns left #marpa
18:00 pczarn hi
18:01 pczarn after making progress with the SLIF, I have several questions as usual
18:04 pczarn I'm simply using a vector for the stack, however, all values in a vector must have the same type
18:06 pczarn For now I'm storing tagged unions, but this approach doesn't seem efficient.
18:09 pczarn I'm not sure how common is having actions that return various types.
18:17 pczarn Second, for simple rules such as `foo ::= val:bar`, the implicit action propagates the only value. At least it makes sense to me. Ok, I just figured out nothing has to be done on the  stack
18:20 pczarn What's the reasoning behind the use of `::=` and not `:=`, `=` or some other operator?
18:20 pczarn What about inline actions?
18:26 pczarn what's L0 and G1 grammar separation for?
18:30 pczarn Since efficiency is not a great concern
18:34 pczarn perhaps related: Imagine that in a grammar that should be formal, there might be an ambiguity, but L0/G1 are unambiguous separately
18:38 pczarn L0 is versioned and backwards compatible. But L0 can be extended without breaking backwards compatibility, and there exists G1 that is broken as a result, I think
18:40 pczarn So, how to resolve an ambiguity in a formal grammar in favor of certain rules?
18:45 pczarn btw, I had a mistake in the error return value list
21:34 jeffreykegler joined #marpa
21:35 jeffreykegler pczarn: it sound like you are talking about something written in C ("unions", etc.).  Is that the case?
21:37 jeffreykegler In Perl, it's quite common to have actions return a wide variety of types.  But the strategy of restricting the return value is also used.
21:39 jeffreykegler As for "::=", it is traditional in the standards and a lot of the literature on BNF.  It has the advantage that it does indicate that we are *not* talking about either assignment or equivalence, but something very different from both -- something producing something else in a rewriting system.
21:40 jeffreykegler The SLIF has no inline actions, because doing so would have committed me to a particular language, and I could not decide.  My solution to that is Kollos, which makes Lua the semantics language for Marpa.
21:41 jeffreykegler The G1 vs. L0 difference is crucial -- this document is all about that: http://search.cpan.org/~jkegl/Ma​rpa-R2-2.100000/pod/Scanless.pod
21:42 jeffreykegler It introduces the idea, assuming that you are new to parsing.
21:42 jeffreykegler In yacc/lex it's the lexer/parser distinction.
21:43 ronsavage joined #marpa
21:43 jeffreykegler In recursive descent it's the difference between structural (call a subroutine) and lexical (do some hacking within a particular subroutine).
21:45 jeffreykegler pczarn: re http://irclog.perlgeek.de/​marpa/2015-01-04#i_9885974 -- I am not at all sure I understood this question, but taking a stab in the dark ...
21:46 jeffreykegler you might want to look at the "rank" adverb for rules.  Again, I am not at all sure this is anything close to helpful.
21:47 pczarn joined #marpa
21:50 pczarn jeffreykegler: it's written in Rust, but it suffices to say C (and most of C++) is a subset of Rust
21:57 jeffreykegler Why aren't tagged unions efficient?  Are you just using a case statement or picking up some sort of OO system's overhead?
21:59 jeffreykegler Also, yes, in C/Rust you probably need to make all results the same type, which in practice will almost always have to be an object or a tagged union.
22:00 pczarn hm, not really, I can think of significant overhead when one type in a tagged union is unusually large
22:02 jeffreykegler So it's a copying/memory management issue?
22:02 pczarn AST normally consists of objects or tagged unions anyway
22:05 jeffreykegler To avoid repeated copying in tree processing, I've used various tricks, most of which involve using pointers.
22:06 jeffreykegler For example, which assembling things into a string, I'll build a linked list (or some such structure), and at the very top flatten the thing into a string.
22:14 pczarn https://github.com/pczarn/rust-marpa/blob/slif/​marpa-macros/example/ambiguous_grammar_slif.rs -- so far my goal was to run this, and it kinda works
22:18 pczarn jeffreykegler: I could use pointers, but there are some unusual constraints
22:20 pczarn well, these constraints can be largely ignored for a library..
22:22 jeffreykegler Is the efficiency problem with the ambiguous grammar?
22:23 jeffreykegler because in the example you give, the number of parses grows exponentially.
22:24 jeffreykegler By the way, your Marpa Rust implementation is *very* cool looking.
22:24 pczarn actually I won't need ambiguous parses in practice, this one is just an example
22:25 jeffreykegler It makes a good test case -- the Marpa::R2 test suite has a few like it.
22:26 pczarn re: efficiency: without any measurements, let's not worry about this
22:26 jeffreykegler OK.
22:26 jeffreykegler For enumerating all parses of a highly ambiguous grammar, the efficiency problem is essentially insoluable.
22:27 jeffreykegler While Marpa can *parse* the grammar in O(n**3) time, its tables contain, packed, something like O(4**n) grammars ...
22:28 pczarn although marpa_r_alternative accepts token values of type int32 with the exception of 0. If it could store int64, that would be better
22:29 jeffreykegler if you try to enumerate all of them, no matter how fast you process each of them, it rapidly becomes hopeless.
22:30 jeffreykegler Re the token values, the typical use for token value is as the index to the actual value.
22:30 pczarn I'm keeping end positions in a vector to get them back with binary search
22:30 jeffreykegler and 2**31 is a whole bunch of tokens.
22:31 pczarn perhaps binary search wasn't a great choice
22:32 jeffreykegler The trend in Libmarpa will be to move fancy processing up out of it -- on the idea that anything that does not gain by being part of Libmarpa, should not be part of Libmarpa.
22:33 jeffreykegler And, whether it was a great choice or not, binary search counts as "fancy processing" in this context.
22:35 pczarn how large is Libmarpa's cycle detection? I heard it counts as non-essential processing
22:36 jeffreykegler Too large.  In future revisions cycle detection will be moved out of Libmarpa into a grammar rewrite.
22:37 jeffreykegler The speed hit is minor, but the additional code complexity in the parse engine is harder to justify.
22:38 jeffreykegler Yes, I'm thinking of turning Libmarpa into something you'd consider implementing on a chip, the way graphics algorithms are currently.
22:39 pczarn configurable reference counting and custom allocation would be neat
22:40 jeffreykegler Configurable ref counting?  how?
22:41 jeffreykegler And what you want want the allocation for?  Libmarpa already allocates for its own structures.
22:41 pczarn more like an option to switch refcounting off
22:42 jeffreykegler Wouldn't incrementing the reference and never decrementing it accomplish that?
22:43 pczarn I think so, how do I deallocate?
22:44 jeffreykegler Decrement the extra increment. :-)
22:45 jeffreykegler That is, if you want an 2nd refcounting system, just have it hold a reference in the 1st one, for as long as it is active.
22:49 pczarn I have a refcounting system which I could reuse, it just doesn't seem.. low-level, but that's not important
22:50 pczarn ultimately, I'd like to write an equivalent of MarpaX::Languages::C::AST for Rust on top of my implementation
22:51 jeffreykegler Actually that makes a good example of when you'd use the Libmarpa reference increment methods.
22:52 jeffreykegler If you want to use your own refcounting system, you just give it a refcount in Libmarpa's native system, and you get the best of both worlds --
22:52 jeffreykegler Libmarpa will protect its own internal linkages, and will delete nothing until you say it is OK.
22:53 pczarn there are two features worth mentioning
22:55 pczarn inference: the interface is written in a statically typed language, but the result type i32 isn't given directly in the example
22:58 pczarn this seems surprising at first, maybe I'm violating some unwritten convention for Rust macros
22:59 pczarn furthermore, inline actions are closures
23:02 pczarn I should refactor this 700 line mess before I lose sanity
23:03 pczarn and then add explicit action result types, I guess: `-> T { func() }`
23:08 jeffreykegler pczarn: you may want to follow the Kollos effort, particularly the design docs ... hopefully we will have some ideas worth stealing :-)

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