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 Wolfgang Corcoran-Mathe 28 May 2024 23:13 UTC

Hi Antero,

Thanks for your work on this. 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 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.

Wolfgang

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