> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Tuesday, October 01, 2019 3:27 PM
>
>>>> New opaque data type, tech-stack, and that's not a good name for
>>>> the stack of e.g. "subprocess jdbc db2", suggestions including
>>>> replacing "stack" are solicited.
>
> [ Lassi makes a very convincing and thorough case for "db-", which I
>   was already arguing myself towards. ]

"db-" it is.

> [ Other good points on avoiding vagueness. ]
>
>> What I'd *really* like is a better name for "stack" / "tech-stack",
>> which encompasses everything needed to get to the database as well as
>> it.
>
> I didn't quite catch how these procedures are used. Do you have an
> example sketched up?

No, but it would be something like this:

(db-stack-construct '((connection-pooling . #f)
                      (connector . subprocess)
                      (connector . jdbc)
                      (database . db2)
                      (read-only . #t))

It would then load the proper libraries, and for something like
read-only which I just dreamed up only for the purpose of this example,
place configuration information so it could be consumed when procedures
get called, like db-connect (not a good example, since it obviously
belongs in the connect string).  It sets up the chain ... ah, that's
perhaps a better word than stack, of "technology" that gets you to your
database of choice.  Like this:

sdbi
connector connection-pooling if it was on
subprocess-jdbc
db2

Parsing two connection pairs, which probably have to be in order,
doesn't sound like fun, would be more procedural than declarative, so
perhaps (connector . subprocess-jdbc) in their place.  Except if I
don't put the stack in order per the above, connection-pooling before
the connectors, database after, then it would be a a bit of a mess to
consume.  perhaps better that than failing in odd ways for the user,
but like connect strings, this is a pretty "magical", cookbook area.

Another idea would be to make this explicit in chained procedure calls,
but laying out an alist like the above looks more clean to me.

>>>> Everything following, which starts with (sdbi-read result-set)....
>
> "read" is a good name since it's used a lot in standard Scheme (well,
> in R7RS) so it reinforces those names in the programmer's memory.
> Unfortunately R6RS uses "get" in place of "read" a lot so the
> convention is not as strong as it could be.

Hmmm, not knowing of the above conventions, I've been think of "get" to
interact with the database, sql-result-set -> db-get-result, returning a
result-set, then I kept read to retrieve data from that.  Like, oh,
getting a book from the bookself, then reading it.

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Tuesday, October 01, 2019 3:45 PM
>
> That mail I sent sounded oddly negative. That's what happens when one
> sends "only the diffs", which tend to focus on what could be improved
> instead of what is right, and as text instead of speech. Sorry about
> that - overall, you're doing great work at a fast pace!

Maybe ... but I didn't take it that way at all, and your reply was
exactly the sort of thing I was looking for.  And thanks; to me it
feels like a crawl, I spend a lot of time pondering till things
fit together and the like.

And again using the Thesarus site, maybe this list will spark better
names, instead of db-chain-construct:

(db-chain-assemble
(db-chain-combine
(db-chain-compose
(db-chain-concatenate
(db-chain-establish
(db-chain-integrate
(db-chain-order
(db-chain-setup

- Harold