[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Proposal to add fexprs
On Sun, 2013-11-17 at 19:31 -0500, Vassil Nikolov wrote:
> John Cowan <cowan@x> wrote:
> > ...
> > Someone asked about what `apply` does with fexprs. In classic Lisps,
> > fexprs don't know anything about where their operands come from any
> > more
> > than other procedures do, so the environment at the point of
> > application
> > is used to interpret variables, there being in fact no other. In
> > Kernel,
> > it is a domain error to invoke `apply` on a fexpr.
> But I think the latter is (also) because
> with `apply', the arguments to the
> function being applied have already
> been evaluated; yet another reason why
> fexprs (never mind macros) are not
> really like functions.
As someone who has actually done some work on this question, I'll
point out a few things:
1. In order to have a consistent semantics of Fexprs,
including the ability to "apply", it is necessary to
abandon the idea that arguments are evaluated before
a function is called.
2. Fexprs *ARE* functions. There is no "macro" ness
left once they become first class objects that can be
stored in memory locations, returned from functions,
passed as arguments, etc. At that point you have created
a new semantics of function calls (passing language forms
as arguments rather than the results of evaluating them)
and in order to make it work you have to call all your
functions (even the "normal" ones) the same way.
3. In order to avoid getting confused as to which argument
is to be evaluated in what environment, it is necessary
to pass a pointer to the environment where a language form
was found along with each language form.
4. If you do not provide fexprs the ability to read, manipulate,
and modify the language forms provided with their arguments
prior to evaluation within the fexpr, the expressive capability
is equal to the expressive capability of scheme. If you do
provide this ability, then the resulting language can arbitrarily
restructure itself at runtime tying gordian knots of semantics
that admit of no unifying theory we as yet understand.
5. If you give up the idea that arguments are (or can be)
evaluated before the function is called, The resulting
language is not Scheme in several important respects.
It can be a consistent language, but it is not Scheme,
and short of some real implementation heroics it will
not be nearly as efficient.
6. If you want 'eval' and 'apply' to be general w/r/t all
your functions including Fexprs, you have to pass results
the same way as arguments. IE, unevaluated language forms
with a reference back to the function in which they were
combined. Further, you have to provide calling environments
with the same ability to deconstruct and manipulate these
forms prior to evaluation, if any, that are available to
the called functions.
Don't misunderstand me; I *like* all of these ideas, but then
I'm known to be mad. Not so mad, however, as to propose the
complete restructuring of Scheme that this would entail. This
is the roadmap or structure of a completely new and different
lispy language, which has its own meta virtues, but which has
not very much to do with scheme.
Scheme-reports mailing list