Am 27.05.2017 um 05:23 schrieb Shiro Kawai:

I'm trying to implement srfi-150 on Gauche and getting into a compatibility issue with srfi-99, regarding using accessor names to designate fields in the constructor specification.

Srfi-99 is designed in the way that syntactic API can expands into procedural API.   You can construct all the necessary procedures from procedural API, and the syntactic API can just bind those values to the designated variables.

Unfortunately, srfi-99 procedural layer do not include information on accessors in rtd.  So it is not possible to simply expand srfi-150 syntactic layer to srfi-99 procedural API + simple definitions.

Of course, srfi-150 doesn't need to be fully compatible to srfi-99; we need to extend the procedural layer anyway to allow non-symbol field names.  Such extension is trivial if implementation has some sort of first-class identifiers.  However, using accessor names to designate fields in constructor spec would record that rtd also need to keep the way to map accessor names to fields, *in addition to* what we have in fieldspecs.

I think what needs to be recorded in the rtd depends partly on the procedural interface. When accessor names are used in child constructors, they are matched by what they are bound to. So it could also be a possibility to store meta-information together with the accessor procedure.

We could also demand from the procedural layer of SRFI 99 that the procedure returned by `(rtd-accessor rtd field)` is always the same. Then we can use `eq?` to match accessors used in child constructors against parent fields (by simply looping through all the fields.

What do you think?

My concern is that if each implementation that chooses to implement srfi-150 on top of procedural layer extends make-rtd in its own way, there will be different extended make-rtd, and it can get in way of creating procedural API srfi compatible to srfi-150 in future.

An ideal solution is to propose extended procedural layer together with this srfi, but that would take time.

Will it be reasonable to include informative section outlines how srfi-99 procedural layer needs to be extended?  Just like srfi-99 notes the optional extension on shield, opaque and uid for make-rtd?

I agree that such an informative section would be quite helpful. However, we have no established standard on how to handle identifiers (vs. symbols) procedurally. So any description of a possible extension of SRFI 99's procedural layer would have to be very vague (if not too vague), wouldn't it?

Or do you have something more concrete in mind?

I might be able to come up some concrete suggestion as I implement srfi-150 on top of extended srfi-99 procedural layer.

That sounds interesting.

--

Marc

On Tue, May 23, 2017 at 11:19 AM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:

Marc Nieper-Wißkirchen, author of SRFI 150, Hygienic ERR5RS
Record Syntax (reduced), has asked me to announce "last
call" for this SRFI.  He believes that it is ready for
finalization, but would like to give reviewers one last
chance to submit corrections and feedback before we finalize
it.

<https://srfi.schemers.org/srfi-150>

In particular, I appeal to anyone reading this to try the
sample implementation, run the tests, and send feedback
about your results.

If you're interested in this SRFI, please give your feedback
via the SRFI 150 mailing list before 2017/5/31.  After that,
assuming that no major revisions are required, we will
declare it final.

Regards,


SRFI Editor
To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=XMYE8xrjaMCo6fGjz8TxaNU6CHTBX7hM

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=gohaWWilB1k9w7Z85UNiF1gxOMLGp7fu