From: Andy Wingo <wingo@pobox.com>
To: Mathieu Lirzin <mthl@gnu.org>
Cc: 24155-done@debbugs.gnu.org
Subject: bug#24155: SRFI-10: Example from the manual fails to execute.
Date: Sun, 07 Aug 2016 11:55:46 +0200 [thread overview]
Message-ID: <87d1lksy1p.fsf@pobox.com> (raw)
In-Reply-To: <87popodnci.fsf@gnu.org> (Mathieu Lirzin's message of "Fri, 05 Aug 2016 03:19:09 +0200")
Hi Mathieu,
Thanks for the report.
On Fri 05 Aug 2016 03:19, Mathieu Lirzin <mthl@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
next prev parent reply other threads:[~2016-08-07 9:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-05 1:19 bug#24155: SRFI-10: Example from the manual fails to execute Mathieu Lirzin
2016-08-07 9:55 ` Andy Wingo [this message]
2016-08-10 18:51 ` Mathieu Lirzin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d1lksy1p.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=24155-done@debbugs.gnu.org \
--cc=mthl@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).