🚀 go-pugleaf

In article <1471@speedy.mcnc.org>, pbr@mcnc.org (Peter Reintjes) writes:
I have not seen XWIP and do not know what its data structures are
like, so I'll have to make some guesses here.

Reintjes considers three choices:

(if-then-else)

    flush_events(Conn, Win) :-
	(   xGetEvent(Conn, Win, [], xExpose, xTrue, xFalse, _) ->
	    flush_events(Conn, Win)
 	;   true
	).

(cut)

    flush_events(Conn, Win) :-
	xGetEvent(Conn, Win, [], xExpose, xTrue, xFalse, _),
	!,
	flush_events(Conn, Win).
    flush_events(_, _).

(repeat-not)

 	repeat,
	    \+ xGetEvent(Conn, Win, [], xExpose, xTrue, xFalse, _),
 	!,

With respect to the choice between (if-then-else) and (cut) he says
> I don't really need a REAL cut when the soft-cut of an
> if-then-else would do just fine.

But the cut in an if-then-else is just as hard a cut as any other.
It has a smaller _scope_ than a plain cut, but it is quite hard.
NU Prolog has
	(if <test> then <when true> else <when false>)
and in addition to delaying as necessary to make the test sound, this
form uses a soft cut, just like
	(cases <test> -> <when true> ; <when false>)
in those versions of C Prolog that have cases/1.

There is a fourth alternative provided in some Prologs:

(iterate)

	iterate(xGetEvent(Conn, Win, [], xExpose, xTrue, xFalse, _))

You'll find it mentioned in the back of Sterling & Shapiro.  It is
sometimes called repeat/1, though that's usually succeed-N-times.
iterate(Goal) is something like
	(L: Goal -> goto L ; true ).

The really clean way of doing this would be to use Logix or Strand and have
the sequence of X events present as a list of records (if you try to look
at the next event and it hasn't happened yet the current process is
suspended until it materialises).  I've seen a windowing system done in
Logix and was instantly converted:  that approach really does work.

It looks as though XWIP is handling X events in much the same way that
Prolog character input handles characters.  If that is so, the best way
to go is to think of that part of your program which is concerned with
"parsing" the event sequence as a finite state machine, and to write the
code whatever way makes the structure of this FSM clearest.

I don't think the choice between (if-then-else) and (cut) in this case is
any big deal; whatever difference there is will be swamped by the cost of
the call to xGetEvent.  Both of them strike me as far clearer than the
(repeat) version.  The apparent straightforwardness of the (repeat) and
(iterate) versions evaporates as soon as you want to skip more than one
type of event.

I suggest that you give serious consideration to developing an FSM notation
which lets you make it really really clear how you are parsing the event
sequence and translate that to Prolog with a preprocessor.  There's a fair
bit in the general computing literature about specifying user interfaces
with this or that generalisation of FSMs.