[pro] Fwd: The Best Examples of "Code is Data"
---------- Forwarded message ---------- From: Raymond Wiker <rwiker@gmail.com> Date: Fri, Sep 24, 2010 at 2:51 PM Subject: Re: [pro] The Best Examples of "Code is Data" To: Kazimir Majorinc <kazimir@chem.pmf.hr> I do not think that this is a case where eval is needed, and it is not a case where eval is likely to be either the best or the simplest solution. Instead of using list-construction operations to construct a "function" to be eval'd, you can use the function-construction operator (lambda, that is). In addition to being more conventional (simply by not using eval), it also gives you a mechanism for passing parameters into your functions without resorting to specials. Two mechanisms, in fact - you can use ordinary parameters and closed-over variables. On Thu, Sep 23, 2010 at 9:53 PM, Kazimir Majorinc <kazimir@chem.pmf.hr> wrote:
OK, but both of you paid more attention to the additional niceties or advantages, unspecified in the problem, than to confirm or reject the claim that eval is the best solution for problem under specified criteria "simpler is better."
It looks to me as implicit claim "Yes, eval is the best solution of that problem, but if the problem is developed further, other approaches (like few mentioned) will (soon?) prevail."
Is it right?
On 24.9.2010 14:51, Raymond Wiker wrote:
Instead of using list-construction operations to construct a "function" to be eval'd, you can use the function-construction operator (lambda, that is). In addition to being more conventional (simply by not using eval), it also gives you a mechanism for passing parameters into your functions without resorting to specials. Two mechanisms, in fact - you can use ordinary parameters and closed-over variables.
But it is not simpler than 'eval'. One would use, for example, #'(lambda ()T) instead of 'T. Rewriting this part The program generates propositional formulas S1, S2, ... using some experimental algorithm. S1, ..., Sn are needed for generation of Sn+1, as typical in deductive systems. using functions instead of formulas is harder; the functions can be funcalled, and used as building blocks for larger functions. Same like formulas. So far so good. However, some essential operations on formulas (substitution, unification, rules or inference ...) require analysis of the formula. Similar analysis of the function could be done only by transforming it back into formula with (caddr (function-lambda-expression Si)), and it is not simpler, even if it work, what is not guaranteed according to Hyperspec. Kazimir Majorinc:
The program generates propositional formulas S1, S2, ... using some experimental algorithm. S1, ..., Sn are needed for generation of Sn+1, as typical in deductive systems. The formulas contain logical constants and already defined operators. The hypothesis is: all generated propositional expressions are true.
The problem: write the function that tests that hypothesis for any generated formula. Optimization is not needed. Simpler is better.
I'd use eval instead of defining any new function, as the simplest and the most natural solution. What would others do? If you'd use eval as well, do you think it is important or rare, maybe even 'artificial' example.
participants (2)
-
Kazimir Majorinc -
Raymond Wiker