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 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 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 Marc Nieper-Wißkirchen 30 Sep 2020 07:08 UTC

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
<xxxxxx@nieper-wisskirchen.de>:
>
> 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.