On Fri, Aug 28, 2009 at 12:48 PM, thyrsus <[email protected]> wrote: > > I'd like to create a scanner for the ruby language, and to proceed > through test driven development. > > As I understand it, test driven development means identifying a > before, an after, developing a test to determine whether the before > was successfully turned into the after, then writing the code to turn > the before into the after. >
Many of Leo's unit tests follow this pattern. There are even scripts that automate this pattern. See unitTest.leo, the tree Scripts-->@ignore-->Scripts that make unit tests > > In the case of a ruby scanner, the before would be a string containing > ruby code, the after would be a Leo tree with the nodes partitioning > the ruby code into modules, classes, methods. > Right. > > I'm concerned about two issues. The easiest, perhaps, first. The > scanner should take a string and return a portion of a Leo tree, and > my test should compare that Leo tree fragment to a pre-built Leo tree > fragment which is the expected result. Is there already a routine > that can do (deep) comparisons of trees, where equivalence is (a) > headers are identical (b) bodies are identical (c) children are > identical? > Yes. Code-->Test classes-->@thin leoTest.py--> class testUtils-->compareOutlines > > The harder problem may be ruby syntax. scanHelper() expects to be > able to find > whitespace > comments > strings > class definitions > function/method definitions > ids (names) > code blocks > "noise" > > I'm worried about strings. Like /bin/sh and perl, Ruby supports > "<<here" documents, that is, strings which are introduced by "<<word", > and whose value is all the following lines of source up to the > occurrence of "word" on a line by itself. There are variations on > quoting and indentation, but those don't introduce difficult hurdles. > The real problem is that Ruby can also use "<<" as a method name, as > in the familiar left shift: > > irb(main):002:0> 1<<8 > => 256 > > Thus to disambiguate the beginning of a string and the invocation of a > method, the parser needs to expect one or the other. I don't see how > to do this in cooperation with the current scanner class design. Does > anyone have an insight? > Not a clue. You will probably want to override one or base-class parser methods. > > Hey, at least it's not perl, the parsing of which was recently show to > require solution of the halting problem: > http://www.perlmonks.org/?node_id=663393 > Unbelievable. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
