Utilities

[Tarrasch]

I've added a lot of utilities and smaller functions that somehow are part of my ll star algorithm.

[ndantam]

Cool, I'll try to merge some of these.

• Initial file for LL(*) code
• Add pattern-lambda

How about this?

 (defmacro pattern-lambda (pattern &body body)
   (with-gensyms (var)
     `(lambda (,var)
        (if-pattern ,pattern var
                    (progn ,@body)
                    nil))))

• Add atn file
• Add rewrite states function for finite automatas

Can we rewrite DFA-RENUMBER using FA-REWRITE-STATES?

• Add"equal" meta-pattern

Cool

• Add finite-set-custom function

Isn't this really just union-ing INIT and ITEMS?

Could also make finite-set-add take a &REST parameter.

• Add a"comparisions" section in util.lisp

Not sure if these help much. Actually, moving that fixnum comparison to a separate function will cause a slowdown in SBCL. When it was inclined, SBCL could infer the types, but in the separate function it cannot (unless you declaim that function inline).

COMPARE-OP and COMPARE-NEST probably make more sense as functions that take arguments for LESS-THAN and GREATER-THAN rather than as macros. Lisp (<) and (>) only work for numbers.

• Add string managing functions in util.lisp
• Use correct comparison
• Add tests for and patterns

Neil Dantam http://www.cc.gatech.edu/~ndantam3

[Tarrasch]

About the comparisons. I will assume you'll actually need the performance here, so I'm not going to question that. However, I think the separate functions are nice and in my LL() code I'm using all of them. Would it be possible to keep the functions and the keep the old definition of gsymbol-compare? About the macros being macros. I did this based on your advice because you'll then not evaluate the second argument if the first argument is non-zero. No? This made a lot of sense to me and will actually play part in the efficiency of the LL() algorithm. About > and <, I intended for the arguments to be numbers. Isn't that a valid assumption? Btw, about compare-op, I think it's incorrect as of now, one should write ,a only once using with-gensyms, no?

Can we rewrite DFA-RENUMBER using FA-REWRITE-STATES?

I did think about it but not for too long. I'm sure it's possible and probably a good idea.

Isn't this really just union-ing INIT and ITEMS? Could also make finite-set-add take a &REST parameter.

Maybe not strictly speaking a unioning because ITEMS is a list, not a set. But I'm unsure if that will matter. Yes, making finite-set-add taking a &REST parameter is probably good.

Thanks for the fast review. :+1: