r7rs/FOUNDATIONS.txt

                                                     -*- mode: org -*-

IMPORTANT! Not everything here will definitely end up in the
Foundations. This is mostly an agenda for discussion, not a table of
contents.

** The Macrological Fascicle

- Things voted in on the Yellow Ballot:
  - syntax-case
  - identifier-syntax
  - Identifier properties
  - Syntax parameters
  - splicing-let-syntax
  - Everything macro-related from the small report (let-syntax
    without splicing, define-syntax, syntax-rules, ...)
- R6RS-style expansion process defined for library and procedure
  bodies. Program bodies will be dealt with in Bibliothecarial
- Implicit phasing defined
  - meta/begin-for-syntax was planned but postponed due to semantic
    difficulties
- A non-normative appendix will show how to get explicit renaming
  (and possibly syntactic closures) back out of a system based on
  syntax objects

** The Procedural Fascicle

- Syntax and procedures from the small language which builds up a
  basic program or library, mainly that which will not be affected any
  major changes coming up in the Foundations Report
  - If it’s in the small report and doesn’t seem to be listed under
    any of the other fascicles, it’ll probably be here
  - SRFI 219 (define for higher-order procedures) [YELLOW]
  - SRFI 31 (rec, or possibly put this in the Batteries) [YELLOW]
  - independently, from SFRI 236
  - begin0, from Racket and the R6RS operational semantics (i.e. CL
    prog1; technically could be in the Batteries, but the idea is to
    save the cost of consing up a list in the case that the first
    form in the body returns multiple values)
  - alias, from SRFI 212, possibly called define-alias [YELLOW]
- Stygian Blue ballot issues:
  - Expressions and definitions in any order, straw poll (SRFI
    245/251)

** The Valued Fascicle

