Guile 2.0 interpretation vs compilation

Guile 2.0 interpretation vs compilation

[Marko Rauhamaa]

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

Re: Guile 2.0 interpretation vs compilation

[Mark H Weaver]

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

Re: Guile 2.0 interpretation vs compilation

[Marko Rauhamaa]

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

Re: Guile 2.0 interpretation vs compilation

[Mark H Weaver]

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

Re: Guile 2.0 interpretation vs compilation

[Mark H Weaver]

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

Re: Guile 2.0 interpretation vs compilation

[Marko Rauhamaa]

Mark H Weaver <mhw@netris.org>:

> Alternatively, you could make sure to always compile your code, in which
> case 'procedure-name' should work properly.

Not a problem.


Marko