More thoughts on tasks

So here I am, doing some sysadmin stuff for Techspex, and thinking about how really, a task is the semantic unit of action. That is to say, when I think of things I have to do to get something done (e.g. install Wordpress - this requires upgrade of MySQL, and that requires a dump to be done, etc.) each of those verbs denotes a task.

The definition of those tasks at the human level might include snippets of shell code to execute the commands required, it might refer to documentation pages, and so on. All those things involve the semantic environment that a human requires to make sense of the actions being done and to be sure that they're reasonably correct.

That's really the essence of a semantic approach. How can I get from a high-level description of a set of tasks to be performed to the specific code required to perform them? That's what programming is, of course. That's where I need to go.

Another consideration: there are certain short lists and items of data that describe a given sysadmin environment - host names, IP addresses, directories, what have you. If these are assigned string variable names, you haven't gained anything; you still have to remember those naming strings. Instead, you need some kind of semantic note-taking structure that can store information of that nature in such a way that it can be retrieved in a purpose-oriented manner.

And that ties back into Code Bubbles, really: the point of that IDE is to arrange a working set of information being used to address a given ... task. See? See how this all makes sense?

Going back even further into my past, I need to resurrect my notion of the semantic database or Lexicon. That's where items of this nature would be grouped. A given context might be "sysadmin work for Techspex". That would be a subcontext of "sysadmin work", and that supercontext would provide useful things to know about any sysadmin environment, such as the hostname, etc. (This could be a checklist of things to discover about a new environment, say.)

But the point there is that the information in that context would be indexed with things like what a hostname is, how it can be determined, how to choose one for a new machine, I don't know - all the things that represent what a system administrator knows. A semantic domain indeed - far more semantically oriented than the Decl domains I keep proposing right and left. Eventually those Decl domains will grow into this concept, but that's still a ways off.

But system administration is a domain where it may make sense to explore it. If only I had more of it to do. (Except that's a great way to lose sleep and hair.)

The semantic and syntactic poles

A symbolic unit encodes a symbolic relationship between a concept (loosely) and its syntactic expression. I'd argue, actually, that a symbolic unit easily generalizes to any symbolic relationship, but the point in our particular case is that the symbolic unit mediates between meaning and expression.

A loop expression

for i=0 to 9 {

...

}

when encountered by an interpreter will cause repeated execution of the loop block and incrementing of the counter. We know that. That, to a human programmer, is the meaning of the loop construct (loosely). The computer, however, can't be said to "know" this except in the narrow sense that programmers use when speaking of software. The computer simply does the right thing. (It is tempting to think of the computer as understanding code because code is expressed in something like the language we use to talk about it - but the computer executing a loop no more understands it than a gearbox understands gear ratios.)

What semantic programming brings to the table is simply that: explicitly associating meaning with program constructs. In this view, the syntactic expression for a loop is the syntactic pole of a symbolic unit whose semantic pole points to the concept of "loop" - or, more precisely, whatever kind of loop it is. And the meaning of that unit involves the more abstract "loop".

This can be applied in either direction. When programming, the system would express the loop in terms of that (or another) symbolic unit. However, the system should be able to parse and understand (let's call it "comprehend" to set it slightly apart from human understanding) existing syntactic structures - we programmers do that all the time, after all. Given code, the system should be able to recreate some of the thinking of the programmer who wrote it.

In natural language, words and phrases in the lexicon work in this same way. We'll construct a syntactic lexicon for each programming language the system will work with, along with specialty project-specific lexicons for natural-language domains (remember - comments are grist for the semantic mill, if the system can manage to comprehend them). (And it should most certainly write comments, when it comes to that.)