R7RS-large discussion: Miscellaneous

[John Cowan]

This is a discussion message for the Miscellaneous items from
the Red Docket. Whichever items get voted in by a majority of legal
votes cast will become part of R7RS-large. *Abstentions do not count.*
In any case, this is not a call for votes yet, only for discussion.
It will always be possible to abstain or to write in an alternative
proposal, provided it has been fully worked out somewhere (i.e. this is
not the time to design proposals from scratch). I won't keep mentioning
these two options. I will summarize the docketed proposals as neutrally
as I can. For links, see <http://trac.sacrideo.us/wg/wiki/RedDocket>.

Here we have five unrelated docket items that don't fit anywhere else.
With one exception, they are simple up/down vote items.

Boxes are analogous to pairs, but contain only a single location.
They are about the simplest possible data structure. SRFI 111 boxes
are mutable, and can be used to insert just a little bit of mutability
into an otherwise immutable structure, like ref cells in Standard ML.
The SRFI is very small.

List queues are provided by SRFI 117. They are just ordinary Scheme
lists with a pointer kept to the last pair as well as the first, making
it possible to efficiently append items to them. The SRFI is a cut-down
version of SRFI 1.

SRFI 99 records are an extension of R7RS-small records that provide single
inheritance as well as some syntactic convenience features. It also
provides a procedural interface making it possible to create arbitrary
record types at run time and to inspect records and record types.
SRFI 129 is a patch to SRFI 99 eliminating the syntactic features that
cannot be implemented using syntax-rules alone. It's possible to vote
down SRFI 99, to vote it up, or to vote it up with the SRFI 129 patch.

Ephemerons are a special variety of weak pairs, and are the only kind
of weakness currently proposed for R7RS-large. A weak pair contains a
key and a value, and allows the garbage collector to collect the value
if there are no non-ephemeron references to it, *including* from the
value itself. SRFI 124 provides a basic implementation. Note that
because there is never a guarantee that the GC will reclaim anything,
it is possible to have a trivial implementation of SRFI 124 with ordinary
strong pointers even in systems with no special GC support.

Finally, SRFI 131 provides a corrected specification of the titlecase
character and string procedures of R6RS, which have no equivalents in
the base library or SRFI 130. If SRFI 13 and 131 are adopted, then 131
will override 13.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant
le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux,
de rapport nyait pas. --Jacques Lacan, "L'Etourdit"

[Will Clinger]

John Cowan wrote:

> SRFI 129 is a patch to SRFI 99 eliminating the syntactic features that
> cannot be implemented using syntax-rules alone.

Untrue.  SRFI 129 is about " Titlecase procedures", and has nothing to do
with SRFI 99.

> Finally, SRFI 131 provides a corrected specification of the titlecase
> character and string procedures of R6RS, which have no equivalents in
> the base library or SRFI 130.

Untrue.  SRFI 131 is a patch to SRFI 99.  The corrected specification of
the R6RS titlecase character and string procedures is found in SRFI 129.

This error was made at the WG2 site and was reported, but apparently
persists.  Please correct this.

Will
 

[John Cowan]

Will Clinger scripsit:

> This error was made at the WG2 site and was reported, but apparently
> persists. Please correct this.

Fixed at RedDocket.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

Yes, chili in the eye is bad, but so is your ear. However, I would
suggest you wash your hands thoroughly before going to the toilet.
--gadicath

[Marc Nieper-Wißkirchen]

[Hygiene of R7RS (small)/SRFI 99/SRFI 131 record field names]

Consider the following record type definition (with meta-variables <field1> and <field2>):

(define-record record-type

  (make-record <field1>)

  record?

  (<field2> accessor))

In order to process this definition, the record system will have to somehow match the field names <field1> and <field2>. The procedural layers of SRFI 99 match <field1> and <field2> by symbol name, which I am going to call ‘non-hygienically’. This way of matching is clear from the description of SRFI 99 and also because a procedural system cannot do differently without any access to the underlying low-level macro facility). As SRFI 131 is built on top of SRFI 99 (and claims to be compatible), SRFI 131 record field names are also matched non-hygienically. In particular, if a child record type wants to reference a parent record type's field in its constructor, the parent record type's field name doesn't have to be exported as an identifier to the child. The child record type just have to know the symbol's name.

