Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site redwood.UUCP Path: utzoo!dciem!nrcaero!pesnta!amdcad!fortune!rhino!redwood!rpw3 From: rpw3@redwood.UUCP (Rob Warnock) Newsgroups: net.lang.c Subject: Re: goto's in 'C' Message-ID: <147@redwood.UUCP> Date: Wed, 30-Jan-85 06:26:26 EST Article-I.D.: redwood.147 Posted: Wed Jan 30 06:26:26 1985 Date-Received: Fri, 1-Feb-85 21:00:53 EST References: <324@harvard.ARPA> Organization: [Consultant], Foster City, CA Lines: 38 +--------------- | | | ...[goto] is extremely useful, though, | | | for 'hardcoding' finite state machines... || Thomas. | | ...The standard technique ... is | | to use a (global) state variable which is really the "PC" of your state | | machine, with assignments to "state" instead of "goto"s... -Rob | I would not refer to a state machine with an explicit state variable | as 'hard coded' (sorry about the fuzzy terminology)... | Thomas. +--------------- Sorry if *I* was confusing... by "hardcoded" I meant the same thing I thought you did: the state transitions are coded into explicit C code, such as "if (...) goto state43" or "if (...) state = STATE43", not whether the "goto" was explicit or implicit in the loop. Both methods have a "goto"; that's what Wulf's "Global Variable Considered Harmful" was pointing out. To me, non-"hardcoded" state machines use a table-lookup method (e.g. Floyd Production Languages) to map {current-state, event} ==> {action, nextstate}, where "action" can produce output and/or push/pop an evaluation stack. The only explicit C code is a small interpreter to obey the table, plus the (small number of fixed) action routines. All of the complexity of the state transitions is explicit in the table. See Gries' book "Compiler Construction For Digital Computers" (John Wiley 1971), Chapter 7: "Production Language" (pp 154-169). Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404 p.s. As a side note, anyone interested in making an improved "connect" function for "cu" or "uucp" or similar tasks might want to consider some form of Production Language for the "syntax analysis" of the dialog. Hint: invent a pseudo-input metaclass "" as one of the possible "inputs".