<https://github.com/schemedoc/guides>

Thanks! Excellent notes all.

> macros.adoc: Gauce supports define-macro too [1]

Added.

> text.md:
>
> perhaps srfi-152 should be mentioned with 13 and 130.

Why not. How widely implemented is SRFI 152? We should probably have a
matrix to show which Scheme comes with which string library (or libraries).

> We could have an alternative "reading from strings" example that uses
> cursors, most underlying procedures are O(1) then

Good idea.

> Also since srfi-135 will be in r7rs-large, maybe worth mentioning
> because it allows O(1) on most everything.

Also a good idea. I was only superficially aware of it.

What's the overall string situation in R7RS-large? The Haskell community
has struggled with juggling different string types. (In their case, they
had lazy strings which are basically linked lists of characters, which
weren't fast enough so they added maybe 2 or 3 other string types.) SRFI
135 looks like the API is disjoint with the ordinary Scheme string API
which would lead Scheme down a similar road.

> I don't know if we could have a document cover ffi basics for
> different schemes? I know they are all different, but having used some
> I think the way they approach ffi is similar (and hopefully we could
> standardize the common parts)

Strongly in favor. Even more generally, An FFI cookbook would be very
useful. In my experience, the basics are reasonably easy to grasp but
the advanced features are complex and often undocumented. Perhaps the
guide could start with simple stuff and move on to advanced concepts?

Have you encountered r6rs-pffi, a portable FFI covering several
implementations? <https://github.com/ktakashi/r6rs-pffi>. IMHO it's a
good start and would be nice to expand upon. Sagittarius Scheme's author
maintains it, but a lot of his Scheme code is portable to other
implementations.

> [1] https://practical-scheme.net/gauche/man/gauche-refe/Traditional-macros.html#Traditional-macros

I gave you write access. Feel free to make changes/additions as you like.

I used AsciiDoc (.adoc) format for the new documents because AsciiDoc
has a standard syntax for tables whereas Markdown does not (it depends
on which Markdown "flavor" you use how tables work, if at all). Editing
locally, `asciidoctor foo.adoc` generates a "foo.html" for preview.