On the other hand, R7RS (small) says in section 5.5 that the field names <field1>, ... are identifiers. As the language used in 5.5 is no different to the language used elsewhere in the report and as identifiers are generally assumed to be matched hygienically, R7RS (small) record type definitions should match field names not by symbol name but hygienically (in other words, by what is called bound-identifier=? in some macro systems or by eq? for identifiers that are implemented as aliases in syntactic closure systems).

This makes the stated claim in SRFI 131, namely that it is compatible to R7RS (small) record system, false, which should definitely be addressed before inclusion of either SRFI 99 or SRFI 131 into R7RS large.

When it comes to implementations, I did tests with Chibi and Larceny. Chibi implements R7RS (small) records hygienically, and SRFI 99 (as written) non-hygienically, so it does match both specs. On the other hand, Larceny processes R7RS (small) records as it processes SRFI 99 records, which makes both record systems compatible, but is a deviation from the R7RS (small) standard.

That some problem exists here came up in the discussion https://github.com/ashinn/chibi-scheme/issues/361, in which also some points are made why it can be advantageous when field names are matched hygienically.

--

Marc

[Marc Nieper-Wißkirchen]

P.S.: The following program runs in Larceny (by SRFI 99, but not by R7RS (small) semantics), but gives an error in Chibi (which, as said previously, is what R7RS (small) seems to demand):

(import (scheme base)

(scheme write))

(define-syntax define-record

  (syntax-rules ()

    ((define-record make-record accessor a)

     (define-record-type <record>

       (make-record x)

       record?

       (a accessor)))))

    

(let ((x 'ignore))

  (define-record make-record accessor x)

  (define r (make-record 1))

  (display (accessor r))

  (newline))

[Will Clinger]

Marc Nieper-Wißkirchen wrote:

Consider the following record type definition (with meta-variables <field1> and <field2>):

(define-record record-type

  (make-record <field1>)

  record?

  (<field2> accessor))

In order to process this definition, the record system will have to somehow match the field names <field1> and <field2>. The procedural layers of SRFI 99 match <field1> and <field2> by symbol name, which I am going to call ‘non-hygienically’. This way of matching is clear from the description of SRFI 99 and also because a procedural system cannot do differently without any access to the underlying low-level macro facility). As SRFI 131 is built on top of SRFI 99 (and claims to be compatible), SRFI 131 record field names are also matched non-hygienically. In particular, if a child record type wants to reference a parent record type's field in its constructor, the parent record type's field name doesn't have to be exported as an identifier to the child. The child record type just have to know the symbol's name.

This was all done on purpose.  Compatibility between procedural and syntactic layers was a guiding principle of the SRFI 99 record system, as was compatibility between SRFI 9 and SRFI 99.  SRFI 131 is a superset of SRFI 9 and a subset of the SRFI 99 syntactic layer.

SRFI 131 should also have been a superset of the R7RS-small define-record-type, but you have found an incompatibility.  I believe this incompatibility is best regarded as an error in R7RS-small, because R7RS define-record-type was supposed to be compatible with SRFI 9, which refers to the names of the fields as field tags without suggesting they are anything other than symbols.
 

> On the other hand, R7RS (small) says in section 5.5 that the field names <field1>, ... are identifiers.

Actually, R7RS (small) section 5.5 says only this:  "It is an error for the same identifier to occur more than once as a field name."  I believe the word "identifier" in that sentence should have been "symbol".  Nothing else in R7RS section 5.5 suggests the field names are anything other than symbols, and the historical fact that R7RS define-record-type was intended to be compatible with SRFI 9 argues for field names being symbols.

Will
 

[Alex Shinn]

On Fri, Jun 17, 2016 at 8:30 PM, Will Clinger <cesu...@gmail.com> wrote:
>
> SRFI 131 should also have been a superset of the R7RS-small
> define-record-type, but you have found an incompatibility. I believe this
> incompatibility is best regarded as an error in R7RS-small, because R7RS
> define-record-type was supposed to be compatible with SRFI 9, which refers
> to the names of the fields as field tags without suggesting they are
> anything other than symbols.

No, we deliberately changed this - we made define-record-type
generative, at which point it pretty much has to be hygienic.

--
Alex

[Marc Nieper-Wißkirchen]

How is this related to being generative? SRFI 99 records are generative as well. And there is no need to hygienically shield child names for R7RS records because they are meanungless outside their define-record-type.

Marc

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Clinger]

