Am So., 27. Sept. 2020 um 19:49 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> To an accountant, a debit is the increase of an asset or the decrease of a liability, and a credit is the opposite: the decrease of an asset or the increase of a liability.  So when a business gets a cash payment from a customer, it increases (debits) its cash-on-hand account, which is an asset, and correspondingly decreases (credits) its cash-on-hand account when it pays a supplier.
>
> Why then, when you get a bank statement, does it talk about deposits as credits and withdrawals as debits?  _Because the bank is compelling you to take on their point of view_.  To the bank, your checking and savings accounts are liabilities that the bank has to pay back whenever you ask them to.  So when you deposit into your account, the bank increases (credits) its liability to you; when you withdraw from your account, the bank decreases (debits) its liability. By the same token, your debit card permits you to debit (from the bank's viewpoint) your accounts.  But a credit card is an asset account from the bank's perspective, so the rules are reversed.

Thanks for the explanations! Here in Germany, the symmetry is lost.
While we talk about "Kreditkarten", we usually do not talk about
"Debitkarten", but "EC-Karten" (from the old Eurocheque system).

> I agree.  Or from the other perspective, if you plant a footgun like Marc's `get` in your library, you can't complain if users do things to your library that you didn't expect.

:)

> So I am very unwilling to dictate how libraries are stored.  In particular, Chicken imports (foo bar baz) not by looking along the library path for a file named foo/bar/baz.{scm,sls,sld,etc.} but for a file named foo.bar.baz.scm.  No directory structure is involved.  AFAIK no current Scheme keeps its library in SQLite, but the idea is not absurd: an (edit (foo bar baz)) procedure would extract the library, run ${VISUAL-${EDITOR}} on it, and rewrite the modified library to the database.

Or, compiled libraries they will be stored in some binary blob.

>> There's not a lot of benefit to replacing one file that imports and re-exports a bunch of ids vs. a file that says it aliases another library -- in both cases the file still has to be read (and in an auto-dependency checking system, re-read or at least stat'ed if you trust modification timestamps) -- other than semantic clarity.
>
> Well, it's less error-prone.  Explicit re-exporting exposes you to missing newly added identifiers if that's what you want to do (that may be the last thing you want to do, of course).

Internally, Unsyntax maintains a table of loaded libraries (which is
important so that a library doesn't get loaded twice, which, while
allowed by R7RS (small), may cause parts of a program including eval'd
parts not working well together). If one library is an exact alias of
another one, I have to store only one entry (with two names) in that
table. (This is how I alias (srfi 1) and (scheme list), for example.)
If, on the other hand, a library re-exports the exact interface of
another one, I have to store an extra entry in the table.)

Using the language of SRFI 212, it is a bit like

(alias x y)

vs

(define x y).

>> I like my export-from declaration (accepts arbitrary import specs, and only re-exports, does not import) because if I also want to import the same ids, I can do that separately.