"Andrew C. Oliver" wrote: > > That was stefano's recommendation -- I quoted it. The idea is to reduce > multipaths not eliminate them. *shrug* -- I took this to mean that two > commands/elements/syntactical devices that do the same thing but are > syntactically different are generally to be avoided where possible. I > take this as a given.
Yeah, multipaths is when there is more than one way to do it. Perl is a good example, where multipaths are considered a feature, not a bug - this is largely a philosophical question. My point was that declarative semantics tend to increase the number of multipaths, while procedural semantics reduce them. Procedural algorithms define HOW TO SOLVE a problem, so one solution is usually enough, so there will be only one path. Declarative algorithms define WHAT IS the problem and leave the solution to a black box, which basically tries out every path that it can find. > > But if you really want a "next-generation", declarative thing, then you > > have to stop trying to control everything. Declarative concepts mean that > > as an application developer you cannot just say "do this now" at any > > arbitrary point. If you want full control and pre-determined paths, you > > are probably better of with a procedural approach. > > > > Web apps are essentially event driven. SAX is essentially event > driven. Given state and user input as data why is this so different > that it necessitates a procedural approach? Good point. Web apps are driven by users and a declarative approach could for example mean the users generate SAX events (the problem) and you write an XSLT stylesheet (the rules) and the XSLT processor (the black box) processes problem and rules to generate a solution path. However, this is a finite state machine and as such there is no context outside of the current node. Since XSLT does not support backtracking, there is no way to go back once you're committed to a path. Example: Consider a multi-page form, where the user inputs data several times and at last clicks a "process order" button. Suppose that on the last page the user does something that necessitates going back to a page somewhere in the middle of the chain, you're out of luck unless you save state continually, which is cumbersome and error-prone. The usual declarative technique for this is backtracking, i.e. if at some point in the processing chain there is a failure, the processor automatically goes back to the last choice point. So here is what could be done: 1) Implement a truly declarative solution with a finite state machine and backtracking. You don't need to save state or context in this case. 2) Implement a mixture of declarative and procedural algorithms, using the best/worst of both worlds. For example an XSLT stylesheet for the rules (declarative) and a central processor to save state (procedural). 3) Implement a truly procedural solution. I believe the first option is hard to implement and the second one kludgy. cheers, Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
