newlispfanclub.alh.net

Posted: **Thu Feb 17, 2011 4:43 am**

Currently, user defined eval is limited on explicit occurences:

(setf original-eval eval)
(constant 'eval (lambda(x)(inc eval-counter)
                     (print eval-counter ": " x "=>")
                     (println (original-eval x))))
(eval '((lambda(x)(+ x 2)) 3)); works OK

; main program

(setf f (lambda(x)(+ x 2)))
(f 4)                         ; used original-eval, not eval

Although this example only show need for such eval on top level, it is simplified example; redefined eval should replace all implicit calls of eval. Why not using explicit eval everywhere where it is needed? Because code would explode to something like

Code: Select all

((eval 'setf) (eval 'f) (eval '(lambda(x)((eval '+) (eval 'x) (eval '2))))
((eval 'f) (eval '4)).

Not impossible, but troublesome.

Posted: **Thu Feb 17, 2011 1:10 pm**

I understand your desire, but internally at some point newLISP has to drop down into dealing with C-language style of functions and data structures. That C function evaluateExpression(CELL * params) is called about 200 times throughout the newLISP executable also calls itself and many times inline coded shorter alternatives are used for efficiency. There is just no way it could be replaced with a user defined eval internally.

But you could write e McCarthy style newLISP evaluator yourself and then put as much customization into it, as you need. You would also emulate a REPL, which is pretty easy using 'read-line', 'read-expr' and your customized evaluator function. You also would use 'quote' instead of the newLISP pre-compiled "'".

Code: Select all

(define (repl)
  (while true
	(print ">> ")
	(catch (eval (read-expr (read-line))) 'result)
	(println "--> " result)
  )
)

(repl)

and you would replace 'eval' with your McCarthy style eval. The 'read-expr' function returns an un-evaluated s-expression translation of the string returned by 'read-line'. On errors 'result' will contain the error message.

newlispfanclub.alh.net

Proposal: extending user defined eval on implicit evaluation

Proposal: extending user defined eval on implicit evaluation

Re: Proposal: extending user defined eval on implicit evalua