enhancement requests

enhancement requests

[Andy Wingo]

Hi Wolfgang,

> (I have "my own" scheme to play with, written in LISP, recently enhanced
>  by adding "call-with-prompt". Still trying to figure out all of its
>  implications ...)

Hey, me too... it's nice to have company in that regard :)

You mentioned a number of wishlist items as well, that I wanted to reply
to in a separate mail.  I have copied guile-devel, as people are more
likely to see it there and respond with better ideas than mine.

> (1) Please provide a means by which the debugger prompt (recursive REPL)
>       can be turned off/on. Both a 'hook' (like COMMON-LISP:DEBUGGER-HOOK
>     plus COMMON-LISP:ABORT) or a REPL command would be OK with me.
>     I mis-type too often!
>       [Anyway, I could not find such a means in 2.0.0].

I have added a REPL option, "on-error", which you may set to `backtrace'
or `report' instead of `debug'.

    scheme@(guile-user)> ,option on-error backtrace
    scheme@(guile-user)> (resolve-interface '(qux))
    In module/ice-9/boot-9.scm:
       2389:9  1 (resolve-interface (qux) #:select #f #:hide #<variable 1981650 value: ()> #:prefix #f #:renamer #<procedure…> …)
    In unknown file:
               0 (scm-error misc-error #f "~A ~S" ("no code for module" (qux)) #f)
    ERROR: no code for module (qux)

The width defaults to the terminal width, hence the verbosity above...

> (2) Please provide some obvious "undefine" command, since UNINTERN is gone.
>       I'd need it only interactively, so a REPL command would be fine.
>       Primary use, of course, would be to remove syntax definitions -
>       alternating between syntax-based and procedure-based code
>     ought not require a re-start of GUILE.

I'm not sure what you mean here.  Can you give an example of a REPL
session in which you would like to have an undefine command?

> (3) documentation: Please do document that ~/.guile is (often) invoked
>     automatically (old omission), and what options (including
>     _undocumented_ "-q") inhibit this.

Will do.

> (4) compiler: Now that compiling into hidden ~.cache/... directories
>     has been declared the default behaviour, please cater to those
>     (like me) who'd always look for their compiled files in the
>     source directory, by providing a command line switch ...
>     (E.g. "psyntax" provides a useful "include" macro, the use
>     of which breaks the "need only recompile when source changed"
>     assumption. Don't like to "make clean" in that hidden place).

Ideally you would almost never need to do this, as we would have some
proper dependency tracking that would always know when you need a
recompile.  But alack, we don't actually do any dependency tracking.

Do you mind setting up a Makefile?  That way you compile to .go files in
your source tree.  We still need to add a command-line option to add a
path to the %load-compiled-path though; currently there is only the
GUILE_LOAD_COMPILED_PATH environment variable.  To load other files, you
would then use include-from-path or load-from-path.

Regards,

Andy
-- 
http://wingolog.org/

Re: enhancement requests

[Wolfgang J Moeller]

Hi Andy,

On Thu, 17 Mar 2011, Andy Wingo wrote:
>[...]
> > (1) Please provide a means by which the debugger prompt (recursive REPL)
> >       can be turned off/on. Both a 'hook' (like COMMON-LISP:DEBUGGER-HOOK
> >     plus COMMON-LISP:ABORT) or a REPL command would be OK with me.
> >     I mis-type too often!
> >       [Anyway, I could not find such a means in 2.0.0].
>
> I have added a REPL option, "on-error", which you may set to `backtrace'
> or `report' instead of `debug'.
>
>     scheme@(guile-user)> ,option on-error backtrace
>[...]

Now if I could set that without typing ... didn't realize before
that there's no obvious way to include REPL commands from a file.

> > (2) Please provide some obvious "undefine" command, since UNINTERN is gone.
> >       I'd need it only interactively, so a REPL command would be fine.
> >       Primary use, of course, would be to remove syntax definitions -
> >       alternating between syntax-based and procedure-based code
> >     ought not require a re-start of GUILE.
>
> I'm not sure what you mean here.  Can you give an example of a REPL
> session in which you would like to have an undefine command?
>[...]

Sorry. I remembered wrong - what is gone is the formerly deprecated UNDEFINE macro.
Meanwhile found that functions like

  (define (unintern sym)	; UNINTERN: delete (local) shadowing symbol
    (module-remove! (current-module) sym)
    (if #f #f))

  (define (undefine sym)	; UNDEFINE: provide an #<undefined> shadowing symbol
    (module-ensure-local-variable! (current-module) sym)
    (variable-unset! (module-variable (current-module) sym))
    (if #f #f))

are what I wanted, in order to
 (a) undo MACRO definitions - you can't re-DEFINE a name after DEFINE-SYNTAX;
 (b) recover built-in functions once you have re-defined them;
 (c) test code that uses UNDEFINED? .

>[...]
> > (4) compiler: Now that compiling into hidden ~.cache/... directories
> >     has been declared the default behaviour, please cater to those
> >     (like me) who'd always look for their compiled files in the
> >     source directory, by providing a command line switch ...
> >     (E.g. "psyntax" provides a useful "include" macro, the use
> >     of which breaks the "need only recompile when source changed"
> >     assumption. Don't like to "make clean" in that hidden place).
>
> Ideally you would almost never need to do this, as we would have some
> proper dependency tracking that would always know when you need a
> recompile.  But alack, we don't actually do any dependency tracking.
>
> Do you mind setting up a Makefile?  That way you compile to .go files in
> your source tree.  We still need to add a command-line option to add a
> path to the %load-compiled-path though; currently there is only the
> GUILE_LOAD_COMPILED_PATH environment variable.  To load other files, you
> would then use include-from-path or load-from-path.

I'm mostly concerned with interactive use of (un-adorned) "guile" command.
I have files that use macros defined elsewhere - once I have LOADed
(and automatically compiled) such files, and change the macros, there's
[apparently] no way to make guile re-load the source, short of deleting
the (.cache-d) compiler output. Having to locate that in a far-away place
is no fun ... so maybe, what I really want is "load-ignoring-cached-go" ?

Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: enhancement requests

[Andy Wingo]

Hi,

On Mon 21 Mar 2011 01:24, Wolfgang J Moeller <wjm@heenes.com> writes:

>>     scheme@(guile-user)> ,option on-error backtrace
>>[...]
>
> Now if I could set that without typing ... didn't realize before
> that there's no obvious way to include REPL commands from a file.

In your .guile:

    (use-modules (system repl common))
    (repl-default-option-set! 'on-error 'backtrace)

Cheers,

Andy
-- 
http://wingolog.org/

Re: enhancement requests

[Andy Wingo]

Hi Wolfgang,

On Mon 21 Mar 2011 01:24, Wolfgang J Moeller <wjm@heenes.com> writes:

>   (define (unintern sym)	; UNINTERN: delete (local) shadowing symbol
>     (module-remove! (current-module) sym)
>     (if #f #f))
>
>   (define (undefine sym)	; UNDEFINE: provide an #<undefined> shadowing symbol
>     (module-ensure-local-variable! (current-module) sym)
>     (variable-unset! (module-variable (current-module) sym))
>     (if #f #f))
>
> are what I wanted, in order to
>  (a) undo MACRO definitions - you can't re-DEFINE a name after DEFINE-SYNTAX;

You can certainly re-define a name after define-syntax.  This used to
not be the case, at least with psyntax, but this changed at some point
in upstream psyntax, and I merged in similar functionality in our copy
sometime last year or the year before.

>  (b) recover built-in functions once you have re-defined them;

Hummmm.  However, functions which have been defined in your module in
terms of your local functions might keep a hold on your local functions.
Whether this happens depends on whether the code in question has been
run or not, and whether the code was introduced from a macro or not.
For the mechanism, see "Compiled Procedures are VM Programs" in the
manual.

Basically I'm hesitant to include such functionality in Guile itself,
because it gets harder for me (as maintainer, bug-hunter, etc) to reason
about users' code after you ,undefine.

>  (c) test code that uses UNDEFINED? .

How is this different from (not (defined? 'sym)) ?  And what kind of
code would you use this for?

Cheers,

Andy
-- 
http://wingolog.org/

Re: enhancement requests

[Andy Wingo]

On Thu 17 Mar 2011 12:50, Andy Wingo <wingo@pobox.com> writes:

>> (3) documentation: Please do document that ~/.guile is (often) invoked
>>     automatically (old omission), and what options (including
>>     _undocumented_ "-q") inhibit this.
>
> Will do.

Done.

Andy
-- 
http://wingolog.org/

Re: enhancement requests

[Wolfgang J Moeller]

On Tue, 29 Mar 2011, Andy Wingo wrote:

>[...]
> >  (a) undo MACRO definitions - you can't re-DEFINE a name after DEFINE-SYNTAX;
>
> You can certainly re-define a name after define-syntax.  This used to
> not be the case, at least with psyntax, but this changed at some point
> in upstream psyntax, and I merged in similar functionality in our copy
> sometime last year or the year before.

Sorry. I could have sworn ... but I must have confused it with GUILE 1.8.

> >  (b) recover built-in functions once you have re-defined them;
>
> Hummmm.  However, functions which have been defined in your module in
> terms of your local functions might keep a hold on your local functions.
> Whether this happens depends on whether the code in question has been
> run or not, and whether the code was introduced from a macro or not.
> For the mechanism, see "Compiled Procedures are VM Programs" in the
> manual.
>
> Basically I'm hesitant to include such functionality in Guile itself,
> because it gets harder for me (as maintainer, bug-hunter, etc) to reason
> about users' code after you ,undefine.

OK, that's a rather exotic point. I came across it since my "prelude"
traditionally re-defines the "while" macro [to work as it should have
in GUILE 1.6, i.e. allowing for an optional result argument to "break"].

> >  (c) test code that uses UNDEFINED? .
>
> How is this different from (not (defined? 'sym)) ?  And what kind of
> code would you use this for?

Sorry, in fact I did mean the function "defined?".
Used in my prelude, because GUILE - my first Scheme - used to provide it.

===

On Thu 17 Mar 2011 12:50, Andy Wingo <wingo@pobox.com> writes:

>>> (3) documentation: Please do document that ~/.guile is (often) invoked
>>>     automatically (old omission), and what options (including
>>>     _undocumented_ "-q") inhibit this.
>>
>> Will do.
>
> Done.

Thanks a lot!

Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: enhancement requests

[Andy Wingo]

Hi Wolfgang,

On Mon 21 Mar 2011 01:24, Wolfgang J Moeller <wjm@heenes.com> writes:

>> > (4) compiler: Now that compiling into hidden ~.cache/... directories
>> >     has been declared the default behaviour, please cater to those
>> >     (like me) who'd always look for their compiled files in the
>> >     source directory, by providing a command line switch ...
>> >     (E.g. "psyntax" provides a useful "include" macro, the use
>> >     of which breaks the "need only recompile when source changed"
>> >     assumption. Don't like to "make clean" in that hidden place).
>>
> I'm mostly concerned with interactive use of (un-adorned) "guile" command.
> I have files that use macros defined elsewhere - once I have LOADed
> (and automatically compiled) such files, and change the macros, there's
> [apparently] no way to make guile re-load the source, short of deleting
> the (.cache-d) compiler output. Having to locate that in a far-away place
> is no fun ... so maybe, what I really want is "load-ignoring-cached-go" ?

I have added a --fresh-auto-compile argument to Guile, or equivalently
GUILE_AUTO_COMPILE=fresh.  Hopefully that should hack around Guile's
missing dependency tracker for the time being.

Cheers,

Andy
-- 
http://wingolog.org/

Re: enhancement requests

[Wolfgang J Moeller]

On Fri, 15 Apr 2011, Andy Wingo wrote:

> Hi Wolfgang,
>
> On Mon 21 Mar 2011 01:24, Wolfgang J Moeller <wjm@heenes.com> writes:
>
> >> > (4) compiler: Now that compiling into hidden ~.cache/... directories
> >> >     has been declared the default behaviour, please cater to those
> >> >     (like me) who'd always look for their compiled files in the
> >> >     source directory, by providing a command line switch ...
> >> >     (E.g. "psyntax" provides a useful "include" macro, the use
> >> >     of which breaks the "need only recompile when source changed"
> >> >     assumption. Don't like to "make clean" in that hidden place).
> >>
> > I'm mostly concerned with interactive use of (un-adorned) "guile" command.
> > I have files that use macros defined elsewhere - once I have LOADed
> > (and automatically compiled) such files, and change the macros, there's
> > [apparently] no way to make guile re-load the source, short of deleting
> > the (.cache-d) compiler output. Having to locate that in a far-away place
> > is no fun ... so maybe, what I really want is "load-ignoring-cached-go" ?
>
> I have added a --fresh-auto-compile argument to Guile, or equivalently
> GUILE_AUTO_COMPILE=fresh.  Hopefully that should hack around Guile's
> missing dependency tracker for the time being.

Sorry, that's not what I intended.

There are already 2 "operational modes": Default, and --no-auto-compile.
I'm indeed asking for a "load-ignoring-cached-go" from _within_ both of these modes,
not for a third mode that makes for even more variation in what ought to be tested.

Something like INCLUDE (which however, doesn't work quite the same as LOAD -
cf. my "prelude" example) would be fine ... there's no point in [file-]compiling
test programs for [in particular] macros.

Of course, currently I do have an emacs dired window open into the .cache directory
in order to check for (and delete) compiler output.
Didn't you claim that I should not need to do so?

Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: enhancement requests

[Andy Wingo]

Hi Wolfgang,

On Mon 18 Apr 2011 11:53, Wolfgang J Moeller <wjm@heenes.com> writes:

> On Fri, 15 Apr 2011, Andy Wingo wrote:
>
>> On Mon 21 Mar 2011 01:24, Wolfgang J Moeller <wjm@heenes.com> writes:
>>
>> >> > (4) compiler: Now that compiling into hidden ~.cache/... directories
>> >> >     has been declared the default behaviour, please cater to those
>> >> >     (like me) who'd always look for their compiled files in the
>> >> >     source directory, by providing a command line switch ...
>> >> >     (E.g. "psyntax" provides a useful "include" macro, the use
>> >> >     of which breaks the "need only recompile when source changed"
>> >> >     assumption. Don't like to "make clean" in that hidden place).
>> >>
>> > I'm mostly concerned with interactive use of (un-adorned) "guile" command.
>> > I have files that use macros defined elsewhere - once I have LOADed
>> > (and automatically compiled) such files, and change the macros, there's
>> > [apparently] no way to make guile re-load the source, short of deleting
>> > the (.cache-d) compiler output. Having to locate that in a far-away place
>> > is no fun ... so maybe, what I really want is "load-ignoring-cached-go" ?
>>
>> I have added a --fresh-auto-compile argument to Guile, or equivalently
>> GUILE_AUTO_COMPILE=fresh.  Hopefully that should hack around Guile's
>> missing dependency tracker for the time being.
>
> Sorry, that's not what I intended.

I realize that it's not what you originally asked for.  However I don't
currently know how to support .go alongside .scm files, if you don't
explicitly compile them yourself and set GUILE_LOAD_COMPILED_PATH.

My point was that there shouldn't be a difference between auto-compiling
and not; auto-compilation should work.  It doesn't in this case, because
of lack of dependency tracking, so I added this flag to forceably treat
the cache as stale.

You could also try setting XDG_CACHE_HOME to something in your build
tree...

Andy
-- 
http://wingolog.org/

Re: enhancement requests ("load-ignoring-cached-go")

[Wolfgang J Moeller]

Hi Andy,

>[...]
> >> > I'm mostly concerned with interactive use of (un-adorned) "guile" command.
> >> > I have files that use macros defined elsewhere - once I have LOADed
> >> > (and automatically compiled) such files, and change the macros, there's
> >> > [apparently] no way to make guile re-load the source, short of deleting
> >> > the (.cache-d) compiler output. Having to locate that in a far-away place
> >> > is no fun ... so maybe, what I really want is "load-ignoring-cached-go" ?
> >>
> >> I have added a --fresh-auto-compile argument to Guile, or equivalently
> >> GUILE_AUTO_COMPILE=fresh.  Hopefully that should hack around Guile's
> >> missing dependency tracker for the time being.
> >
> > Sorry, that's not what I intended.
>
> I realize that it's not what you originally asked for.  However I don't
> currently know how to support .go alongside .scm files, if you don't
> explicitly compile them yourself and set GUILE_LOAD_COMPILED_PATH.
>[...]

In my browser, searching the Guile Reference Manual
( http://www.gnu.org/software/guile/manual) Indices
for GUILE_LOAD_COMPILED_PATH ... no hits ... looking up LOAD ...
incidentally noting that there's PRIMITIVE-LOAD which _allegedly_
does the same as LOAD, except for the optional argument ...
wondering ... setting %load-hook as described on that page ...
finding that it _often_ remains silent (V2.0.0!) ... and now
wondering if the %load-hook message is telling me precisely
that a "load from source w/o autocompilation" is taking place -
in which case, PRIMITIVE-LOAD was apparently
the "load-ignoring-cached-go" I'm asking for!

(Meanwhile found GUILE_LOAD_COMPILED_PATH on the manpage ;-().

Now, I don't care for %load-hook, but you tell me
what PRIMITIVE-LOAD is _intended_ to do!


Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: enhancement requests ("load-ignoring-cached-go")

[Andy Wingo]

Hi Wolfgang :)

On Thu 21 Apr 2011 12:21, Wolfgang J Moeller <wjm@heenes.com> writes:

> In my browser, searching the Guile Reference Manual
> ( http://www.gnu.org/software/guile/manual) Indices
> for GUILE_LOAD_COMPILED_PATH ... no hits ...

An open bug, yes; hrm.  Adding Mark Harig to the Cc, who had a plan for
fixing this.

> looking up LOAD ...
> incidentally noting that there's PRIMITIVE-LOAD which _allegedly_
> does the same as LOAD, except for the optional argument ...
> wondering ... setting %load-hook as described on that page ...
> finding that it _often_ remains silent (V2.0.0!) ... and now
> wondering if the %load-hook message is telling me precisely
> that a "load from source w/o autocompilation" is taking place -
> in which case, PRIMITIVE-LOAD was apparently
> the "load-ignoring-cached-go" I'm asking for!
>
> Now, I don't care for %load-hook, but you tell me
> what PRIMITIVE-LOAD is _intended_ to do!

Heh.  Well, primitive-load is a load that doesn't autocompile, doesn't
load .go files, and doesn't run within a module excursion.  The
%load-hook business is another bug, reported recently:
http://thread.gmane.org/gmane.lisp.guile.devel/12259, but not yet
resolved.  I'll see about fixing this shortly.

BTW, I see you are still on 2.0.0.  How about beta testing one of these:

  http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest

2.0.1 will come out shortly, but it would be good if you could report
bugs on the snapshots.

Cheers,

Andy
-- 
http://wingolog.org/

Re: enhancement requests ("load-ignoring-cached-go")

[Wolfgang J Moeller]

On Thu, 21 Apr 2011, Andy Wingo wrote:

>[...]
> > In my browser, searching the Guile Reference Manual
> > ( http://www.gnu.org/software/guile/manual) Indices
> > for GUILE_LOAD_COMPILED_PATH ... no hits ...
>
> An open bug, yes; hrm.  Adding Mark Harig to the Cc, who had a plan for
> fixing this.

No, that wasn't intended as a bug report, but if you say so ... ;-)

> > looking up LOAD ...
> > incidentally noting that there's PRIMITIVE-LOAD
>[...]
> Heh.  Well, primitive-load is a load that doesn't autocompile, doesn't
> load .go files, and doesn't run within a module excursion.  The
> %load-hook business is another bug, reported recently:
> http://thread.gmane.org/gmane.lisp.guile.devel/12259, but not yet
> resolved.  I'll see about fixing this shortly.

Ok, you fix the docu of LOAD (which doesn't say that .go files
are preferred over source), and I'll gladly use PRIMITIVE-LOAD
for my environment-dependent test programs. No more questions! ;-)

> BTW, I see you are still on 2.0.0.  How about beta testing one of these:
>
>   http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest
>
> 2.0.1 will come out shortly, but it would be good if you could report
> bugs on the snapshots.

Maybe ... actually I'm more concerned now with better integrating
'psyntax' [7.3] into "my" Scheme. 'define-syntax defmacro' ala GUILE
seems to be working, but got to be exercised ... btw., in R6RS and
this latest "pre-R6RS" 'psyntax', the first argument to datum->syntax
must be an identifier, not an arbitrary syntax form. Permitting
the latter in the old 'psyntax' might have been a mistake ...
I've still got to read up some more, and think of a test.

Cheers & happy Easter,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: enhancement requests ("load-ignoring-cached-go")

[Mark Harig]

>
> On Thu 21 Apr 2011 12:21, Wolfgang J Moeller <wjm@heenes.com> writes:
>
> > In my browser, searching the Guile Reference Manual
> > ( http://www.gnu.org/software/guile/manual) Indices
> > for GUILE_LOAD_COMPILED_PATH ... no hits ...
>
> An open bug, yes; hrm.  Adding Mark Harig to the Cc, who had a plan 
for
> fixing this.
>

In brief, the plan was to reorganize the sections in the chapter
"Programming in Scheme" to add a new section, "Invoking Guile", with
two new subsections, "Command-line Options" and "Environment
Variables."  The subsection "Command-line Options" is a copy of the
former subsection "Invoking Guile", which resided in the section
"Guile Scripting."  The subsection "Environment Variables" is a new
node that contains descriptions of the (as yet undocumented)
environment variables that can be set before Guile is started.

Here is an outline of the change in the chapter structure:

1. Current structure:

  Chapter: Programming in Scheme
    * Guile Scheme
    * Guile Scripting
      * The Top of a Script File
      * Invoking Guile
      * The Meta Switch
      * Command Line Handling
      * Scripting Examples
    * Using Guile Interactively
    * Using Guile in Emacs

2. New structure:

  Chapter: Programming in Scheme
    * Guile Scheme
    * Invoking Guile
      * Command-line Options
      * Environment Variables
    * Guile Scripting
      * The Top of a Script File
      * The Meta Switch
      * Command Line Handling
      * Scripting Examples
    * Using Guile Interactively
    * Using Guile in Emacs

I will send the proposed patches in a separate message.

Re: enhancement requests ("load-ignoring-cached-go")

[Andy Wingo]

Hi!

On Thu 21 Apr 2011 17:56, Wolfgang J Moeller <wjm@heenes.com> writes:

> btw., in R6RS and this latest "pre-R6RS" 'psyntax', the first argument
> to datum->syntax must be an identifier, not an arbitrary syntax
> form. Permitting the latter in the old 'psyntax' might have been a
> mistake ...  I've still got to read up some more, and think of a test.

Hum, this might indeed be a bug.  Thing is, the answer is not entirely
clear.  Check this commit log:

    commit 9846796b6abb6ecbce0d596db32daa7ac5921a2a
    Author: Andy Wingo <wingo@pobox.com>
    Date:   Sun Jun 6 13:00:59 2010 +0200

        fix module-hygiene corner case by relying more on syntax objects
        
        * module/ice-9/psyntax.scm (chi-macro): Instead of assuming that output
          of a macro should be scoped relative to the module that was current
          when the macro was defined, allow the module information associated
          with the syntax object itself to pass through unmolested. Fixes bug
          29860.
          (datum->syntax): Propagate the module of the identifier through to the
          new syntax object, so that datum->syntax preserves module hygiene in
          addition to lexical hygiene.
          (include, include-from-path): Refactor to plumb though the hygiene
          information from the filename instead of the `include', allowing
          hygiene from the original caller of include-from-path to propagate
          through.
        
        * module/ice-9/psyntax-pp.scm: Regenerated.
        
        * test-suite/tests/syncase.test ("macro-generating macro"): Add test for
          bug 29860.

There were two bugs fixed there, but I'm only interested in the latter,
affecting `include-from-path'.  The issue was that:

  (define-syntax include-from-path
    (syntax-rules ()
      ((_ relname) (include (search-path relname)))))

  ...

  (include-from-path "foo")

wasn't working, because the included forms were getting scoped relative
to the `include' in the macro, not the `include-from-path' in the
original invocation.  That's because `include' used the #'include
identifier for `datum->syntax' on the forms.  This change fixed it to
use the mark on "foo" instead -- a hack perhaps?  Perhaps `include'
should take a second argument, an identifier, to use in syntax->datum
calls.

Anyway, the hack did end up working though, and it would be prohibited
by a change to datum->syntax.  ISTR that Racket folk had a similar issue
about a year ago too.  Perhaps it makes more sense in their context, in
which (foo) implicitly donotes an instance of the `%app' abstraction.
Dunno!

I guess I'm going to let this sleeping dog lie around for a while.
When & if the time comes to fix it there will be some other code that
needs patching too.

Thanks for the note,

Andy
-- 
http://wingolog.org/