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)
|
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.