>> as for eval, it will always be there (in RnRS)
>
> EVAL has not been in every report. R4RS did not specify EVAL, nor did R3RS,
> RRRS, RRS.
The fact that R5RS does only proves the fact that they should have :)
By the way I have a question (regarding not using eval).
I want to pass the contents of a list to a function that accepts the
so-called "rest" args.
(let ((l '(1 2 3 4 5)))
(let ((operation (append '(+) l)))
(primitive-eval operation)
)
)
How to achieve this effect without using eval?
(I've tried (+ . l) but it didn't work out)
>> besides I don't imagine not messing with lexical
>> environments :) The bad thing is that scopes aren't
>> explicitly definable and the report doesn't say
>> much about their properties. I don't know how
>> about practical performance, but I'd find it best
>> if they were implemented as (implicit) hash tables
>> that could be bound to variables and passed as
>> arguments. I think that they could perform
>> equally good as fixed arrays for memoized
>> procedures.
>
> The view of the scheme community as a whole is that first class lexical
> environments are irreconcilable with the need to compile (optimize) code.
Certainly there's a faction that thinks differently :]
> In many cases, once you have done some variety of compilation, a lot of the
> lexical environments you think you ought to have will have been optimized
> away; conversely, preserving these environments will prevent entire classes
> of compilation.
Unless some limitations are to be imposed on compiled closures
(and some control over optimization is given to the programmer)
I see no problem with that.
> I am of the suspicion that in most cases, the environment would never be
> reified, the compiler could prove this, and optimization could proceed as
> desired. However, I would still agree with Clinton that you should avoid
> messing with environments, first class or otherwise, whenever possible.
> When you must, you should quarantine it: use it in a very limited part of
> your code, where you wrap it in a more mundane abstraction, then use that
> abstraction elsewhere. CALL/CC should be treated the same way usually.
Yeah, I always write additional layers so the code corresponds to the
way I think. (Everybody does, don't they?)
> Broadening the topic a bit, it seems that first class envs and macros (and
> maybe not macros!) are all that would be needed to define a module system in
> scheme, rather than building it into the interpreter. Then the module
> system could be put in a file which any r5rs+envs (or whatever standard you
> like) scheme could LOAD (most likely implicitly at startup) without
> modification to the interpreter itself. It might even be the case that
> DEFMACROs and reified environments would be sufficient to make low-level
> hygienic macros a library too (but I'm no macrologist, for sure). You would
> still have to deal with the compilation issues, but as I said, my gut
> feeling is that these are solvable.
Such a pretty vision you have :)
("and no religion too..." :P)
The thing is that this would really make *everything* simpler.
(or maybe it's just another collective hallucination)
