[Asdf-devel] Chipping away at the manual

[Robert P. Goldman]

Faré wrote:
> Dear Robert,
> 
> On Sat, Apr 5, 2014 at 11:31 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
>> If you are interested in the current status, see the 'docs' topic branch.
>>
>> You will see there some work products, particularly a marked up copy of
>> the old manual, with my thoughts about what needs to be done, and a
>> ledger of exported symbols, which should be documented in the manual.
>>
>> Comments and suggestions welcomed.  Patches also welcomed, but for that
>> perhaps it's best you contact me.  I'd be happy to cede parts of the
>> manual to others.
>>
> Thanks a lot for this important documentation work.
> 
> If you want me to document some functions you're not sure you
> understand, please tell me which.
> 
> Should it be a release blocker, though? Lack of documentation for
> exported functions is not a regression.

I will do some triage on the changes needed so that it does not hold up
the release excessively.  I expect to get the manual to a "good enough
for release" state before all of the exported symbols are documented, so
I believe we are on the same page.
> 
> PS: I'm slightly disappointed you felt more comfortable using perl
> rather than CL for those scripts. :-)

I thought you might be!  I know you think that CL should be an
acceptable scripting language.  Why did I still use perl?  I offer these
reflections in the hopes that they will inspire clever new solutions...

1.  Paradoxically, AFAICT perl seems to provide a more REPL-like
experience when scripting than does CL.  It's so much easier to tweak
the perl script, then re-run it.  The CL alternative must be wrapped in
a lot of scaffolding to make it runnable from the command-line -- that
is, command line use seems radically different from in-REPL-use -- so it
doesn't seem obvious to me how to quickly modify a CL script.  I suppose
one could run in the repl and then package for command-line use, but
that is two steps instead of one.

2.  While software purists no doubt deplore them, the implicit variables
that perl offers provide significant terseness in writing filters that
CL simply does not equal.

(iter (for x = (read-line str nil nil))
      (while x) ...)

is a lot more typing than

while (<STR>) { ...}

3.  Regexps:  In perl regexps are in the language.  In CL not only must
we load a special library (a small nuisance), but the regexps are
strings that are not in the language.  This adds much unpleasant
verboseness and quoting.

4.  The relationship between the CL REPL environment and the standard
unix notions of current working directory is annoyingly complex, since
the notion of *default-pathname-defaults* sits in the middle.  Also,
it's a lot easier to use $FindBin::RealBin . "/foo/" than it is to use
something like (or *compile-file-pathname* *load-truename*) and
MERGE-PATHNAMES.  *AND* there's the fraught issue of working that
together with incremental compilation in the REPL.

I'm waiting for a lot more terseness before I give up using perl for
line-based text file processing.

> 
> PPS: my ASDF3 paper was accepted at ELS 2014!
>    https://github.com/fare/asdf3-2013/
> I already improved the paper much from the feedback, but more feedback
> still welcome, especially for the extended version of the paper. Said
> extended version can also provide background information or copy/paste
> material for the manual; conversely, parts of the manual could be
> removed and replaced with references to the paper.

I hope to get a chance to look this over RSN (please lmk what is the
deadline for comments before you have to have final copy in to ELS).
But getting a good enough ASDF manual for release must be my first priority.

best,
r