I would like to reawaken interest in another extension of the module
meta-language, which may a lot more important for actual
implementation further libraries for R7RS (large), namely a way to
*replace* a binding silently (see Guile's #:replace option).
For example, let us assume that some future standard extends the gcd
function from (scheme base) so that it also takes zero arguments and
returns 0 in this case (NB: that would be the correct behavior).
So I would implement it as follows:
(define-library (scheme gcd)
(export gcd)
(import (rename (scheme base) (gcd %gcd)))
(begin
(define (gcd . args)
(if (null? args) 0 (apply %gcd args)))))
However, using it will be inconvenient because
(import (scheme base) (scheme gcd))
won't work as (scheme base) and (scheme gcd) try to export
incompatible bindings.
So I am looking for something like an export spec of the form (export
(replace %gcd gcd)), which means that gcd is exported and that it is a
conservative extension of %gcd. In a context, where both gcd from
(scheme base) and gcd from (scheme gcd) are imported, the Scheme
system will only use the binding of (scheme gcd). It will warn again,
if (scheme gcd2) is imported, which claims to have another
conservative extension of gcd in (scheme base). Only if the replace
clause of (scheme gcd2) claims compatibility between its gcd and the
gcd from (scheme gcd), one can again import all three libraries with
no renamings.
This proposal, however, is yet immature. Sometimes, not only the
behavior but also exact binding counts. For example, I may invoke a
macro from a fourth library that does not know about (scheme gcd). And
now assume that this macro uses gcd as some auxiliary syntax...
Any ideas to make this sound?
Marc
Am Di., 29. Sept. 2020 um 18:12 Uhr schrieb Marc Nieper-Wißkirchen
<[email protected]>:
>
> Am So., 27. Sept. 2020 um 19:49 Uhr schrieb John Cowan <[email protected]>:
>
> > 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.