Alex Shinn wrote:

No, we deliberately changed this - we made define-record-type
generative, at which point it pretty much has to be hygienic.

As Marc Nieper-Wißkirchen observed, that doesn't make any sense.
If that's the reason WG1 made the change, then the change was based
upon invalid reasoning and should be corrected by WG2.

If this correction is not made, then R7RS-large will be incompatible with
SRFI 9, SRFI 131, and SRFI 99.

Will

[John Cowan]

Marc Nieper-Wißkirchen scripsit:

> How is this related to being generative? SRFI 99 records are generative as
> well. And there is no need to hygienically shield child names for R7RS
> records because they are meanungless outside their define-record-type.

I agree. I've added this as unofficial erratum 26.

--
No saves, Antonio, loke es morirse en su lingua. Es komo kedarse soliko en el
silensyo kada dya ke Dyo da, komoser sikileoso sin saver porke.
--Marcel Cohen, 1985

[Alex Shinn]

Please don't add any erratum until we've come to a consensus.

"It is an error for the same _identifier_ to occur more than once
as a field name."

Whether the identifiers have meaning or not in R7RS, they must
be distinct. How can we write macros that expand into record
types with multiple fields using hygienic renaming if we then strip
the hygiene?

--
Alex

[Marc Nieper-Wißkirchen]

Whether the identifiers have meaning or not in R7RS, they must
be distinct.  How can we write macros that expand into record
types with multiple fields using hygienic renaming if we then strip
the hygiene?

The macro simply uses different symbols for different field names. Think of all the names implicitely quoted.

 

--
Alex

On Sat, Jun 18, 2016 at 3:34 AM, John Cowan <co...@mercury.ccil.org> wrote:
> Marc Nieper-Wißkirchen scripsit:
>
>> How is this related to being generative? SRFI 99 records are generative as
>> well. And there is no need to hygienically shield child names for R7RS
>> records because they are meanungless outside their define-record-type.
>
> I agree.  I've added this as unofficial erratum 26.
>
> --
> No saves, Antonio, loke es morirse en su lingua. Es komo kedarse soliko en el
> silensyo kada dya ke Dyo da, komoser sikileoso sin saver porke.
>                         --Marcel Cohen, 1985
>
> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-wg2+unsub...@googlegroups.com.

[Alex Shinn]

