|
Unix Programming - Applying Minilanguages - Case Study:
Case Study:
fetchmail Run-Control Syntax
See Example8.5 for an example.
Example8.5.Synthetic example of a fetchmailrc.
# Poll this site first each cycle.
poll pop.provider.net proto pop3
user "jsmith" with pass "secret1" is "smith" here
user jones with pass "secret2" is "jjones" here with options keep
# Poll this site second, unless Lord Voldemort zaps us first.
poll billywig.hogwarts.com with proto imap:
user harry_potter with pass "floo" is harry_potter here
# Poll this site third in the cycle.
# Password will be fetched from ~/.netrc
poll mailhost.net with proto imap:
user esr is esr here
This run-control file can be viewed as an imperative
minilanguage. There is an implied flow of execution: cycle through
the list of poll commands repeatedly (sleeping for a while at the end
of each cycle), and for each site entry collect mail for each
associated user in sequence. It is far from being general-purpose;
all it can do is sequence the program's polling behavior.
As with
pic(1),
one could choose to view this minilanguage as either declarations or a
very weak imperative language, and argue endlessly over the
distinction. On the one hand, it has neither conditionals nor
recursion nor loops; in fact, it has no explicit control structures at
all. On the other hand, it does describe actions rather than just
relationships, which distinguishes it from a purely declarative syntax
like Glade GUI descriptions.
Run-control minilanguages for complex programs often straddle
this border. We're making a point of this fact because not having
explicit control structures in an imperative minilanguage can be a
tremendous simplification if the problem domain lets you get away
with it.
One notable feature of .fetchmailrc syntax
is the use of optional noise keywords that are supported simply in
order to make the specifications read a bit more like English. The
‘with’ keywords and single occurrence of
‘options’ in the example aren't actually necessary, but
they help make the declarations easier to read at a glance.
The traditional term for this sort of thing is
syntactic sugar; the maxim that goes with this
is a famous quip that “syntactic sugar causes cancer of the
semicolon”.[88] Indeed, syntactic sugar needs to be used
sparingly lest it obscure more than help.
In Chapter9
we'll see how data-driven programming helps provide an elegant
solution to the problem of editing
fetchmail run-control files through a
GUI.
[an error occurred while processing this directive]
|
