Open mabragor opened 11 years ago
Thank you!
****AAARG. Effing markdown. Gimme plain text or give me death... so the numbers are screwed up, can't be arsed to figure out how to keep them right.
I took a quick look at this. VERY quick. Here are the issues I saw on my pass through the diff to origin/master:
Junk left in:
+(defun foo () nil) +
Missing earmuffs, ditto with INDENT in the example. Definite no-go. (See http://random-state.net/log/3498750808.html for context, unless this is already familiar ground to you.):
+(defparameter contexts nil) +(defmacro register-context (context-sym)
Alexandria has hash-table-alist:
+(defun hash->assoc (hash)
I think I would like to see the different parts here separated out into a distinct pull requests. Now there are too many trees in the forest.
Thinking about how to integrate context sensitivity with packrat parsing in a more principled manner, I have a feeling that allowing users to define arbitary functions which could then function as terminals might be the way to go. See sketch on https://github.com/nikodemus/esrap/tree/custom-terminals-sketch (just pushed it). It seems to me that forcing all context into the same cache cannot really be a win, and correctness becomes also harder to reason about.
OK, I'll try to fix the issues. But now, while integrating all those new syntactic constructs into COMPILE-EXPRESSION, I've noticed, that what's really done is duplicating some of the functionality of the Lisp code-walker.
So I decided to improve on HU.DWIM.WALKER a little bit, for it to be able to substitute unknown symbols with something else on the fly (to imitate ESRAP's behaviour, where all symbols are treated as non-terminals). Now my patch there is accepted, and I started to work on rewriting DEFRULE to use that code-walker for macroexpansion.
Of course, this allows to completely mix up destructuring with grammar, which you don't like.
I removed compiler macro for PARSE, since other way all the rules ended up in ESRAP::RULES hashtable not CL-YACLYAML::YACLYAML-RULES, which I wanted them to be in (because compiler macro works outside of dynamics, and my (LET ((ESRAP::RULES CL-YACLYAML::RULES)) simply had no effect on DEFRULE, which was a real pain to debug.
About separating into several pull requests, I know, how to do that in Darcs (where you can rewrite the commit history), but how to do that with Git?
On 22 June 2013 19:09, Alexandr Popolitov notifications@github.com wrote:
OK, I'll try to fix the issues. But now, while integrating all those new syntactic constructs into COMPILE-EXPRESSION, I've noticed, that what's really done is duplicating some of the functionality of the Lisp code-walker.
A code walker is a limited generalization of evaluator or compiler (or code analyzer), so obviously. :)
So I decided to improve on HU.DWIM.WALKER a little bit, for it to be able to substitute unknown symbols with something else on the fly (to imitate ESRAP's behaviour, where all symbols are treated as non-terminals). Now my patch there is accepted, and I started to work on rewriting DEFRULE to use that code-walker for macroexpansion.
I can right off say that a walker-using defrule won't be merged by me. ...but maintainership is probably moving to Jan or someone else soonish, so they may like it better. :)
I removed compiler macro for PARSE, since other way all the rules ended up in ESRAP::RULES
hashtable not CL-YACLYAML::YACLYAML-RULES, which I wanted them to be in (because compiler macro works outside of dynamics, and my (LET ((ESRAP::RULES CL-YACLYAML::RULES)) simply had no effect on DEFRULE, which was a real pain to debug.
Fine for your local usage, perhaps, but definitely not something to be merged.
About separating into several pull requests, I know, how to do that in Darcs (where you can rewrite the commit history), but how to do that with Git?
Easiest way is probably to make several branches, each with single feature -- and merge them into your all-features branch. Obviously if some things depend on each other, then a they cannot be separated into individual branches - but the thing depended on can still have it's own branch.
(Despite my today's pass over esrap pull requests, I'm on vacation and spending as much time away from the computer as i can -- and once I get back to work my time will be very short. ...which is why I'm hoping to pass on Esrap's maintainership to eg. Jan.)
Also, I fixed a bug, with infinite loop, which occured when greedy-repeating something that could match to an empty string. There are use-cases in tests.lisp and in examples-very-context-sensitive-grammar.lisp
Hopefully, this fix how will allow me to write YaML parser using esrap. But in case I missed something, I'll add fixes on the fly.