- The basic data types of the small language will be defined with
  the procedures that work on them, and some new types which have
  lexical syntax:
  - The numeric tower (all required [RED]) and numerical operations
    including the (scheme division) library
    - SRFI 169 (underscores in numbers)
    - The contradiction in the lexical syntax of numbers between
      sections 2.1 and 7.1.1 in the small language report needs to
      be resolved.
      - There is as yet no definitive word from WG1, but they seem to
        favour 2.1, but with an explicit appeal to extensibility of
        the numeric syntax. So Large could choose 7.1.1 without
        formally breaking the charter, even if this feels sketchy.
    - Decide what to do about R6RS explicit mantissa width syntax
      (#191)
    - Bitwise operations (SRFI 151), in supplemental library
  - Booleans (no changes at all)
  - Pairs and lists (cons, car, cdr through map and for-each): no
    major changes from small; the majority of these procedures will
    be in the Batteries
    - memp from the R6RS list library?
  - Symbols (waiting for WCM’s uninterned symbols SRFI, which will
    probably be ballotted)
  - Characters (add SRFI 129, require full Unicode, otherwise no
    changes)
  - Strings (require full Unicode including nulls in strings; add SRFI
    129; no major additions to the procedure library — most things
    will be in the Batteries. string-ref performance guarantee ballot,
    see below)
  - Vectors (probably no changes at all, SRFI 133 in the Batteries)
  - Bytevectors (maybe adding the utf16 and utf32 procedures, and
    adding safety guarantees to all the encoding conversion
    procedures)
    - SRFI 207 (string-like notation, but not procedures — ballot)
  - Homogeneous numeric vectors from SRFI 160: base library only,
    possibly extended only with the procs that bytevectors have in
    small; rest of the libraries in Batteries [RED]
  - Bitvectors from SRFI 178 (only if with lexical syntax, otherwise
    Batteries — ballot?)
  - Multidimensional arrays (SRFI 231, base library: [[https://github.com/johnwcowan/r7rs-work/blob/master/ArrayBase.md][ArrayBase]]) — only
    if with lexical syntax, otherwise all in Batteries — ballot?
- All non-! procedures explicitly defined as continuation-safe (by a
  blanket statement to this effect)
- Stygian Blue ballot issues:
  - Are literal values enforcedly immutable? (By implication, can we
    safely assume impls know how to enforce immutability of e.g.
    pairs?)
  - SRFI 207 notation
  - string-ref performance guarantee

** The Erroneous Fascicle

This fascicle and everything after it lies beyond the current planning
horizon, in terms of what’s definitely going to be/not be in the
fascicles, what we have consensus for, what needs to be voted on, etc.

- The R6RS condition hierarchy will be added to the small language
  - Until the records fascicle is written, it will be undefined
    whether conditions are records or not
- SRFI 255 restarters — consensus or ballot
- Misc. things, possibly to be voted on:
  - assert from R6RS
  - assume from SRFI 145
- A vote will definitely be held on the extensibility of R7RS Large
  (e.g. whether we should adopt the R6RS stance that implementations
  are not allowed to add functionality in cases which, according to
  the standard, are errors)
  - Adopt the CL stance? (Extensions are allowed, must be
    implementation-specified, some basic limitations on what they’re
    allowed to do)
    - Ban on catastrophic failure on (most? all?) ‘is an error’ cases
      (allowed by R7RS small): impls must either signal an exception
      or (if allowed) return a value corresponding to a documented
      extension
      - R6RS ‘safety’, modified for practicality
  - Encourage impls to provide a linter which warns about use of
    non-portable extensions to the standard libraries?

** The Bibliothecarial Fascicle

- define-library from R7RS small will be combined with library from
  R6RS
  - Import and export specs in both will be identical
  - Phasing information from R6RS will be syntactically valid for
    hysterical raisins, but ignored in all cases, because we have
    implicit phasing
    - Possibly implementations will be requested to issue a warning
      when they encounter phasing info in import specs, explaining
      that they do nothing
  - The question of library versioning, and alternative solutions to
    the problems it solves, will be considered
    - If R6RS-style versioning is rejected, the version spec syntax
      will probably still be valid but officially meaningless, like
      the phasing spec syntax, for compatibility
- MNW straw proposal: ‘Chez-style modules’ (needs a SRFI; N = at least
  2, Chez and Loko; but probably needs an implementer ballot)
- Also program semantics
  - Resolve the ambiguity in R7RS small program imports
    - Define ‘interactive mode’ i.e. REPL semantics (semantics of
      eval), closely derived from R7RS small program semantics
    - Define R7RS small program semantics in terms of eval semantics?
  - Define the relationship between SRFIs 22 and 138 and the concept
    of a top-level program (non-normative?)

** The Flow-Controlling Fascicle

- Context: Dybvig, Peyton Jones, & Sabry (2007) show that the ⁻Ƒ⁻
  operator is the most general of known delimited control operators,
  can be used to implement other popular ones, and can be
  implemented by a minor variant on a standard CPS transform, among
  other possible strategies:
  <https://cs.indiana.edu/~dyb/pubs/monadicDC.pdf>
  - SRFI 226 provides the ⁻Ƒ⁻ operator and has a sample
    implementation requiring comparatively minimal support from the
    underlying Scheme runtime
  - The popular shift/reset operators correspond to ⁺Ƒ⁺ in this
    model, can be implemented in terms of ⁻Ƒ⁻, but in their most
    common form lack named prompts; they can be adapted for this,
    however, and SRFI 226 also provides versions which do this
- Context: Flatt & Dybvig (2020) introduce continuation marks for
  dynamic binding and context inspection with proper tail calls and
  delimited continuations, and discuss their implementation:
  <https://www-old.cs.utah.edu/plt/publications/pldi20-fd.pdf>
- SRFI 226 will be broken up into its constituent parts and
  decisions made about each:
  - Low-level delimited continuations (sections ‘Continuation
    Prompts’, ‘Continuations’, ‘Inspection’, and ‘Initial
    Continuations’)
    - Possibly cut this down radically (alternative API: Guile)
  - +High-level delimited continuations+ This section belongs to the
    Batteries if accepted!
    - Alternative proposal: SRFI 248
  - Continuation marks (section ‘Continuation Marks’, ‘Parameter
    Objects’, ‘Promises’)
    - Do not have N=3 yet (N=1 by the strict definition that discounts
      non-independent impls!)
    - MNW decided to adopt the Chez separation between ‘parameters’
      and ‘thread parameters’, which is not small-compatible, so this
      may be out of scope
  - Fluids (may go into the Batteries if accepted, as they are
    merely syntactic sugar over parameter objects)
  - Threads (only the sections which supersede SRFI 18): consider
    whether to make threads mandatory (may be impossible or very
    tricky in some environments) or optional
    - Atomic operations (SRFI 230)
      - Minimal atomics: add box-cas! to boxes in the Valued Fascicle?
  - Thread-locals
  - Thread interrupts
- Making SRFI 226 more approachable: don’t specify the type of a
  prompt tag, rename continuation-prompt to just prompt, find a short
  name for call-with-composable-continuation, ...

** The Record-Winning Fascicle

The only record I expect it to win is for how heated the discussion
will be.

- Context:
  - R6RS defined a record system which has been criticized for its
    complex interface
  - SRFIs 237 and 240 compatibly simplify this interface and specify
    one define-record-type form which can be used either in the
    style of R7RS small (i.e. the popular SRFI 9) or in the style of
    R6RS
  - SRFI 99 extended SRFI 9 with single inheritance and the ability
    to auto-generate the names of, or suppress the definition of,
    accessors, mutators, and predicates
  - SRFIs 136/150 reduced the syntax of SRFI 99 to remove the
    ability to auto-generate field names, but also made changes to
    match an assumption that R7RS field names are identifiers, not
    symbols
  Note that only the syntactic layers of the respective proposals
  are really being considered here; the procedural and inspection
  layers are another issue which aren’t considered yet in this
  agenda.
- +Decide on the field names are identifiers vs symbols question+
  - This entire ‘issue’ is a red herring, and only applies to SRFI 99.
    Field names in R6RS are informative/documentation information only
    (don’t even have to be unique), and their unique identifiers are
    exact integer indexes; SRFI 99 decided to make them more
    significant, which leads to this phony issue.
- A ballot will probably be held on the following questions (exact
  wording far from final):
  1. Fascicles of the Foundations report have thus far been written
     assuming that an implementation of R7RS may also wish to
     support R6RS, and that in such implementations, R7RS programs
     should be able to make use of R6RS libraries as if they were
     native R7RS libraries and vice versa. Should this be extended
     such that all R7RS implementations are also required to
     implement the libraries of R6RS as written? (This will
     incorporate SRFIs 237 and 240 into the R7RS foundations.)
  2. If you answered ‘no’ to question 1, should R7RS Large
     incorporate a record system substantially similar to, and
     compatible with, that of R6RS? (This will also incorporate
     SRFIs 237 and 240 into the R7RS foundations.)
  3. If you answered ‘no’ to question 1 and 2, should R7RS Large add
     single inheritance to the record system provided by R7RS small,
     even if it may not be possible to prevent subtyping if there is
     a means (possibly implementation specific) of procedural record
     inspection? (This will add the syntax of SRFI 99/136/150 into
     the foundations.)
  These have the following consequences for other parts of the
  reports:
  - If the answer to all three is ‘no’, the status quo from R7RS
    small is retained. It remains undefined whether condition types
    are record types, unless the implementation also supports R6RS.
  - If option 2 or 3 wins, condition types become record types. SRFI
    222 may also be incorporated so that there are compound records
    as well as compound conditions.
  - If option 1 wins, the overall division of the foundations into
    libraries will more closely resemble R6RS. What exactly that
    looks like (in re the ‘rnrs’ and ‘scheme’ namespaces in
    particular) will depend on what we decide about library
    versioning in that ballot.
  There will probably be further questions about a procedural layer
  and an inspection layer.
- Tagged procedures or applicable record types. Solutions in
  increasing order of maximality:
  - Absolute minimal solution: provide a make-procedure form which
    simply guarantees a unique location tag for the procedure it is
    given as an argument
  - Slightly less minimal but not type safe: SRFI 219
  - Type-safe version of SRFI 219, see comment to #195:
    - ~(define-tagged-procedure-protocol <<key identifier>> <<accessor
      procedure identifier>> <<predicate procedure identifier>>)~,
      generative
    - ~(lambda/tag <<key expression>> <<value expression>> <<formals>>
      <<body>>)~
  - Full-blown applicable records
- Custom ports and character encodings, ideally equipotent with R6RS
  - SRFI 181 is essentially R6RSbis on this issue
  - dpk’s faceted ports pre-SRFI
  - or sham1’s ‘port properties’ which is less radical than faceted
    ports
- Storage management features:
  - A solution for eq?-based hashing
    - just provide eq-hash and require implementations to find some
      way to make it stable
    - ephemeron-keyed tables
    - transport guardians (SRFI 254)
    - strong eq-hash tables as primitives
  - Finalization (guardians, SRFI 254)
  - Ephemerons (SRFI 124, potentially superseded by 254)
    - What accommodations to make for implementations on runtimes
      which might only be able to implement them as weak pairs, or
      even not at all?
    - Consider dropping reference-barrier on the basis that any
      implementation smart enough to do the optimization MNW was
      concerned about should also be smart enough to mark any
      variables created from ephemeron keys as not able to be
      optimized in this way

At that point the Foundations report is done and dusted in terms of
content. The remaining task would be to re-arrange all the text in the
fascicles into a single finished report, which would mostly be a
copy-and-paste task followed by careful reading to make sure
everything makes sense together. The non-portable features still to be
added to the Large language are I/O and other operating system calls
(previously considered the responsibility of Committee E, which never
managed to find a chair). This might then in practice be incorporated
into the Foundations report, notwithstanding the original plan to make
them their own report.