unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
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





      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).