On Sat, Jan 30, 2010 at 1:04 PM, Michael Wood <esiot...@gmail.com> wrote: > > I have come across references to a "declarative implementation of the > DICOM-3 network protocol" written in Common Lisp and I was wondering > what that means, exactly, and how one would go about doing something > for an arbitrary network protocol.
Maybe you're referring to this document: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.982&rep=rep1&type=pdf I didn't know this (medical) protocol. Anyway, its parsing is driven by some header control data: <<To the PDU parser, this message is simply an uninterpreted stream of bytes. The DICOM Upper-Layer protocol specifies a header for each message encoding the length of the following data field and some flags indicating whether the data field is a command message or a data object (and additionally whether the data field contains the complete object or is a portion of a long data field that has been fragmented into multiple messages). If the message is a command, our system gives the PDU parser pointers to the beginning and end (in the TCP data buffer) of the message. The ruleset contains rules for parsing commands using the same conventions and language as for parsing any other type of PDU. If the message is a data object, however, the buffer (and begin/end pointers) are passed to a different parser. This parser is also data-driven, using the data dictionary to decode arbitrary data objects.>> Each server/client has a state machine which processes those messages: it can guess what to do next by reading the header control data: <<The Prism DICOM code uses a finite state machine to implement the DICOM Upper Layer Protocol, parsing incoming PDUs, and generating outgoing PDUs using a production rule grammar>> <<As the system parses incoming PDUs it extends an environment which stores these variables and their values. The environment is accessible to any operation that needs values of data fields in the decoded PDUs. In Lisp terms, the environment is represented as a nested association list. That is, the entire environment is a list of components.>> It seems to me that there is no automatic parser generation from a grammar: there is a continuous consuming and parsing which check the data with the stored grammar, and after a recognized event it changes the machine's state, producing a proper output. Anyway, very interesting this LISP implementation, thank you. Never heard of such a thing :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
