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)

Re: In-source documentation pre-SRFI draft #2 Antero Mejr 29 May 2024 00:12 UTC

Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> writes:

> I’ve come to prefer the idea of
> documentation as a first-class identifier property rather than a
> “magic comment”, but I think this proposal might be able to bridge the
> two approaches. I also very much appreciate the “light” specification
> of the documentation format feature.

I think the two approaches are compatible: for implementations that
support identifier properties, attached documentation comments can be
parsed and put into an identifier property.

> I had difficulty with the notion of “attached” documentation as
> you’ve described it. What does it mean for ‘make-documentation’
> to take “an expression” as its *content* argument? In your example,
> you pass it the value ‘(+ 3 2), but the idea, of course, is to attach
> documentation to expressions, not values. (In other words, shouldn’t
> ‘documentation-object’ return a syntax object?) Maybe I’m missing
> something about how you’re expected to invoke these procedures.

The idea is to call (read-doc) to extract documentation from a
file/port, similar to how a REPL would call (read). When there are no
documentation comments, (read-doc) is the same as (read). When there
are, instead of returning an expression/object, (read-doc) returns a
documentation record, which wraps the expression/object along with the
text of the associated (or "attached") documentation comment. The
documentation comment must be "adjacent" to the expression/object in the
source code. Typically documentation comments would be placed
immediately before the expression, but I left the interpretation of
"adjacent" up to the implementation, based on feedback I received
earlier.

The documentation-content field is an unevaluated expression or readable
Scheme object, since R7RS-small does not have #'() syntax objects.

I think the code of doc-exporter.scm is a good example of how it is
intended to be used: it applies read-doc to a .scm/.sld file, and
exports formatted documentation to .txt files. Or maybe this snippet can
explain better:

```
(define code-from-scm-file "\
#|* Import the base and write libraries. *|#
(import (scheme base) (scheme write))

;; This expression has no documentation.
(define result (+ 3 2))

#|* Display the result of 3+2. *|#
(display result)

#|? Note: the answer should be five. ?|#
")

(define port (open-input-string code-from-scm-file))

(read-doc port)
=> documentation record
     attached = #t
     text = " Import the base and write libraries. "
     content = (import (scheme base) (scheme write))

(read-doc port)
=> (define result (+ 3 2))

(read-doc port)
=> documentation record
     attached = #t
     text = "  Display the result of 3+2. "
     content = (display result)

(read-doc port)
=> documentation record
     attached = #f
     text = "   Note: the answer should be five. "
     content = #f

(read-doc port)
=> eof-object
```