On Fri, 2011-10-14 at 20:19 +0200, Raphaël Pinson wrote: > Just a note. If the file is really like lisp and can take any depth of > recursion, then you need a recursive lens, probably very close to json.aug, > so you might want to study how json.aug works.
For a little more background: regular, i.e. nonrecursive, lenses can only deal with regular expressions, which means it is impossible to process matching pairs of parentheses with arbitrarily deep nesting. Recursive lenses can process context-free languages, and therefore are able to handle parens. Unfortunately, it is not possible to detect ambiguity for them by just looking at lenses; ambiguity isn't detected until you actually try and process an ambiguous word with a recursive lens. To get some level of confidence that the recursive json lens (Json.lns) isn't horribly broken, json.aug builds a regular lens 'value1' which can only handle one level of braces, and 'value2' which can handle two levels of braces. As it was until a few minutes ago, the json lens actually was ambiguous, as was shown by the value2 lens - I just fixed that ambiguity in git. The problem was that whitespace was handled haphazardly: some lenses ate the whitespace after the actual text they were processing, others at the beginning (or both), which causes problems when you concatenate lenses and have an overall lens that's structured like '(l1 . ws) . (ws . l2)' - it's now not clear whether whitespace should be processed by the first occurence of ws, or by the second, or some combination of the two. To fix this problem, I went through and made sure that lenses only gobble up whitespace at the end. David _______________________________________________ augeas-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/augeas-devel