I was talking about dynamically generated fields. As we have
no gensym (nor would be able to use it anyway if we did), the
classic way to do this with syntax-rules is to use different hygienic
renamings of the same symbol, typically `tmp'.

I'm a little busy just now but can provide an example later.

--
Alex

>> > an email to scheme-reports-...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google Groups
> "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to scheme-reports-...@googlegroups.com.

[Marc Nieper-Wißkirchen]

Okay, I see your point. With the proposed erratum (thus SRFI 131 semantics) it is not possible to write a syntax-rules macro that takes any number of identifiers as arguments and expands into a record type definition that has as much fields as there are identifier arguments and, say, uses the identifiers as the names for the accessor functions.

I also agree that non-hygienic matching for the field names look a bit like a wart as this would be more or less the only occurrence of non-hygienic matching (outside of library definitions) in R7RS, wouldn't it? But how can SRFI 99/SRFI 131 be made compatible with this?

Marc

>> > an email to scheme-reports-wg2+unsub...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to scheme-reports-wg2+unsub...@googlegroups.com.

[John Cowan]

Alex Shinn scripsit:

> Please don't add any erratum until we've come to a consensus.

I've marked it PROPOSED.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

Her he asked if O'Hare Doctor tidings sent from far coast and she with
grameful sigh him answered that O'Hare Doctor in heaven was. Sad was the
man that word to hear that him so heavied in bowels ruthful. All she
there told him, ruing death for friend so young, algate sore unwilling
God's rightwiseness to withsay. Joyce, Ulysses, "Oxen of the Sun"

[John Cowan]

Marc Nieper-Wißkirchen scripsit:

> Okay, I see your point. With the proposed erratum (thus SRFI 131 semantics)
> it is not possible to write a syntax-rules macro that takes any number of
> identifiers as arguments and expands into a record type definition that has
> as much fields as there are identifier arguments and, say, uses the
> identifiers as the names for the accessor functions.

The whole point of SRFI 131 is to deal with the fact that syntax-rules can't
introduce identifiers that are not provided at the time of call: in other
words, it has no syntax->datum analogue. You can't have it both ways;
if you want to do something like this, use a non-hygienic macro system.

> I also agree that non-hygienic matching for the field names look a bit like
> a wart as this would be more or less the only occurrence of non-hygienic
> matching (outside of library definitions) in R7RS, wouldn't it?

Inclusion is also non-hygienic: if a file cons.scm contains "cons",
then (let ((cons +)) ((include "cons.scm") 1 2)) => 3, not (1 . 2).
This is IMO the Right Thing. Library definitions are irrelevant because
they are not written in Scheme at all.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

You cannot enter here. Go back to the abyss prepared for you! Go back!
Fall into the nothingness that awaits you and your Master. Go! --Gandalf

[Alex Shinn]

On Sat, Jun 18, 2016 at 7:45 AM, John Cowan <co...@mercury.ccil.org> wrote:
>
> Inclusion is also non-hygienic: if a file cons.scm contains "cons",
> then (let ((cons +)) ((include "cons.scm") 1 2)) => 3, not (1 . 2).
> This is IMO the Right Thing. Library definitions are irrelevant because
> they are not written in Scheme at all.

Non-library-declaration include is also a wart in the language.

--
Alex

[Will Clinger]

John Cowan wrote:

 

if you want to do something like this, use a non-hygienic macro system.

Or use the procedural layer of SRFI 99, which can easily handle the use
case being discussed.

Will
 

[Alex Shinn]

On Sat, Jun 18, 2016 at 7:36 AM, John Cowan <co...@mercury.ccil.org> wrote:
> Alex Shinn scripsit:
>
>> Please don't add any erratum until we've come to a consensus.
>
> I've marked it PROPOSED.

And I've removed it. Even if you could convince me we
wanted to make this unhygienic, it's too big a change to make
as an erratum. Errata should only be mistakes which would
clearly be broken if not addressed, and require unanimous
agreement from the WG1 members. If the WG2 members
need to make semantic changes at this late point in the
game, they need to maintain their own list of extensions or
incompatibilities to the small language.

Far from convinced, I think we made the correct decision
in WG1 and it's essential that the field accessors and names
remain hygienic. Discussion of records was one of the
longest topics, spanning multiple ballots and several proposals.
One thing we made clear in the list from early on was that
we were only considering the generative extension to SRFI 9,
because you could then use the syntactic API to implement
a procedural API. Thus, our `define-record-type' is not some
static, top-level class definition, but a way to introduce new
lexical types. To make these unhygienic is just not acceptable.

To answer Marc's original question, I don't see the problem
with extending SRFI 131 to allow identifiers as field names.

--
Alex

[Will Clinger]

Alex Shinn quoting John Cowan quoting Alex Shinn:

>> Please don't add any erratum until we've come to a consensus.
>
> I've marked it PROPOSED.

And I've removed it.  Even if you could convince me we
wanted to make this unhygienic, it's too big a change to make
as an erratum.  Errata should only be mistakes which would
clearly be broken if not addressed, and require unanimous
agreement from the WG1 members.

At least one of the following sentences is clearly wrong, because
the two sentences contradict each other:

R7RS-small section 5.5: "It is an error for the same identifier to

occur more than once as a field name."

Other language changes since R5RS: "New disjoint types
supporting access to multiple fields can be generated with
the define-record-type of SRFI 9 [19]"

The second of those sentences is found within a list that is
explicitly "not authoritative", so I regard the sentence quoted
from R7RS section 5.5 as a definitive statement that R7RS
(small) define-record-type is not compatible with SRFI 9.

If the WG2 members
need to make semantic changes at this late point in the
game, they need to maintain their own list of extensions or
incompatibilities to the small language.

Yes, WG2 should fix this.

