Jan-Peter Voigt <[email protected]> writes: > On 14.05.2012 12:34, David Kastrup wrote: >> Jan-Peter Voigt<[email protected]> writes: >> >>> Hello Harm and list, >> Could you try _not_ posting in HTML? This mail had both a plain text as >> well as an HTML-specified part, and both rendered awfully here. If you >> send just as plain text, chances are that you see what you are actually >> sending. > ups, sorry! It was the last thunderbird update, or whatever ... >>> \version "2.15.38" >>> >>> % predicate for a number or a list of numbers >>> #(define (number-or-list? v) >>> >>> (or (number? v) >>> >>> (and >>> >>> (list? v) >>> >>> (eval `(and ,@(map (lambda (x)`(number? ,x)) v))(interaction-environment)) >>> >>> ))) >> What is the crazy idea with using eval? Why don't you use >> >> (every number? v) here? > ... because I sometimes don't see the obvious ... ;-) thank you!
No, it is not just that. Using eval is a recipe for trouble because it runs at a time where the actual lexical environment you are evaluating this in is _gone_. It also adds a _spurious_ layer of evaluation, so anything but self-evaluating expressions in the list will fail with the weirdest of consequences. eval is a _very_ special tool with a _lot_ of strange consequences. On par with self-modifying code in assembly language. When you need its special effects, namely creating a new interpretative environment and _interpret_ something in this environment _completely_ detached from the code around it, its use may be called for. But it is not the first time I have seen you propose the use of eval where it makes absolutely no sense at all calling a complete encapsulated Scheme interpreter instead of using the interpreter/compiler already dealing with the surrounding expression. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
