You are reading The New Programming (Part IV): Semantic Unit Architecture (S-Unit), Unit Structure Language. You can leave a comment or trackback this post.
Posted on August 31st, 2006 by Chris.
Categories: Chris, Programming, Semantic Unit Architecture.
“once i stop changing the name, we’ll know i’ve figured out what it is”
So, in my last entry, I drew a nice diagram that purported to explain exactly how this so called Unit Architecture would be constructed; however, I neglected to have real code to back it up.
How would a Unit be coded? Basically, all a Unit has to expose to the outside world is an interface that lists the semantic types it deals with.

The LinkToIMNetwork specifies 4 interfaces and is basically event-driven. If I update my connection settings (i.e. pick a new server or something), the Human unit sends a message that gets received by ConnectionManager. Want to guess what channel that event goes through? Yup, UserInput.
The ConnectionManager then sends a message through the ConnectionSettings channel to LinkToIMNetwork. We can imagine that these messages can either be handled sequentially or concurrently, and it won’t make much of a difference, syntactically speaking.
If we were to pseudocode the UserList unit, we might see something like the following (note: Wordpress can’t indent):
Unit UserList: ---Channels Out: -------UserInterface ---Channels In: -------ListofUsers ------UserInput
In each of the In channels, we’d have to specify how to handle an incoming message. This would be exactly one function, in a language yet to be described. In the out channels, we’d need a way of identifying what sort of semantic data the system would output; in the in channels, we’d need a way of specifying what kinds of semantic data the system would accept (this might allow more than one fit!).
Next episode, we’ll talk about fundamental design concerns that one might call aspects (security, debugging). In Part VI, we’ll talk about the language we might use to handle the incoming messages; its design requirements, and possible fits.
0 comments.
Comments can contain some xhtml. Names and emails are required (emails aren't displayed), url's are optional.