Far from convinced, I think we made the correct decision
in WG1 and it's essential that the field accessors and names
remain hygienic.  Discussion of records was one of the
longest topics, spanning multiple ballots and several proposals.
One thing we made clear in the list from early on was that
we were only considering the generative extension to SRFI 9,
because you could then use the syntactic API to implement
a procedural API.  Thus, our `define-record-type' is not some
static, top-level class definition, but a way to introduce new
lexical types.  To make these unhygienic is just not acceptable.

As three people have already pointed out within this thread,
the argument made in that paragraph doesn't make sense.
Whether field names are symbols or identifiers is orthogonal
to the question of whether record definitions are generative.

Repeating that invalid argument just reinforces my impression
WG1 relied upon invalid reasoning when it introduced this
incompatibility between R7RS-small and SRFIs 9 and 99
(and now SRFI 131).

If no valid argument can be made for retaining the R7RS (small)
semantics, then R7RS (large) should change the semantics of
define-record-type to make it consistent with SRFIs 9, 99, and 131.

Will

[John Cowan]

Alex Shinn scripsit:

> Far from convinced, I think we made the correct decision
> in WG1 and it's essential that the field accessors and names
> remain hygienic.

Nobody doubts that the accessors (and mutators) should be hygienic,
as they are the names of Scheme variables. It's only the field
names that are at issue.

> One thing we made clear in the list from early on was that
> we were only considering the generative extension to SRFI 9,

I still don't understand what generativeness has to do with whether
field names are identifiers or symbols.

> Thus, our `define-record-type' is not some static, top-level class
> definition, but a way to introduce new lexical types.

What is a lexical type?

I note that although R6RS says field names are identifiers, it also
says:

# The <field name>s become, as symbols, the names of the fields in the
# record-type descriptor being created, in the same order.

SRFI 99 also says that field names are identifiers, but has no equivalent
of the above remark.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

A rose by any other name may smell as sweet, but if you called it
an onion you'd get cooks very confused. --RMS

[John Cowan]

Will Clinger scripsit:

> If no valid argument can be made for retaining the R7RS (small)
> semantics, then R7RS (large) should change the semantics of
> define-record-type to make it consistent with SRFIs 9, 99, and 131.

As my earlier post implies, it's not clear what the semantics of SRFI 99
are in this respect, since it says field names are identifiers and does
not mention their role as symbols.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

Normally I can handle panic attacks on my own; but panic is, at the moment,
a way of life. --Joseph Zitt

[Alex Shinn]

On Sat, Jun 18, 2016 at 12:32 PM, Will Clinger <cesu...@gmail.com> wrote:
>
> R7RS-small section 5.5: "It is an error for the same identifier to
> occur more than once as a field name."
>
> Other language changes since R5RS: "New disjoint types
> supporting access to multiple fields can be generated with
> the define-record-type of SRFI 9 [19]"
>
> The second of those sentences is found within a list that is
> explicitly "not authoritative", so I regard the sentence quoted
> from R7RS section 5.5 as a definitive statement that R7RS
> (small) define-record-type is not compatible with SRFI 9.

Both aspects, generativeness and allowing identifiers, are
purely backwards-compatible extensions to SRFI 9.

--
Alex

[Alex Shinn]

On Sat, Jun 18, 2016 at 12:34 PM, John Cowan <co...@mercury.ccil.org> wrote:
> Alex Shinn scripsit:
>
>> Far from convinced, I think we made the correct decision
>> in WG1 and it's essential that the field accessors and names
>> remain hygienic.
>
> Nobody doubts that the accessors (and mutators) should be hygienic,
> as they are the names of Scheme variables. It's only the field
> names that are at issue.

The field names are used in the constructor to match which
fields are initialized. I have to go out now, but if you can't think
of how hygiene could break here I'll provide a concrete example
later.

--
Alex

[Will Clinger]

John Cowan wrote:

As my earlier post implies, it's not clear what the semantics of SRFI 99
are in this respect, since it says field names are identifiers and does
not mention their role as symbols.

We could seek to clarify that by reading the rest of SRFI 99, by
examining its reference implementation, and by considering its
use in practice.  As a last resort, we could question the author
of SRFI 99, whose opinion would be at least as authoritative
with respect to SRFI 99 as (say) the opinion held by one of the
three editors of R7RS (small) with respect to that document.

