>     I intensely dislike that kind of magic argument parsing :)
>
> I understand your concerns.

Thanks for listening to them.

> Well, put the optional arguments at the
> end, then, or if that still bothers you, make the parameters into a
> single argument.

I agree it's nicest to have the optional mapfun and accumulator
arguments last, because then we can omit them without even passing a #f
placeholder in their place.

If the SQL statement is given as (cons string params) or (sql-prepare
string params) then it can always be a single argument, simplifying the
arg list but adding an extra data structure.

If we also accept a lone string (in place of a list starting with a
string) for simple queries that need no parameters, the complexity of
the inner data structure can be omitted in those cases.

Does this seem reasonable?

A further problem (which you already pointed out) is named vs positional
SQL parameters. IIRC it's even possible to mix both kinds in the same
prepared statement. In Lisps we may be able to solve this by using a
list where pairs are treated as association pairs and non-pairs are
treated as positional values. However, I haven't tried any examples.

> (I really do need to settle down and write up
> Dicitionaries.md better so we can get it implemented and stop fussing
> about what kind of dictionary procedures accept: the answer will be "Any
> kind!")

I've been thinking about this. Sequences can be thought of as
dictionaries with natural numbers (indexes) as keys. Some kind of
general interface for traversing nested collections in this manner would
be useful. Maybe the dictionary SRFI should be something even more general.

> I ran through 1600+ man pages and found only a few examples of optional
> arguments to options.  For example, "vim -q errorfile" means to start
> vim in quick-fix mode, where errorfile is a file containing errors to be
> fixed (more generally, lines to be changed).  Simple "vim -q" looks for
> the error file in a system-dependent place, typically "errors.err".

Wow, that's a huge run. Did you grep for particular nroff markup?

Good to hear that there are not many instances of it in the wild. It
makes it hard to write reliable shell scripts when you don't know
whether something's going to be parsed as an option or an argument. The
"--" sentinel argument helps, but it stops _all_ flag processing.

>     For example closures, S-expressions, and GC, none of which belong in
>     the
>     Unix pantheon :)
>
> True in specifics, but not in overall worldview.  Bash is an impure
> functional programming language, much like Scheme: it's no accident that
> scsh exists.  It's just that people tend to write it imperatively, not
> exploiting conditional expressions in pipelines, e.g.  That "worse is
> better" paper is basically a battle between two groups that disagree
> only on details.

While Unix people certainly love rapid prototyping, I feel there's a
glass ceiling of generality, integration, and simplicity that is never
broken. Unix advocates pay lip service to those virtues, but anything
taking them to their logical conclusion gets laughed out of the room.

For example Unix people love structured text formats, but once a format
is as simple and general as S-expressions, they don't want it. It has to
have arbitrary restrictions or irregularities like YAML, TOML, or one of
the Yacc contraptions they keep rigging up for individual applications.
Likewise, using similar syntax and semantics for all their programming
languages is frowned upon and different-looking languages with random
restrictions and incompatibilities proliferate. Unix people like macros,
but as soon as the macros get as simple and general as the ones in Lisp,
nobody wants them.

I never understood why this glass ceiling is there. From a Lisp-first
perspective, Unix looks like any time something is too good, it gets
ostracized, laughed at and maligned. It's like there's some central
truth that we're always going towards but are not supposed to get too
close to. You have to make things artificially less general and more
complicated in order to gain mindshare. And re-introduce a similar thing
from scratch every decade (Perl -> Python -> Ruby -> Node.js etc.)

The really interesting question is, does Lisp have a similar glass
ceiling? What ideas for increased generality, integration, and
simplicity are laughed out of Lisp communities?