[r6rs-discuss] [Formal] Trivial Enhancement of macros in v5.91: capture-syntax

From: Abdulaziz Ghuloum <aghuloum>
Date: Fri Dec 1 02:16:24 2006

On Nov 30, 2006, at 7:29 AM, AndrevanTonder wrote:
>
> Would the fundamental types not be more naturally non-generative, or
> am I missing some aspect of generativity?

I would think yes. If fundamental types are different when a library
is compiled, when it's visited, or when it is invoked by the expander
or the final script, then that's a serious problem regardless of
whether procedural macros are used or not. A symbol that is read by
the reader when the library is compiled has better be the same symbol
when the library is later used. I don't see the report requiring that
fundamental types be implemented using records. If an implementor
choses to implement them using records, then the implementors would
have to ensure consistency across different compiler runs.

On Nov 29, 2006, at 10:12 PM, William D Clinger wrote:

> The answer to those questions is that the implementors of
> the Scheme system on which the L0-script is running should
> be required to do whatever is necessary to make the macro
> expander and library system, written in M, know how to
> marshall L1-values into L0-values. If the implementors
> can't figure out how to do that, then they shouldn't try
> to implement the R6RS.

Yes. And if the implementors cannot ensure that symbols are the same
across the board, then they shouldn't try to implement (R0RS) Scheme.
Read/write invariance is the job of the implementor. If bignums are
implemented as user-level records, I don't see how they would be read
and written correctly.

> By bignum, I meant an exact integer that is not a fixnum.
> With that definition, it becomes absolutely clear that a
> bignum is a datum in the sense defined by the draft R6RS.

Let me see if I follow this correctly.
1. A bignum is a datum (stated above and has always been so).
2. A record is not a datum (section 3.3.1 of R5.91RS).
3. A bignum may be implemented as a record (as done in the reference
implementation).
I don't see how these three points can be valid at the same time.

I think the issue of how the (opaque) fundamental types are implemented
is an implementation detail that has nothing to do with libraries,
phases, procedural macros, records, generativity, etc. If an
implementor decides on using the reference implementation internally,
then that decision better be a detail that is not visible to the end
user (this is an opinion).

Aziz,,,
Received on Thu Nov 30 2006 - 08:57:27 UTC