SRFI 99 says "The define-record-type syntax specified by
this SRFI is compatible with and extends SRFI 9", and also says
"The procedural layer specified by this SRFI is fully compatible
with its define-record-type syntax."  For reasons mentioned
earlier in this thread, that already implies field names are symbols.

SRFI 99 mentions identifiers only when discussing the syntactic
layer.  In connection with field names, I believe the author of that
SRFI was using the word "identifier" as in R6RS section 4.2.1,
where it is defined by a nonterminal in the context-free grammar.
R6RS chapter 4 does not mention symbols until R6RS section 4.2.4,
which says "Any identifier may also be used as a syntactic datum,
in which case it represents a symbol (see section 11.10)."

It might be a good idea to add something like the above clarification
of SRFI 99 as some kind of erratum for that document.

Will

[Marc Nieper-Wißkirchen]

The field names are used in the constructor to match which
fields are initialized.  I have to go out now, but if you can't think
of how hygiene could break here I'll provide a concrete example
later.

The macro

(define-syntax foo

  (syntax-rules ()

    ((foo c p identifier ...)

     (define-record-type <rtd>

       (c identifier ...)

       p

       (identifier identifer) ...))))

cannot be written with non-hygienic symbols. It would have to use the procedural layer (and would happen at execution time) of SRFI 99, which is not provided by R7RS-small.

[Marc Nieper-Wißkirchen]

And I've removed it.  Even if you could convince me we
wanted to make this unhygienic, it's too big a change to make
as an erratum.  Errata should only be mistakes which would
clearly be broken if not addressed, and require unanimous
agreement from the WG1 members.  If the WG2 members
need to make semantic changes at this late point in the
game, they need to maintain their own list of extensions or
incompatibilities to the small language.

If implementations don't agree on the semantics of R7RS-small records, it would make no difference to include such a thing in an erratum or not. Without agreement, as a macro writer I simply have to carefully choose names that are distinct as symbols and are distinct as identifiers, which is the least common denominator. So if, say, Chibi and Larceny (I haven't tested other implementations yet), remain contradictionary, it makes more sense to specify it as undefined behaviour, namely whether the names are matched as symbols or identifiers.

But it would be much better, if a consent was found.

 

To answer Marc's original question, I don't see the problem
with extending SRFI 131 to allow identifiers as field names.

As SRFI 131 is only about the syntax, there wouldn't be a problem when viewed in isolation. However, it would break compatibility with SRFI 99. And it would break compatibility with R7RS-small: If field names are identifiers, they have to be exportable so that record types that extend the original record type are able to access them (they want to mention them in their constructor). So SRFI 131's define-record-type would have to bind all field names in the outer scope, which is in contrast to R7RS-small records (and SRFI 9 and SRFI 99 records).

[Will Clinger]

Marc Nieper-Wißkirchen wrote:

If implementations don't agree on the semantics of R7RS-small records, it would make no difference to include such a thing in an erratum or not. Without agreement, as a macro writer I simply have to carefully choose names that are distinct as symbols and are distinct as identifiers, which is the least common denominator. So if, say, Chibi and Larceny (I haven't tested other implementations yet), remain contradictionary, it makes more sense to specify it as undefined behaviour, namely whether the names are matched as symbols or identifiers.

If the R7RS (small) semantics were defensible, Larceny's semantics
could be changed to align with R7RS (small).  That would come with
costs.  The less important cost is that any library or program that
imports both (scheme base) and some combination of SRFI 9, SRFI 99,
and SRFI 131 would have to rename/exclude R7RS define-record-type
when importing (scheme base).

As you point out, however, portable programs that use any of those
three SRFIs have to do that renaming anyway, because there is at
least one implementation (Chibi) in which the R7RS (small) semantics
is actually implemented.

The far more important problem with the R7RS (small) semantics is
this:
 

If field names are identifiers, they have to be exportable so that record types that extend the original record type are able to access them (they want to mention them in their constructor). So SRFI 131's define-record-type would have to bind all field names in the outer scope, which is in contrast to R7RS-small records (and SRFI 9 and SRFI 99 records).

The R7RS (small) semantics must have been adopted without giving
any thought to the possibility of adding inheritance as in SRFI 99 and
SRFI 131.  If WG2 wants extensible records (with inheritance) in R7RS
large, we will have to overturn this one-word detail of R7RS section 5.5.

