Ken Tilton wrote: > What if it turns into an SQL lookup during refactoring?
If the macro can produce SQL code, then whatever interprets the table can produce SQL code as well. If you're thinking of the macro taking apart the user's reverse function (rather than just wrapping it) and somehow translating it into SQL, well... a macro *could* do that, but it would be an awfully hairy thing to do, especially if the user is allowed to write arbitrary Lisp code in the body of his function (as it seems he is, in your example). A better way would be to design an abstract API for the user to use in his reverse functions. Then you can just re-implement the functions making up the API so that they do SQL queries instead of whatever they were doing before. No macro processing needed then. > The last example showed the macro inserting code to magically produce a > binding inside the reverse function. Are you sure? It looked to me like it was adding code *around* the reverse function, not inside it. I posted a Python function that achieves the same thing by calling the existing reverse function. > It would be easier to compare and > contrast with the Python equivalent if someone had posted such, but your > troops have fallen back to Fort So What? and pulled up the drawbridge. I'm still trying, but some of the code you posted is rather impenetrable without knowing a lot more about the details of your system. I'm doing my best to show some Python demonstrating the gist of what could be done. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
