From: Mathieu Lirzin <mthl@gnu.org>
To: Andy Wingo <wingo@pobox.com>
Cc: 24155-done@debbugs.gnu.org
Subject: bug#24155: SRFI-10: Example from the manual fails to execute.
Date: Wed, 10 Aug 2016 20:51:06 +0200 [thread overview]
Message-ID: <87oa50bgpx.fsf@gnu.org> (raw)
In-Reply-To: <87d1lksy1p.fsf@pobox.com> (Andy Wingo's message of "Sun, 07 Aug 2016 11:55:46 +0200")
Andy Wingo <wingo@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
prev parent reply other threads:[~2016-08-10 18:51 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
2016-08-10 18:51 ` Mathieu Lirzin [this message]
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=87oa50bgpx.fsf@gnu.org \
--to=mthl@gnu.org \
--cc=24155-done@debbugs.gnu.org \
--cc=wingo@pobox.com \
/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).