In-source documentation pre-SRFI draft #2 Antero Mejr (28 May 2024 05:35 UTC)
Re: In-source documentation pre-SRFI draft #2 Wolfgang Corcoran-Mathe (28 May 2024 23:13 UTC)
Re: In-source documentation pre-SRFI draft #2 Antero Mejr (29 May 2024 00:12 UTC)
Re: In-source documentation pre-SRFI draft #2 Arthur A. Gleckler (29 May 2024 01:51 UTC)
Re: In-source documentation pre-SRFI draft #2 Antero Mejr (29 May 2024 02:10 UTC)
Re: In-source documentation pre-SRFI draft #2 Arthur A. Gleckler (29 May 2024 02:16 UTC)
Re: In-source documentation pre-SRFI draft #2 Philip McGrath (29 May 2024 19:19 UTC)
Re: In-source documentation pre-SRFI draft #2 Antero Mejr (29 May 2024 23:37 UTC)
Re: In-source documentation pre-SRFI draft #2 Antero Mejr (29 May 2024 23:41 UTC)
Re: In-source documentation pre-SRFI draft #2 Wolfgang Corcoran-Mathe (30 May 2024 03:02 UTC)

In-source documentation pre-SRFI draft #2 Antero Mejr 28 May 2024 05:34 UTC

I updated the in-source documentation pre-SRFI based on feedback here
and the discussion on Codeberg. It is available here:
https://github.com/pre-srfi/in-source-documentation

Changes in v2 include:
1. Use #|* ... *|#  and #|? ... ?|# for backwards compatibility.
2. Specify documentation-format parameter, that controls how
   documentation text is exported.
3. Added a plain-text exporter that can document procedures, lambdas,
   records, identifiers, and libraries. You can try it out on
   the doc-lib.sld file, which has in-source documentation.
4. Various updates to specification and library, mostly to ensure
   non-interference with #| block comments.
5. Switched the meaning of #|* (now means attached), and #|? (now means
   unattached), for aesthetic reasons.

As mentioned before, it will be impossible to come up with a solution
everyone 100% agrees with. Some people prefer documentation as part of
top-level define forms, others like attaching them to identifiers, and
some people want to document at the identifier level using inline
comments. And others prefer a inline, sexp-based format.

I think the comments method provides a acceptable compromise. If you
want, your implementation's exporter can support extracting
documentation only from top-level identifiers. I also adjusted the
specification so implementations can support this:

```
(define (add-one x)
  #|* Add one to x. *|#
  (+ x 1))
```

The documentation-format parameter is intentionally lightly specified,
but I put some notes about its capabilities in doc-exporter.scm, copied
below:

Exporter programs can parameterize documentation-format based on the
value of a CLI flag. Exporter libraries can then use the parameterized
value. documentation-format can also be parameterized by code, by a
special string inside the documentation text, or be inferred from the
documentation text.

I hope that is an acceptable compromise for specifying the markup format
of a documentation comment, without needing to add new lexical syntax,
which this version does not do.