merits of Lisp vs Python

[Ken Tilton]

greg wrote:
> Ken Tilton wrote:
> 
>> 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.

You are thinking about the results iteration, where you broke 
encapsulation. I just reminded you of the magical "signed-value" binding 
  in a reply to another post of yours.

btw, when looking back at the rest of the code I was reminded I had done 
something even wilder (well, maybe as wild) in the transforming code 
itself. I say "wilder" in the sense of it being waaaaay cool, having a 
flying-without-a-net feeling, yet making coding of dozens and dozens of 
these transformations simpler, terser, and less buggy.

Someone had me laughing when they said the actual application of a macro 
was nice and simple, but the macro itself was scary. It reminded me of a 
cranky but sweet old guy on a project who was outraged upon learning I 
was using a finite state machine to handle a shaky exchange between two 
processes. He maintained that I was "foisting a crazy scheme on the 
bank" which no one would be able to maintain. He actually forced me to 
defend it in a group code review, the first they ever had, so don't 
think it was a normal process for them, this was war. After my 
demonstration on how the FSM would react to either or both processes 
going south at any point in the exchange, the crank pronounced his 
satisfaction with the approach and said, "OK, that is simple. The 
infinite-state thing is complicated, but the way it works is simple." 
That really made the whole thing worthwhile. :)

> 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.

Great. That's the spirit. But how do we move forward if you just express 
global confusion? See if you can understand the magical binding of the 
parameter "signed-value". The reverse function will be called by the 
engine to reverse a mathematical transformation, in this case simply 
taking the absolute value. The generic engine has no way of knowing out 
of all the targets, results, and operands (targets from a "before" 
expression relocated in their incarnation in the expression operated on) 
recorded by a transformation to pass in that position. When I code that 
reverse function, I just want to work on the signed-value, as identified 
in hard-code fashion by the transformation. ie, All I need do is 
coordiate the TF and its reverser. If the reverser needs something else, 
say the "coefficient" (this would be a add-like-terms TF), I just go to 
the add-like-terms and have it tag the coefficients with the symbol 
'coefficient, then I can code:

     (reverse (coefficient literal-part)...)

Ah. Time to refactor. I will have multiple coefficients, and when 
multiples are expected I want all the input math forms searched for 
those tagged coefficient. Any ideas out there? :) It is so tempting to 
add an s and have the macroexpansion look for a trailing s in the 
symbol-name, but then I am bound to have some singular and in s. Ah, 
grep to the rescue: (reverse (literal-part coefficient+)...)

Sweet. By using + I can even have the macroexpansion insert an assertion 
that there is at least one. Of course there should be at least two or 
this TF would not fire. And so it goes...

:)

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon