- Internal type system might have used symbols or identifiers that services "type name"---e.g.

for debugging or introspection. srfi-137's type payload can be any Scheme values, so either

such internal system adds new field in its type structure to hold the type payload, or modify

internal system to accept any object as a type name. It's doable, but its extra complexity

without clear benefit (except supporting srfi-137 itself).

SRFI 137's type payload can only be accessed via a procedure returned by make-type. There is no way to get a reference to such a procedure when a given a value of a certain type or when given the type predicate. So supporting the type paylod of SRFI 137 seems orthogonal to existing type systems.

- Records can be implemented in a way that an instance is stored in a single contiguous

memory, with type tag and instance payload together. In such systems, the constructor

and accessor are likely to need copying and extra bookkeeping; or it implements srfi-137

based instances with extra layer (i.e. internally srfi-137 instance is represented as a

native record with a slot that holds given instance payload), which is probably the case

if srfi-137 is implemented on top of existing record systems such as srfi-9. Then we get

seemingly unnecessary layering---any record system based on srfi-137 will have a

structure that "a record system based on srfi-137 layer that is emulated by the native

record system". Probably this layering is the thing bothering me.

Isn't this only a problem for portable implementations of record-type systems? If SRFI 137 finds enough support in the community, the idea would be that each implementation provides SRFI 137 and all natively supported record-type systems in the same low-level layer. Only portable implementations will have to use the SRFI 137 interface.

Do existing record systems so fragmented that they'll hinder further development? I might

be unaware of that since usually I stick to a single implementation. For example, it's

easy for Gauche to provide srfi-137 on top of existing type system. But if there will be

nice record system srfi, I'd prefer implementing it directly bypassing srfi-137 layer.

Then it doesn't matter if the initial srfi is based on srfi-9 or srfi-99 or whichever existing

record system.

Existing and proposed record systems want to achieve two things at once: Providing a way to structure a vector-like value (i.e. a record), and providing a way to create disjoint types and to create subtypes for them (in the sense of SRFI 137). I have understood this SRFI as a means to untangle these two things. SRFI 137 is only about the latter.

Also, as I suggested earlier, we could use SRFI 137 to actually define what we mean by "disjoint type" and "subtype" so that other SRFIs can reference this one.

As to fragmentation of record systems: SRFI 9 seems to be widely accepted, but does not allow sub-types. However, SRFI 9 is interpreted differently amongst implementations and standards (for example, Scheme 48, Racket, Chibi, R7RS-small interpret field names as identifiers, possibly renamed for hygiene; on the other hand, Larceny, SRFI 99, and SRFI 131 interpret field names as symbols). Without consensus, it is hard to write portable code.

While SRFI 131 won't work well with R7RS-small's definition of record types, my SRFI 136 does not have this problem. However, I don't know whether there will be a consensus to integrate that into R7RS-large.

With SRFI 137, everyone could choose their own record system while inheritance chains of record types from different record systems would still work.

--

Marc

On Thu, Jun 30, 2016 at 1:28 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

Shiro Kawai <xxxxxx@gmail.com> schrieb am Mi., 29. Juni 2016 um 23:53 Uhr:

(It seems that I sent this to wrong address, so this is a retry)

However, existing implementations must already have internal type

handling mechanisms, and if an implementation already supports some

record type, it's likely that it wants to directly integrate it to the internal

type system. Such internal type system doesn't need to fit smoothly

with srfi-137 protocol, in which case srfi-137 just adds complexity as

opposed to simplifying it.

Can you think of a type system (that is able to handle SRFI 9 records) that is incompatible (in the sense that it doesn't fit smoothly) with SRFI 137?

Marc