Re: [Scheme-reports] Proposal to add fexprs musicdenotation@gmail.com (17 Nov 2013 12:31 UTC)
Re: [Scheme-reports] Proposal to add fexprs Perry E. Metzger (17 Nov 2013 19:51 UTC)
Re: [Scheme-reports] Proposal to add fexprs John Cowan (17 Nov 2013 23:35 UTC)
Re: [Scheme-reports] Proposal to add fexprs Vassil Nikolov (18 Nov 2013 02:37 UTC)

Re: [Scheme-reports] Proposal to add fexprs Perry E. Metzger 17 Nov 2013 17:06 UTC

On Sun, 17 Nov 2013 17:19:00 +0700 musicdenotation@gmail.com wrote:
> Why is static analysis a problem? The compiler can tell whether
> something is a function or a macro by looking at it's source code.
> If it's from a library, look at the source code of a library or the
> library should flag whether a procedure is a function or a macro.

Everything is okay provided that such macros are only used in the way
you in particular anticipate, in a language that is implemented in
the way you presume it will be implemented. Bitter experience over
decades say this is not nearly so simple as you presume.

> Anyway, you can specify fexprs as an optional part of the language,
> so that anyone interested can implement it.

You have not actually proposed any means to deal with the distinction
between the binding environment at the location where the fexpr is
invoked and the binding environment inside the fexpr. A simple
example of why this is a very hard problem was given already.

(I will point out that the situation is harder than that still if you
presume compilation rather than interpretation and people rebind a
symbol from a normal function to a fexpr.)

You seem to believe that all of this is trivial. I suggest that you
implement your proposals in at least one compiled scheme system
before proceeding any further.

Perry
--
Perry E. Metzger		perry@piermont.com

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