* Guile 2.0 interpretation vs compilation
@ 2014-10-05 11:03 Marko Rauhamaa
2014-10-06 4:22 ` Mark H Weaver
0 siblings, 1 reply; 6+ messages in thread
From: Marko Rauhamaa @ 2014-10-05 11:03 UTC (permalink / raw)
To: guile-user
Consider this program:
===begin test.scm=======================================================
(define (hello) #f)
(format #t "~S\n" (procedure-name hello))
(define (xyz)
(define (hello) #f)
(format #t "~S\n" (procedure-name hello)))
(xyz)
===end test.scm=========================================================
If I run:
$ guile --no-auto-compile test.scm
hello
#f
$ guile --no-auto-compile test.scm
hello
#f
$ guile test.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
[...]
hello
hello
$ guile test.scm
hello
hello
$ guile --no-auto-compile test.scm
hello
hello
# $ guile -v
guile (GNU Guile) 2.0.11
[...]
Is this a bug or expected behavior?
Marko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Guile 2.0 interpretation vs compilation
2014-10-05 11:03 Guile 2.0 interpretation vs compilation Marko Rauhamaa
@ 2014-10-06 4:22 ` Mark H Weaver
2014-10-06 6:33 ` Marko Rauhamaa
0 siblings, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2014-10-06 4:22 UTC (permalink / raw)
To: Marko Rauhamaa; +Cc: guile-user
Marko Rauhamaa <marko@pacujo.net> writes:
> Consider this program:
>
> ===begin test.scm=======================================================
> (define (hello) #f)
> (format #t "~S\n" (procedure-name hello))
>
> (define (xyz)
> (define (hello) #f)
> (format #t "~S\n" (procedure-name hello)))
>
> (xyz)
> ===end test.scm=========================================================
>
> If I run:
>
> $ guile --no-auto-compile test.scm
> hello
> #f
> $ guile --no-auto-compile test.scm
> hello
> #f
This is expected but not ideal. Our primitive evaluator does not
preserve non-toplevel variable names, and therefore the associated
procedure names are lost. Maybe we can fix this in Guile 2.2.
> $ guile test.scm
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;; or pass the --no-auto-compile argument to disable.
> [...]
> hello
> hello
> $ guile test.scm
> hello
> hello
> $ guile --no-auto-compile test.scm
> hello
> hello
The reason this last one works is because the .go file was created in
the preceding compiled runs, and --no-auto-compile does not inhibit the
use of pre-existing .go files (unless the .scm file is newer, of
course).
Regards,
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Guile 2.0 interpretation vs compilation
2014-10-06 4:22 ` Mark H Weaver
@ 2014-10-06 6:33 ` Marko Rauhamaa
2014-10-06 6:52 ` Mark H Weaver
2014-10-06 7:58 ` Mark H Weaver
0 siblings, 2 replies; 6+ messages in thread
From: Marko Rauhamaa @ 2014-10-06 6:33 UTC (permalink / raw)
To: Mark H Weaver; +Cc: guile-user
Mark H Weaver <mhw@netris.org>:
> This is expected but not ideal. Our primitive evaluator does not
> preserve non-toplevel variable names, and therefore the associated
> procedure names are lost. Maybe we can fix this in Guile 2.2.
I noticed the issue because I have software that depends on the
procedure-name of inner functions. I can live with this guile-2.0 quirk
if it is considered a guile defect. However, if the semantics of
procedure-name of inner functions is unspecified, I'll have to look at
refactoring my code.
Marko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Guile 2.0 interpretation vs compilation
2014-10-06 6:33 ` Marko Rauhamaa
@ 2014-10-06 6:52 ` Mark H Weaver
2014-10-06 7:58 ` Mark H Weaver
1 sibling, 0 replies; 6+ messages in thread
From: Mark H Weaver @ 2014-10-06 6:52 UTC (permalink / raw)
To: Marko Rauhamaa; +Cc: guile-user
Marko Rauhamaa <marko@pacujo.net> writes:
> Mark H Weaver <mhw@netris.org>:
>
>> This is expected but not ideal. Our primitive evaluator does not
>> preserve non-toplevel variable names, and therefore the associated
>> procedure names are lost. Maybe we can fix this in Guile 2.2.
>
> I noticed the issue because I have software that depends on the
> procedure-name of inner functions. I can live with this guile-2.0 quirk
> if it is considered a guile defect.
I consider it a guile defect, yes. Can you please send a bug report to
bug-guile@gnu.org? I'll look into whether it can be fixed in 2.0.x, and
try to come up with a workaround.
Thanks,
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Guile 2.0 interpretation vs compilation
2014-10-06 6:33 ` Marko Rauhamaa
2014-10-06 6:52 ` Mark H Weaver
@ 2014-10-06 7:58 ` Mark H Weaver
2014-10-06 19:05 ` Marko Rauhamaa
1 sibling, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2014-10-06 7:58 UTC (permalink / raw)
To: Marko Rauhamaa; +Cc: guile-user
Marko Rauhamaa <marko@pacujo.net> writes:
> Mark H Weaver <mhw@netris.org>:
>
>> This is expected but not ideal. Our primitive evaluator does not
>> preserve non-toplevel variable names, and therefore the associated
>> procedure names are lost. Maybe we can fix this in Guile 2.2.
>
> I noticed the issue because I have software that depends on the
> procedure-name of inner functions. I can live with this guile-2.0 quirk
> if it is considered a guile defect.
Here's a simple workaround for now, though unfortunately it will mostly
prevent our compiler from doing optimizations on code that uses this
'define' macro:
(define-syntax define
(syntax-rules ()
((define (proc . args) body body* ...)
(define proc
(let ((p (lambda args body body* ...)))
(set-procedure-property! p 'name 'proc)
p)))
((define name expr)
((@ (guile) define) name expr))))
Does this work for you?
Alternatively, you could make sure to always compile your code, in which
case 'procedure-name' should work properly.
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-06 19:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-05 11:03 Guile 2.0 interpretation vs compilation Marko Rauhamaa
2014-10-06 4:22 ` Mark H Weaver
2014-10-06 6:33 ` Marko Rauhamaa
2014-10-06 6:52 ` Mark H Weaver
2014-10-06 7:58 ` Mark H Weaver
2014-10-06 19:05 ` Marko Rauhamaa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).