define-library-alias Lassi Kortela (26 May 2020 13:34 UTC)
Re: define-library-alias Shiro Kawai (27 May 2020 00:08 UTC)
Re: define-library-alias Jim Rees (23 Sep 2020 02:07 UTC)
Re: define-library-alias Jim Rees (23 Sep 2020 02:08 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (23 Sep 2020 06:02 UTC)
Re: define-library-alias Jim Rees (23 Sep 2020 12:52 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (23 Sep 2020 12:58 UTC)
Re: define-library-alias John Cowan (23 Sep 2020 21:45 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (24 Sep 2020 05:53 UTC)
Re: define-library-alias John Cowan (25 Sep 2020 21:27 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (26 Sep 2020 07:44 UTC)
Re: define-library-alias Jim Rees (26 Sep 2020 21:11 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (26 Sep 2020 21:23 UTC)
Re: define-library-alias Jim Rees (27 Sep 2020 01:44 UTC)
Re: define-library-alias John Cowan (27 Sep 2020 17:49 UTC)
Re: define-library-alias Arthur A. Gleckler (27 Sep 2020 18:16 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (29 Sep 2020 16:13 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (30 Sep 2020 07:08 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (29 Sep 2020 16:00 UTC)
Re: define-library-alias Jim Rees (26 Sep 2020 01:05 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (26 Sep 2020 07:49 UTC)
Re: define-library-alias Alex Shinn (27 May 2020 00:35 UTC)
Re: define-library-alias Shiro Kawai (27 May 2020 01:30 UTC)
Re: define-library-alias Alex Shinn (27 May 2020 03:26 UTC)
Re: define-library-alias Shiro Kawai (27 May 2020 04:09 UTC)
Re: define-library-alias Lassi Kortela (27 May 2020 07:27 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (27 May 2020 07:53 UTC)
Re: define-library-alias Lassi Kortela (27 May 2020 07:57 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (27 May 2020 08:05 UTC)
SCHEME_PATH and library lookup metadata files Lassi Kortela (27 May 2020 08:15 UTC)
Re: SCHEME_PATH and library lookup metadata files Marc Nieper-Wißkirchen (27 May 2020 08:24 UTC)
Re: SCHEME_PATH and library lookup metadata files Lassi Kortela (27 May 2020 09:04 UTC)
Reader flags to indicate different kinds of files Lassi Kortela (27 May 2020 09:14 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (27 May 2020 09:21 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (27 May 2020 09:51 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (27 May 2020 10:21 UTC)
Re: Reader flags to indicate different kinds of files Per Bothner (27 May 2020 14:42 UTC)
Re: Reader flags to indicate different kinds of files John Cowan (27 May 2020 17:46 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (27 May 2020 20:16 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 16:03 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (29 May 2020 17:03 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 17:09 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (29 May 2020 17:52 UTC)
Data vs metadata distinction Lassi Kortela (29 May 2020 17:59 UTC)
Re: Data vs metadata distinction Marc Nieper-Wißkirchen (02 Jun 2020 09:43 UTC)
Re: Reader flags to indicate different kinds of files John Cowan (29 May 2020 17:15 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 17:26 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 17:41 UTC)
Re: Reader flags to indicate different kinds of files John Cowan (29 May 2020 18:04 UTC)
Re: SCHEME_PATH and library lookup metadata files Marc Nieper-Wißkirchen (27 May 2020 09:26 UTC)
Scheme filename extensions Lassi Kortela (27 May 2020 09:40 UTC)
Re: Scheme filename extensions Marc Nieper-Wißkirchen (27 May 2020 09:49 UTC)
Re: Scheme filename extensions Marc Nieper-Wißkirchen (27 May 2020 09:51 UTC)
Re: Scheme filename extensions Lassi Kortela (27 May 2020 10:21 UTC)
Re: Scheme filename extensions Alex Shinn (27 May 2020 09:55 UTC)
Re: Scheme filename extensions Lassi Kortela (27 May 2020 10:30 UTC)
Library lookup metadata file Lassi Kortela (27 May 2020 10:32 UTC)
Re: Scheme filename extensions John Cowan (28 May 2020 17:30 UTC)
Re: define-library-alias Alex Shinn (04 Jun 2020 14:57 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (04 Jun 2020 15:31 UTC)
Re: define-library-alias Marc Feeley (04 Jun 2020 15:37 UTC)
Re: define-library-alias Lassi Kortela (04 Jun 2020 15:39 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (21 Sep 2020 06:13 UTC)
Re: define-library-alias Lassi Kortela (22 Sep 2020 16:05 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (22 Sep 2020 16:13 UTC)
Re: define-library-alias Lassi Kortela (22 Sep 2020 16:41 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (22 Sep 2020 17:13 UTC)

Re: define-library-alias Marc Nieper-Wißkirchen 29 Sep 2020 16:12 UTC

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.