> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, August 30, 2020 9:52 AM
>
>> [...]
>>
>> And I'm sorry I failed to communicate my question.  *Exactly* how
>> would the library developer consulting registry.scheme.org discover
>> "'sqlstate" and "'oracle-ORA"?  Would he navigate to a sub-page and
>> ^F/F3 search for likely things, like "database", "RDMBS", "sql", etc.?
>>
>> If there is such a sub-page, what limiting principle, if any, would
>> be used to decide which names to include in it, vs. ones that might
>> be in a sub-sub-page like fiddly details only relevant to Oracle
>> ORAs, PostgreSQL status returns, etc.?
>
> We have a tentative list of 15 properties at
> <https://registry.scheme.org/#foreign-status-property>. Assume we wrap
> so many foreign systems that the list grows to 50 properties, making it
> difficult to navigate at a glance.
>
> Options for managing that level of complexity:
>
> * Use prefixes: e.g. start SQL-related property names with `sql`
>    and HTTP-related ones with `http`.
>
> * Have little groups of two or three properties that are conventionally
>    used together and interpreted in light of each other. We started with
>    `set`, `code/number`, and `name/symbol`. That would be one set where
>    all three help interpret the others.

Both of the above are sounding a bit like like our convention concept.

> [ We agree there are set-independent properties like `line-number`. ]
>
> I think the issue you're getting at is: "Suppose I'm interfacing to
> sqlite; how do I know which properties I can expect to be filled in by a
> foreign status object coming from the sqlite interface? I could test for
> all 50 properties, but that doesn't make much sense."
>
> I think that is a question that would make sense to pose to the people
> who wrote each interface, not to the registry.

TILT / face palm / segment fault.

Why is this not in the remit of Schemeregistry?  If only to help
people building new interfaces that share some characteristics
beyond the most common 15-50?

How is this even vaguely practical?   In your vision that knowledge
will be smeared across the Internet, the Wayback Machine, etc., or
worse, require bothering a developer for something you could just
look up in the registry?

> Suppose you're the person writing the sqlite binding. You'd go
> through the manual for SQLite's C API, looking at what information
> it returns. You'd then look at the full list of 50 properties in the
> registry, picking out the ones that have a sensible mapping to
> something coming from the SQLite C API, and leave out the rest.

And then what do you do for new ones you come up with, ones that
others might see were they in the registry and want to use in a
standardized way.

I now realize there's a veritable chasm between my visions for both
SRFI 198 and the Schemeregistry and yours'.  I can see no way of
bridging it.

> E.g. the C API gives you an error code and corresponding error message,
> so your Scheme wrapper would fill in the 'code and 'message properties.
> Likewise, if we had a 'foreign-system or 'foreign-library property or
> some such, you'd put 'sqlite or 'sqlite3 in there. If SQLite returned a
> SQLSTATE code, you'd store it in a 'sqlstate property. But I don't think
> it does; this illustrates that the flexibility in not unnecessarily
> coupling properties is useful. You'd think all SQL databases use
> SQLSTATE codes, but maybe not. Things like that.

In that case, we'd expect the interface writer to notice his database
that speaks (some) SQL doesn't return SQLSTATEs, and not use the
'sqlstate convention.  But he'd likely pick up some clues as to what
to use from looking at that convention, or perhaps a 'no-sql
convention if there's enough commonality in that class of databases
to create such a top level convention, etc. etc.

> What we're doing is kind of like duck typing in OOP. Dynamic
> languages are kind of based on the insight that you can leave out
> constraints that everyone thinks are mandatory for basic programming
> sanity and everything can still work just fine.

That's what you're doing.  We're saying that if you want to get more
sophisticated than the 'error or 'status conventions, we'd really like
you to search for prior art on the registry, and register new stuff
you come up with *with explanations for your new properties*.

Of course, we'll have keys who's properties in the wild have subtle or
vast differences, won't be registered, etc. etc.  Maybe John and my
vision is unrealistic....

> [ Insert dislike of class based OO. ]

- Harold