[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unhandled constant?
Re: unhandled constant?
Sat, 01 Feb 2020 16:21:43 +0100
tried it in a couple of syntax-case-enabled schemes (defmacro is implemented
using syntax-case in guile) and it doesn't work anywhere. The procedure ends up
The #<procedure> object ,inner points to doesn't exist at runtime because it is
not defined anywhere in any meaningful way to the compiler. One work-around
would be to output the literal lambda in place of ,inner but by then you should
just output a (let ...) With the lambda in it and let the inliner take care of
On Sat, 1 Feb 2020, at 15:23, David Kastrup wrote:
> Linus Björnstam <address@hidden> writes:
> > On Sat, 1 Feb 2020, at 12:09, David Kastrup wrote:
> >> Can you expand about the "expansion time and macro time separation"?
> >> If we have
> >> (define decl '())
> >> (define (make-var n v) (list "var" n v))
> >> (defmacro define-session (name value)
> >> (define (inner n v)
> >> (set! decl
> >> (cons
> >> (make-var n v)
> >> decl))
> >> )
> >> `(,inner ',name ,value))
> >> (define-session foo 1)
> >> (display decl)
> >> (newline)
> >> as stated, the local function "inner" is defined at macro time, but the
> >> form
> >> `(,inner ',name ,value)
> >> does not export the _name_ inner but rather the defined function. That
> >> part naively appears to me like it should work; an "expansion time and
> >> macro time" issue appears rather to be that inner calls make-var (and
> >> accesses decl) which is only being defined at expansion time.
> >> The error message, however, rather appears to complain about inner being
> >> undefined rather than the definition of inner referring to undefined
> >> entities.
> > I am not sure what is really the problem. Either the inner function is
> > not present at runtime due to separation of compile time and runtime,
> > or it is a result of how defmacro re-introduces the result of the
> > macro into the syntactic context of the macro usage (where inner is
> > not visible). Either way, having the inner definition in the macro
> > output will solve the problem of it not being visible.
> This fails when byte-compiling, so it would appear that the equivalent
> (defmacro ...
> (define local-fun ...
> `(,local-fun ...)))
> is not able to represent the local (and thus ultimately anonymous)
> function here. Whether this is a general shortcoming or is conditioned
> on local-fun calling functions not available at byte-compile time (in
> which case those would need to get wrapped in eval-and-expand) I haven't
> checked yet.
> David Kastrup
Re: unhandled constant?, Taylan Kammer, 2020/02/01
Re: unhandled constant?, Jan Nieuwenhuizen, 2020/02/02