Unwanted evaluation

[Manuel Simoni]

This happens to me quite frequently in Kernel programming: I use a list not as a syntax form, but as a data structure containing some objects, and when I pass it to eval as part of a constructed syntax tree, it gets evaluated as a combination.

There doesn't seem to be any way to prevent this in general, except wrapping the list in an encapsulated data type that prevents evaluation.

Any thoughts on this?

[Yi Dai]

Isn't this what is supposed to happen?  I mean whatever s-expression you passed in to (Lisp's, Scheme's or Kernel's) `eval', itself the whole is treated as code or combination in Kernel's jargon.  If you want a list remains as is, you can quote it, although not recommended by Kernel.

--
DAI Yi
(代 毅)

Y I = (λ f . (λ x . x x) (λ x . f (x x))) (λ x . x) = 易

[Andres Navarro]

>
> Isn't this what is supposed to happen? I mean whatever s-expression you
> passed in to (Lisp's, Scheme's or Kernel's) `eval', itself the whole is
> treated as code or combination in Kernel's jargon. If you want a list
> remains as is, you can quote it, although not recommended by Kernel.
>

You can use any operative actually, you are not limited to quote.

If I remember correctly, John has a couple of "real world" examples in his
dissertation.

However, in my experience the problem usually arises because one is trying to
do too much with eval at the same time. This is typical while experimenting
with semantics, but I don't think it happens so much when programming
"normally".

Regards

[Yi Dai]

I agree.  Many arguments against Kernel I saw are made from this "normal" programming point of view, which in my opinion kinda misses the point.  Here the same wisdom of when to use macros instead of functions applies.  Though I am considering whether it is better to omit all the operatives intended for meta-programming (say $vau, wrap, eval, etc.) in the initial and standard environment but instead provide them as a library module that can be imported just in need.  Thus, in the initial and standard environment, we provide only applicatives (say cons, car, cdr, $lambda, etc.), that is, we have approximately a pure Scheme only.  I see this actually interesting since in Scheme, a macro library module seems almost impossible.  Otherwise, I guess those Racket guys could have already made it.

Regards,