[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] file inclusion (section 4.1.7 of draft 9)

On Sun 09 Jun 2013 01:35, John Cowan <cowan@x> writes:

> Alex Shinn scripsit:
>> > (lambda (~a) (+ a 1))
>> >
>> > How could compiler know these 2 symbols are the same?
>> Correct - the macro is hygienic, so the a in the file won't match the
>> renamed a in the lambda.
> Oddly, this isn't always what happens.  Given the call `((m) 32)`,
> Racket, Gambit, Guile, Kawa, SISC, Chez, Mosh, IronScheme, SXM return
> 33, whereas Gauche, Chicken, Chibi, STklos, S7, Owl Lisp say `a` is
> undefined.  See HygienicInclusion for details.

FWIW, most syntax-case-like systems give the included forms the lexical
environment of the "include" expression itself, though it is common also
to provide an alternative that takes an additional argument to
explicitly give the context.

It is as if the included forms were lexically present where the
"include" expression originally was.

>> > BTW, if the above macro is defined in a library, which file would
>> > be included? The file in the same location of the library or macro
>> > caller location?
>> By the time the include is expanded it has no idea in which file it
>> was originally defined (barring some sort of self-introspection on
>> source info), so the include path would naturally be relative to the
>> caller location.

I seem to be doing a lot of well-actuallies these days; apologies for
that.  However :)  Guile's include documentation is here (without regard
for R7RS, fwiw):


The include is relative to the file the "include" form originally
appeared in, which might be a macro.

Both of these (IMO correct, user-friendly) behaviors are possible
because Guile's expander works on syntax objects, not raw s-expressions,
and thus is able to have more information about the lexical context and
origin of an expression.



Scheme-reports mailing list