[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mathieu Lirzin
Subject: bug#24155: SRFI-10: Example from the manual fails to execute.
Date: Wed, 10 Aug 2016 20:51:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Andy Wingo <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]