From mboxrd@z Thu Jan  1 00:00:00 1970
Subject: Re: [9fans] OT: small xml parser found!
From: John Murdie <john@cs.york.ac.uk>
To: 9fans@cse.psu.edu
Cc: john@cs.york.ac.uk
In-Reply-To: <08c25b30f091062677fe829b999b39cf@plan9.escet.urjc.es>
References: <08c25b30f091062677fe829b999b39cf@plan9.escet.urjc.es>
Content-Type: text/plain; charset=ISO-8859-1
Message-Id: <1077206087.1790.18.camel@pc118>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Feb 2004 15:54:47 +0000
Topicbox-Message-UUID: ee22b44c-eacc-11e9-9e20-41e7f4b1d025

On Thu, 2004-02-19 at 15:27, Gorka Guardiola M=C3=C2=BAzquiz wrote:
> >> Why isn't Expat suitable?=20
> >=20
> > callbacks are horrible.
>=20
> Reasons?.

Callback-(handler)s are interrupt-(handler)s - remember Dijkstra's
original (1962?) dismissal of the idea of writing programs with
interrupt handlers instead of processes as first-class entities. (From
his paper on The THE Multiprogramming System? I forget the reference.)

I'm fond of showing people a paper by a certain D. W. Jones from SIGPLAN
Notices that I think has some bearing on the matter; systems of
interrupt handlers have to maintain explicit state variables, whereas
much equivalent systems coded with processes seem to have fewer, and
Jones simple little paper contrasts the shallow control structures of
each:

> %T How (not) to code a finite state machine
> %X The standard advice for those coding a finite state machine is to
> use a while loop, a case statement, and a state variable. This is
> usually bad advice! The reasons for this are explored and better
> advice is formulated. The examples presented are an interesting test
> of software complexity metrics. All have the same deep control
> structure but they have different shallow control structures
> %K programming, finite state machine, while loop, case statement,
> state variable, software complexity metrics, deep control structure,
> shallow control structures
> %O SIGPLAN Not. (USA)
> %J SIGPLAN Notices
> %A Jones, D.W.
> %V 23
> %N 8
> %V A01
> %P 19-22
> %D Aug. 1988

See some seminar notes "Why threads are a bad idea" (he means processes,
not any particular formulation of threads, if I remember rightly) from
USENIX 1996 by John Ousterhout offer an opposing view, some of which I
can see the sense of http://home.pacbell.net/ouster/threads.pdf.

John A. Murdie
Department of Computer Science
University of York