Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-06-29

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

All times shown according to UTC.

Time Nick Message
00:06 sivoais_ joined #marpa
00:09 sivoais joined #marpa
00:21 hobbified joined #marpa
05:43 ronsavage joined #marpa
06:42 aredridel joined #marpa
08:04 ronsavage Aria: Solved! Errr, by re-typing the whoel XML file into INI format -(((((.
08:05 ronsavage whoel => whole.
14:49 jdurand joined #marpa
14:51 jdurand FYI I have been experimenting a nice feature of Scanless resume()int at any position, and it works beautifully. The semantic is the following:
14:51 jdurand suppose you have a language in which you can define blocks (let's say functions) in pieces. A second appearance of the same block would just be a "re-open" of it.
14:52 jdurand For example; in C, this would be : int function() {...} int anotherFunction {...} int function() {... /* Reopening of function block! */}
14:53 jdurand All C compilers will say "function() already has a body" or something like that
14:53 jdurand If I want the semantic to be: "add to function body the new function body", at lexing phase to make sure definitions of the old block would be become invalid when entering the new block, this is failry easy!
14:54 jdurand I just resume() at the position of the old; and loop until an event happens at the end of this old block, and then resume() again at the beginning of the new block -;
14:55 jdurand Use case of the real world: IDL language which allows a module, whose grammar is: 'module' <identifier> { ... }
14:55 jdurand ./.. to be REOPENED in the same scope -;
15:08 jdurand "to make sure definitions of the old block would not become invalid ./.."
16:12 jeffreykegler joined #marpa
16:25 jeffreykegler A few comments on prioritized rules: as for example in the Scanless::DSL synopsis: https://metacpan.org/pod/distribution/Marpa-R2/pod/Scanless/DSL.pod
16:26 jeffreykegler Someone wanting to compare Marpa to other parsers might find it instructive to try to implement prioritized rules in the other parser -- they won't find it possible.
16:27 jeffreykegler It relies on *indirect* syntax-driven programming.  That is,
16:28 jeffreykegler The SLIF DSL is parsed into BNF, and the BNF is used to drive the parse.
16:28 jeffreykegler This is only possible if you know that automatically-generated BNF can be parsed.
16:29 jeffreykegler Any parser which relies on hand twiddling each grammar to make it work, cannot do this.
16:31 jeffreykegler Also, any parser which cannot parse all context-free grammars, and a predictable but large subset of them in linear time, will not be able to implement prioritized rules.
16:34 jeffreykegler A parser which parses a restricted set of grammars which is also hard to define, will be, in practice, impossible to use for handling prioritized rules.
16:36 jeffreykegler Among those three (hand twiddling required, severely restricted class of grammars, ill-defined class of grammars) every alternative to Marpa (except CYK, chart-parsing, or other Earley parsers) is included.
16:37 jeffreykegler I believe that the SLIF might be the first practical use of indirect syntax-driven programming.
16:43 jeffreykegler I'll bet that SLIF's prioritized parsing rules are far from the only new technique made possible by indirect syntax-driven parsing.
16:44 Aria ronsavage: That was the right answer!
16:45 Aria Oh nice, jdurand. I like that resuming in the parser.
16:59 jeffreykegler Re: resuming
16:59 jeffreykegler jdurand: nice
17:00 jeffreykegler My immediate motive for allowing the user to jump around in the input was Perl 5's here documents, where the parse, in effect, does not follow lexical order.
17:02 jeffreykegler But I try to not add features narrowly targeted to a specific hack, but instead to generalize them, so that they allow for uses that I have not foreseen.
17:03 jeffreykegler I learned to do this from UNIX, which pioneered a "tool box" approach, where you invent things that are likely to be useful beyond any presently foreseen "use cases"
17:04 jeffreykegler There's a real cost, in that the docs have to talk about two different kinds on location: parse location vs. input location,
17:05 jeffreykegler which complicates a set of documents which many already find daunting.
17:06 jeffreykegler And it complicates error reporting, etc., etc.
17:06 jeffreykegler But I chose to err on the side of being "expert friendly", which is of course another UNIX tradition.
17:08 jdurand jeffreykegler: you did the things right, I was pleased to see how this worked flawlessly - for my marpaXml sutff, I have decided to generate the code via dom.idl - but this requires an IDL parser, which of course is almost abandonned on CPAN
17:08 jdurand This mean that I will probbly be one the first to propose an ANSI-C DOM3 compliant library - esidl is another parser that generates nice C++ code, though
17:09 jeffreykegler First on CPAN or first ever?
17:10 jdurand CPAN has an IDL parser that understand old IDL syntax, not working with current W3C stuff, and generates only CORBA-C stuff - so the answer is between
17:12 jdurand while everybody knows that it is possible to do object--oriented sutff in pure ANSI-C - that's why I would like to do - at least I'll can generate the headers - C++ can come later - and I am quite sure that generating Moose classes from an IDL could be of interest - I am thinking in particular to Dancer/Mojolicious frameworks
17:12 jdurand "that what I would like to do"
17:13 jdurand Anyway, my goal is to write only what is needed to marpaXml - so I'll to the AST, and a template for ANSI-C, or C++ if it is too hard - the last thing I will avoid if possible -;
17:15 jdurand right now marpaXml parsing is finished , or almost - I am now thinking to semantics, i.e. well-formed documents (that usually is done at lexing phase), and of course validation phase (that could be done at value() phase of Marpa - although not necessary since XML grammar should be not-ambiguous if the lexing is well-driven)
17:20 jdurand C.f. http://search.cpan.org/~perrad/CORBA-C-2.62/ - lase release is 2007 - and trust me it does not work with latest IDL versions
17:20 jdurand "last release is 2007"
17:20 jdurand and it is so elegant to do it with Marpa, I tried to resist but could not...
17:36 jdurand Jeffrey, I want to know - is your marpa_avl.c reusable as is, as a drop-in replacement of avl.c
17:38 jeffreykegler jdurand: that was not a design criterion, so it's not safe to assume that it is drop-in replaceable.
17:38 jeffreykegler I know in hacking it, I would have felt free to break compatibility.
17:40 jdurand ok - no pb
18:13 jeffreykegler jdurand: by the way, if you're thinking of doing an avl clone, I'd love for someone to take over the Marpa variant of avl.c
18:13 jeffreykegler Since it's in the heart of Libmarpa, if that happened I'd want a thorough unit test suite, but that's a good idea anyway.
18:14 jeffreykegler In particular, if I go ahead with the idea of adding guile or Lua to libmarpa, I'd want to add AVL's, which have huge advantages over Lua's indexed hashes and LISP's linked lists.
18:21 jdurand Hmm... I want AVL as well, because I'll need to provide a "searchByKey" facility - not decided yet
18:24 Aria Heh, IDL in its varieties vs WebIDL. Oy.
18:28 jdurand Aria - in fact I look to WebIDL as well - they say it is better but I doubt
18:28 Aria Heh, yeah. I've never seen anyone actually make use of an IDL lately.
18:28 Aria Not since the CORBA days.
18:28 Aria More of a 'That's nice. I'll implement it directly.' attitude.
18:28 jdurand currently DOM level 3 is in CORBA IDL
18:29 jdurand I'll WebIDL if next version DOM is in WebIDL
18:29 jeffreykegler With AVL, I have hacked the memory management, which is why Marpa has two versions of it.  AVL's spend a *lot* of time malloc'ing small blocks of memory.
18:30 jeffreykegler For most of Marpa's memory needs, the data goes into structures where the block is not deleted or resized until the structure as a whole is destroyed, which allows me to use a variant of GNU's obstacks.
18:31 jdurand jeffreykegler - yes, that's what I was thinking to - for the grammar itself as a end-user I adopted the lazy attitude of mallocing * 2, again *2 etc. This is ok because I know I will not need a lot of memory, but the insides of Marpa /and/ the management of value, this is a different story
18:32 jeffreykegler For a more general AVL, I think it'd be nice to restrict the AVL data payload to a pointer (plus maybe flags), and put deleted AVL data blocks on a trash list.  Since they'd all be of one size they'd be reused.
18:33 jdurand hmmm... yes - not sure I'll have time for that in the immediate days, to be frank
18:33 jeffreykegler Right now, since all this is buried inside the overhead of a Perl layer, it's crazy over-optimization, but I've always planned for the data when Libmapra is standalone inside C applications.
18:33 Aria I'm wondering how the new V8 memory management tweaks are going to play into this for me. They shrunk their garbage collection 'young' generation area to mostly match these semantics. Optimized for many small allocations.
18:33 jeffreykegler That's OK -- it's not a short term need.
18:34 jdurand ok
18:34 jdurand Aria - Ah did not know they have a new garbage collection algorithm
18:34 jdurand will it crash as in the goold old Java days -; !
18:35 jeffreykegler Aria: GC is much less efficient than what I'm talking about.  GC is much more general, but it's less efficient.
18:35 Aria Yeah, I'd expect. I just don't know how much less efficient.
18:35 Aria I'm always surprised at how little it's less efficient with V8.
18:36 Aria jdurand: My experience is that the v8 garbage collector is very mature. Unlikely to crash, and ... pretty smart.
18:37 jdurand Aria, this was a joke, I trust quite a lot V8 development - they manage to make something quick with something badly designed - this is quite remarquable
18:37 Aria (It's a two-generation mark-and-sweep collector. Small young generation, with tweaks for same-sized objects, and a larger 'mature' generation)
18:37 Aria Oh. Hehe.
18:37 Aria Yeah, they've done a bang-up job.
18:38 jdurand I was thinking to Dart at the moment of writing - have you tried
18:39 Aria I've not. But I've little interest in it as a language.
18:40 Aria I happen to _like_ javascript for many of the reasons it's hated, so ... Dart brings little to the table I want.
18:40 Aria I'm also mostly anti-OO.
18:41 jeffreykegler It does seem that OO-experimentation has been a vast incinerator of talent.  There have been benefits, but nothing compared to the effort expended.
18:41 Aria Absolutely.
18:42 Aria I don't mind OO where it erupts organically like CLOS-style, Metaobject systems. It's nice to have those around as canonical shapes to refactor such a thing into.
18:42 Aria But I don't think it's usually the right shape.
18:42 jeffreykegler Trying to say nice things about OO, it has raised awareness about the role of global data -- how that can basically be reduced to read-only constants.
18:42 Aria Objects are either too small or too large a unit for re-use.
18:43 Aria Heh. You're the first to ever phrase it that way, jeffreykegler, and I love that telling.
18:43 Aria "reduce global data to read only constants"
18:43 jeffreykegler I have to think that's been said before.
18:44 * jdurand AFK
18:44 jeffreykegler By the way, there are still justifications for non-read-only global data, but they are rare.
18:46 jeffreykegler But in the Perl world, if you look at the list of OO-focused experiments you have Topaz, Parrot, Perl 6.
18:46 jeffreykegler We'll call Moose a success, which it certainly has been in relative terms.
18:47 jeffreykegler Perl 6 will be influential, regardless of what may happen, but I think at this point nobody will deny that progress is disappointing.
18:49 jeffreykegler With Topaz and Parrot, you cannot fault the people involved for lack of talent or lack of dedication.
18:50 jeffreykegler Now actually, the promising paradigm for language reuse ...
18:50 jeffreykegler is language-driven programming.
18:51 jeffreykegler It's fully general, will shrink your code, allows infinite customization and careful control of forward and backward compatibility.
18:52 jeffreykegler But of course the limitation has been that you've got to come up with a parser for that fancy new language.
19:49 Aria Agreed. I think this is ultimately what VPRI leans toward, everywhere.
19:49 Aria With everything they do.
22:40 ronsavage Here's a list of Perl 5 class builders I assembled in November 2012: http://savage.net.au/Module-reviews/html/gci.2012.class.builder.modules.html
22:50 ronsavage I just posted that to indicate the attempts people have come up with to implement OO in Perl, given they must all have assumed having something was better than not having OO.
23:03 jeffreykegler ronsavage: It clearly proves something, though I'm not sure exactly what. :-)
23:06 jeffreykegler People *do* feel the need for better languages, and having given up on better parsers, they had to look for improvements elsewhere.
23:07 jeffreykegler And not *every* major advance in computer languages was accompanied by an advance in parsing, but that's tended to be the case.
23:08 jeffreykegler Perl 5 is not an exception -- Perl 5 is what happened when Larry Wall decided he could be a lot bolder in using yacc than the authors of awk had been.
23:10 Aria Hehe.
23:18 ronsavage One thing it proves is that programmers are all-too-happy to Reinvent the Wheel :-(((.

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