[pro] The Best Examples of "Code is Data"

[Pascal Costanza]

On 23 Sep 2010, at 21:53, Kazimir Majorinc 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."

This sounds like a very inappropriate reply to me. You've got responses from two of the most experienced Lispers around, not just experienced in Common Lisp, but in a couple of the most important Lisp dialects. 

"Simpler is better" is not a criterion, but a highly subjective, untestable and vague idea at best. The fact is that the problems with eval are well known and well described, both in literature and in practice. It's not necessary to discuss them in this forum, which is about professional uses of Common Lisp. I don't consider this a professional topic, because aside from toy examples, using eval most certainly doesn't simplify things, but makes things more complicated in the long run.

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

There is a lot of hand-waving in these paragraphs. Do you have an actual problem that you want to solve, or are you making up these requirements along the way?


Pascal


>>>> Look at this:
>>>> 
>>>> 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.
>>>> 
> 
> 
> Scott McKay
> 
>>> 
>>> This is a place you could use 'eval', but... - It depends on what
>>> the propositions contain. If it's a tiny subset of Lisp (like
>>> 'and', 'or', 'not'), a custom evaluator might be nicer. - A custom
>>> evaluator might be faster, too, especially if you're doing this in
>>> the context of some sort of SAT-solver where you've got lots of
>>> propositions, and you might want caching, etc.
>> 
>>> In the many years I've been using Lisp, I've used eval so few
>>> times, and one of the times was in a debugger where I wanted to
>>> evaluate Lisp forms. :-)
>>> 
> 
> Daniel Weinreb:
> 
>> 
>> I'll add that if you can make the tiny subset have no side effects,
>> there are lots of good properties of that.
>> 
>> And if you can make it declarative, that has big advantages, although
>> that might provide not enough power, depending on what you're
>> planning to use this for.
>> 
> 
> 
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium