zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk (Zsh hackers list)
Subject: Thoughts on self-documenting functions
Date: Wed, 20 Sep 2000 14:33:14 +0000	[thread overview]
Message-ID: <1000920143315.ZM31433@candle.brasslantern.com> (raw)
In-Reply-To: <0G140090FMIN8S@la-la.cambridgesiliconradio.com>

On Sep 19, 10:04am, Peter Stephenson wrote:
} Subject: Re: generals observations about completion system
}
} Bart wrote:
} > It does tend to be easier to add new completion functions than it is to
} > document them.
} 
} [...] self-documenting functions with something
} like pod, except using shell functions to strip out the bits and turn them
} into yodl, should be pretty easy.  Adding comments is usually much easier
} than fiddling with the full documentation.

I actually have a bit of experience with this, and I have reservations
about how effective it will be.

In Z-Mail, which has a shell-like scripting language with "#...\n"
comments, each function may contain a block that looks like

	#%
	# Documentation goes here
	# across several lines if
	# necessary
	#%

The zscript parser grabs those comments and uses them to generate on-line
help in the GUI.  Also, if you run `func -?' the documentation block is
printed (with the leading '# ' stripped from each line) instead of
executing the real function body.

POD's biggest advantage over this scheme is that you don't have to put a
comment character on every line, which makes editing the doc a lot easier
should you ever need to change it.  The value of that convenience should
not be underestimated; zmail was heavily customized through zscript by
each of several organizations that bought it, but I never heard of anyone
who made use of this inline doc feature. Conversely, the use of POD is
quite common.

In any case, in both zscript and POD, the support for stripping the doc
out of the function is built in to the parser.  Since I don't think PWS
is suggesting we diddle with zsh's parser, we can't avoid using comments
(any other approach, e.g., here-documents, would store the documentation
as part of the function definition when it gets loaded).  That's my first
reservation.

The second is with the idea of "generating yodl" from the text in the
comment.  That seems doomed from the start; yodl's designed to be the
source language, not the generated one, and consequently has a whole
syntactic menagerie that can't be inferred from un-marked-up text, which
is all we can expect anyone to write in a shell script comment -- no one
will want to document their functions twice, so whatever form we choose
ought to be plainly readable without preprocessing.

One thought that I had is to put the documentation into its own function,
which is then unfunction'd after the whole file has been autoloaded.  So
each file _xxx would look something like:

    _xxx_doc () {
	some sort of documentation format
    }

    _xxx () {
        the actual function
    }

    unfunction _xxx_doc
    _xxx "$@"

This way, the doc format wouldn't have to be a comment, but would still
get flushed out of zsh's memory after the file is loaded.  On the other
hand, I think redefining _xxx that way prevents taking full advantage of
memory-mapped .zwc files, which is also undesirable.  However, using a
function might let us do something clever with shell expansions to mark
up the documentation for conversion to yodl.

Anyway, no conclusions yet, just musings.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


  parent reply	other threads:[~2000-09-20 14:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-17 23:33 generals observations about completion system E. Jay Berkenbilt
2000-09-19  4:59 ` Bart Schaefer
2000-09-19  9:04   ` Peter Stephenson
2000-09-19 15:19     ` Bart Schaefer
2000-09-19 15:51       ` Clint Adams
2000-09-20 14:33     ` Bart Schaefer [this message]
2000-10-04  9:41 Thoughts on self-documenting functions Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1000920143315.ZM31433@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).