On Sun, 2013-11-17 at 19:31 -0500, Vassil Nikolov wrote:
>
> John Cowan <cowan@mercury.ccil.org> 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.

				Bear

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports