GNU bug report logs - #24155
SRFI-10: Example from the manual fails to execute.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24155 in the body.
You can then email your comments to 24155 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: bug-guile <at> gnu.org
Subject: SRFI-10: Example from the manual fails to execute.
Date: Fri, 05 Aug 2016 03:19:09 +0200

Hello,

The following example from the Guile manual in subsection 7.5.9, fails
for me both on Guile master 2.1.3.94-1a1c3 and Guile 2.0.11 from Debian
Testing.

--8<---------------cut here---------------start------------->8---
     (use-modules (srfi srfi-10))

     (define-reader-ctor 'hash
       (lambda elems
         (let ((table (make-hash-table)))
           (for-each (lambda (elem)
                       (apply hash-set! table elem))
                     elems)
           table)))

     (define (animal->family animal)
       (hash-ref '#,(hash ("tiger" "cat")
                          ("lion"  "cat")
                          ("wolf"  "dog"))
                 animal))
--8<---------------cut here---------------end--------------->8---

The error is:

--8<---------------cut here---------------start------------->8---
While compiling expression:
ERROR: build-constant-store: unrecognized object #<hash-table 1c52c80 3/31>
--8<---------------cut here---------------end--------------->8---

Thanks,

-- 
Mathieu Lirzin

Message #10 received at 24155-done <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 24155-done <at> debbugs.gnu.org
Subject: Re: bug#24155: SRFI-10: Example from the manual fails to execute.
Date: Sun, 07 Aug 2016 11:55:46 +0200

Hi Mathieu,

Thanks for the report.

On Fri 05 Aug 2016 03:19, Mathieu Lirzin <mthl <at> gnu.org> writes:

> The following example from the Guile manual in subsection 7.5.9, fails
> for me both on Guile master 2.1.3.94-1a1c3 and Guile 2.0.11 from Debian
> Testing.
>
>      (use-modules (srfi srfi-10))
>
>      (define-reader-ctor 'hash
>        (lambda elems
>          (let ((table (make-hash-table)))
>            (for-each (lambda (elem)
>                        (apply hash-set! table elem))
>                      elems)
>            table)))
>
>      (define (animal->family animal)
>        (hash-ref '#,(hash ("tiger" "cat")
>                           ("lion"  "cat")
>                           ("wolf"  "dog"))
>                  animal))
>
> The error is:
>
> While compiling expression:
> ERROR: build-constant-store: unrecognized object #<hash-table 1c52c80 3/31>

I replaced the text with this:

      We do not recommend #,() reader extensions, however, and for three
   reasons.

      First of all, this SRFI is not modular: the tag is matched by name,
   not as an identifier within a scope.  Defining a reader extension in one
   part of a program can thus affect unrelated parts of a program because
   the tag is not scoped.

      Secondly, reader extensions can be hard to manage from a time
   perspective: when does the reader extension take effect?  *Note Eval
   When::, for more discussion.

      Finally, reader extensions can easily produce objects that can’t be
   reified to an object file by the compiler.  For example if you define a
   reader extension that makes a hash table (*note Hash Tables::), then it
   will work fine when run with the interpreter, and you think you have a
   neat hack.  But then if you try to compile your program, after wrangling
   with the ‘eval-when’ concerns mentioned above, the compiler will carp
   that it doesn’t know how to serialize a hash table to disk.

      In the specific case of hash tables, it would be possible for Guile
   to know how to pack hash tables into compiled files, but this doesn’t
   work in general.  What if the object you produce is an instance of a
   record type?  Guile would then have to serialize the record type to disk
   too, and then what happens if the program independently loads the code
   that defines the record type?  Does it define the same type or a
   different type?  Guile’s record types are nominal, not structural, so
   the answer is not clear at all.

      For all of these reasons we recommend macros over reader extensions.
   Macros fulfill many of the same needs while preserving modular
   composition, and their interaction with ‘eval-when’ is well-known.  If
   you need brevity, instead use ‘read-hash-extend’ and make your reader
   extension expand to a macro invocation.  In that way we preserve scoping
   as much as possible.  *Note Reader Extensions::.

Thanks for the report,

Andy

Message #13 received at 24155-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 24155-done <at> debbugs.gnu.org
Subject: Re: bug#24155: SRFI-10: Example from the manual fails to execute.
Date: Wed, 10 Aug 2016 20:51:06 +0200

Andy Wingo <wingo <at> pobox.com> writes:

> I replaced the text with this:
>
>       We do not recommend #,() reader extensions, however, and for three
>    reasons.
>
>       First of all, this SRFI is not modular: the tag is matched by name,
>    not as an identifier within a scope.  Defining a reader extension in one
>    part of a program can thus affect unrelated parts of a program because
>    the tag is not scoped.
>
>       Secondly, reader extensions can be hard to manage from a time
>    perspective: when does the reader extension take effect?  *Note Eval
>    When::, for more discussion.
>
>       Finally, reader extensions can easily produce objects that can’t be
>    reified to an object file by the compiler.  For example if you define a
>    reader extension that makes a hash table (*note Hash Tables::), then it
>    will work fine when run with the interpreter, and you think you have a
>    neat hack.  But then if you try to compile your program, after wrangling
>    with the ‘eval-when’ concerns mentioned above, the compiler will carp
>    that it doesn’t know how to serialize a hash table to disk.
>
>       In the specific case of hash tables, it would be possible for Guile
>    to know how to pack hash tables into compiled files, but this doesn’t
>    work in general.  What if the object you produce is an instance of a
>    record type?  Guile would then have to serialize the record type to disk
>    too, and then what happens if the program independently loads the code
>    that defines the record type?  Does it define the same type or a
>    different type?  Guile’s record types are nominal, not structural, so
>    the answer is not clear at all.
>
>       For all of these reasons we recommend macros over reader extensions.
>    Macros fulfill many of the same needs while preserving modular
>    composition, and their interaction with ‘eval-when’ is well-known.  If
>    you need brevity, instead use ‘read-hash-extend’ and make your reader
>    extension expand to a macro invocation.  In that way we preserve scoping
>    as much as possible.  *Note Reader Extensions::.

I find this documentation helpful.

Thank you.

-- 
Mathieu Lirzin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.