Re: [Scheme-reports] Proposal to add fexprs

[Bear <bear@x>]

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. 

				Bear



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