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/