I believe WG2 should and will add extensible records, reverting to the
field name semantics of SRFI 99 and 131 as it does so.  That is why
Larceny's implementation of R7RS define-record-type will remain
compatible with those SRFIs for the time being, and incompatible
with that one word of R7RS section 5.5.

Will

[Marc Nieper-Wißkirchen]

 

If field names are identifiers, they have to be exportable so that record types that extend the original record type are able to access them (they want to mention them in their constructor). So SRFI 131's define-record-type would have to bind all field names in the outer scope, which is in contrast to R7RS-small records (and SRFI 9 and SRFI 99 records).

The R7RS (small) semantics must have been adopted without giving
any thought to the possibility of adding inheritance as in SRFI 99 and
SRFI 131.  If WG2 wants extensible records (with inheritance) in R7RS
large, we will have to overturn this one-word detail of R7RS section 5.5.

I believe WG2 should and will add extensible records, reverting to the
field name semantics of SRFI 99 and 131 as it does so.  That is why
Larceny's implementation of R7RS define-record-type will remain
compatible with those SRFIs for the time being, and incompatible
with that one word of R7RS section 5.5.

I also believe that some specification of extensible record types should be part of R7RS-large. However, we R7RS-large should be a conservative extension of R7RS-small as it is actually implemented.

By this I mean: if all complete implementations of R7RS-small that implement Chibi's model of syntactic records (the model that was actually defined in R7RS-small on purpose) can be convinced  to adopt the model of SRFI 9 and SRFI 99, there would be no actual incompatibility.

However I understand Alex's objections of changing Chibi's model as this would make some use cases impossible (in reality, they are already impossible in a portable way because implementations disagree).

So I propose the following change to R7RS-small record types that make them compatible to SRFI 9/SRFI 99/SRFI 131 records, but make Alex' use cases possible:

- Field names are symbols, not identifiers as in SRFI 9.

- Instead of a field name in a field definiton, also #f is allowed.

- Instead of field names, one may use the record field accessor in the constructor. They are, of course, matched hygienically.

SRFI 131 could build on this extension of SRFI 9 records. It would also become a

strict superset of SRFI 99's syntactical layer, which is fine. 

EXAMPLE 1:

(define-record-type <record>

  (make-record field1 getter2)

  record?

  (field1 getter1)

  (#f getter2)))

If children record types want to use the second field in their constructor, they will have to know the denotation of getter2.

EXAMPLE 2:

(define-syntax define-immutable-record-type

  (syntax-rules ()

    ((define-immutable-record-type <rtd> constructor pred? getter ...)

     (define-record-type <rtd>

       (constructor getter ...)

       pred?

       (#f getter) ...)))))

       

Marc

Will

--
You received this message because you are subscribed to a topic in the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scheme-reports-wg2/oKuhgwaM45w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scheme-reports-...@googlegroups.com.

[Marc Nieper-Wißkirchen]

P.S.: In other words, when we want hygienic matching of fields, the concept of <field name> becomes superfluous (barring introspection, which is not specified) as we already have entities we can use for hygienic matching, namely the <accessor name>s. With the original semantics in SRFI 9, the <field name>s are not superfluous as the <accessor name>s should be identifiers in all cases.

To unsubscribe from this group and all its topics, send an email to scheme-reports-wg2+unsub...@googlegroups.com.

[John Cowan]

Will Clinger scripsit:

> We could seek to clarify that by reading the rest of SRFI 99, by
> examining its reference implementation, and by considering its
> use in practice. As a last resort, we could question the author
> of SRFI 99, whose opinion would be at least as authoritative
> with respect to SRFI 99 as (say) the opinion held by one of the
> three editors of R7RS (small) with respect to that document.

Digression: I don't claim to be an authoritative interpreter of that
document, but I deny (on general principle) that the author of a document
is an authority on its meaning either. At most the author can say what
the authorial intent was, but authorial intent cannot supersede what
lawyers call the plain meaning of a document. I've been down this road
before with Doug Crockford and the JSON RFC. He found it very difficult
to accept that what he says now that he meant when he wrote that RFC
doesn't control its interpretation.

> SRFI 99 says "The define-record-type syntax specified by
> this SRFI is compatible with and extends SRFI 9", and also says
> "The procedural layer specified by this SRFI is fully compatible
> with its define-record-type syntax." For reasons mentioned
> earlier in this thread, that already implies field names are symbols.

I don't see that it does anything of the sort. The claims made by a
document about *itself* are matters of fact rather than definition,
and might turn out not to be the case. Alex is already asserting that
SRFI 99, contrary to this claim, is self-inconsistent. Of course he
might be wrong.

> It might be a good idea to add something like the above clarification
> of SRFI 99 as some kind of erratum for that document.

An erratum would be welcome, particularly since we now have a de facto
erratum process. Talk to Art about it.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org

You escaped them by the will-death and the Way of the Black Wheel.
I could not. --Great-Souled Sam

[Will Clinger]

John Cowan quoting me:

> We could seek to clarify that by reading the rest of SRFI 99, by
> examining its reference implementation, and by considering its
> use in practice.  As a last resort, we could question the author
> of SRFI 99, whose opinion would be at least as authoritative
> with respect to SRFI 99 as (say) the opinion held by one of the
> three editors of R7RS (small) with respect to that document.

Digression: I don't claim to be an authoritative interpreter of that
document, but I deny (on general principle) that the author of a document
is an authority on its meaning either.  At most the author can say what
the authorial intent was, but authorial intent cannot supersede what
lawyers call the plain meaning of a document.  I've been down this road
before with Doug Crockford and the JSON RFC.  He found it very difficult
to accept that what he says now that he meant when he wrote that RFC
doesn't control its interpretation.

Thank you, John.  That is the response for which I was trolling.

Limiting ourselves to the plain meaning of R7RS small, there is
at most one word that could be cited in support of Alex Shinn's
opinion that field names are to be interpreted as denotations of
identifiers regarded as variables/keywords rather than symbols.

That one word is "identifier", as used in this sentence:

    It is an error for the same identifier to occur more than
    once as a field name.

That use of the word "identifier" is ambiguous because, as was
explained in R7RS section 2.1:

    Identifiers have two uses within Scheme programs:

      * Any identifier can be used as a variable or as a
        syntactic keyword (see sections 3.1 and 4.3).

      * When an identifier appears as a literal or within
        a literal (see section 4.1.2), it is being used to
        denote a symbol (see section 6.5).

To decide which of those uses was intended when "identifier"
is a field name, we'd have to know whether field names are
to be interpreted as variables/keywords or as literals.  The
R7RS doesn't say anything about that.

So the "plain meaning" of the R7RS (small) document is entirely
neutral with respect to the interpretation of field names as
symbols or as identifier/keyword denotations.

When the plain meaning of a document is insufficient to resolve
issues such as this, we can look at common practice, historical
context, and authorial intent.

Another legal principle may play a role:  When there are two
ways to interpret a document, and one of those interpretations
allows the document to achieve its stated purpose while the
other does not, the interpretation that achieves the stated
purpose of the document should be preferred.

That is the case with SRFI 99 and SRFI 131.  If field names are
symbols, then inheritance of fields works reliably.  If field
names are identifier/keyword denotations, however, then the
matching of field names in constructor clauses will be affected
by coincidental definitions of variables that happen to have
the same names.  It is easy to construct a test case for this,
and I will post an example in the thread devoted to technical
discussion of records.

According to my tests, all implementations of SRFI 99, including
Chibi's, interpret field names as symbols.

So field names are symbols in common practice.  Historically,
field names were symbols in the R6RS syntactic layer.  That
leaves only authorial intent.

I have sent a message to the post-finalization discussion for
SRFI 99 saying the word "identifier" is there used as in R6RS
Libraries section 6.2, which means field names are symbols.

It looks to me as though you have said you intended for field
names to be symbols in SRFI 131.

Alex Shinn, however, has said field names are not symbols in
R7RS small.  It looks as though he isn't speaking for his
co-editors, but Alex's statements do count as a statement of
authorial intent.  That one example of authorial intent seems
to be the only real argument for interpreting R7RS (small) to
mean field names are not symbols.

Regardless of whether any of us are convinced by Alex Shinn's
statement of authorial intent (which happens to be contradicted
by Alex Shinn's implementation of SRFI 99), WG2 should consider
this question on its own merits, which I will discuss in the
other thread.

Will