On Tue, Jul 12, 2016 at 2:07 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

- 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.

I think we're on the same page in that regard. What I'm saying is that, because of srfi-137 and existing type systems are orthogonal, supporting srfi-137 is purely an additional cost for existing implementations. The cost pays off when it can use srfi-137-based systems in future; however, using such systems over srfi-137 is like using it through emulation layer, and I (as a maintainer of an implementation) would rather plug such systems into existing type systems directly if they're useful.

So, srfi-137 is certainly useful for having portable implementations of experiment / PoC / transient code until it is ported on native type system, etc. It may serve as a common language of defining type-related systems. I do see the value for that. I just don't expect that the code actually written in terms of srfi-137 would run on the actual day-to-day codebase; but we'll see.

At this point of discussion, my opinion to this srfi is that I like to see the intro of this srfi makes it clear that it does not intende to unify type systems in the existing implementations, but provide a convenient common language on top of that we can experiment/discuss various type systems. If it's already clear, I just missed it.

Only portable implementations will have to use the SRFI 137 interface.

Yes, that's exactly my point. And such portable implementations wouldn't be quite integrated to the underlying systems, thus they will only serve as temporary or experimental solution.

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.

I totally agree on that. As a conceptual design layer, srfi-137 is nice.

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.

[...]

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

One problem I see is the notion of subtype srfi-137 provides. In srfi-137 it just mean that an instance of subtype responds affirmatively to the type predicate of parent types. To actually implement subtypes there are more to do, and it's up to each record system, and predicates are just a small part of the story. It is more like a common interface of the actual record system implementation, and not like a concrete mechanism every record system needs to rely on. If I want to implement multiple inheritance, it's still easy to provide interface in predicates (i.e. instance of subtype responds true to parent's type predicate) but it would be awkward to implement the actual inheritance using srfi-137.

Now, I see the existing record systems either fall short as a basis of further record systems or have unnecessary stuff, and are mutually incompatible. And I see srfi-137 extract common factors well, can be implemented on various existing systems, and new record systems can be implemented on srfi-137 portably. I don't object that. But I feel like what it's doing is having turing machine as a common layer of execution mechanism; it can be implemented on various existing systems, and new systems can be implemented portably on top of that, but do you really want to do so?

However, I don't have any alternative idea to address the fragmented record system issue. I'll think on this more.