Some thoughts circling back to semantic programming now

OK. So this declarative style of programming can be seen as the systematic laying out of the semantic structure of the program at the same time we are building the code. I'm a little worried that this structure is still very thin (that is, the extremely complex ramifications of meaning that come along with human understanding of a program are missing in this structure), but it's still a beginning.

Let's consider this: we could see the Class::Declarative structure as a sort of prototype. But knowing sufficient amounts of semantics for any given class, we could take a working structure and "compile" it into a pure-Perl structure that doesn't depend on Class::Declarative at all. In fact, we could compile it into any language for which we knew how to express the semantics of the structure.

This is important. This is what we will end up doing much, much farther down the road.

As a more proximate goal, this is what I was fumbling towards in January. I read January's posts and they seem sort of naive. I think that bodes well.

Let's posit a set of semantics that talks about databases, PHP code, Web pages, and AJAX. That's what sproggler is talking about. This declarative-plus-semantic framework would be the backbone of that system, and it could express itself using templates of some kind.

These templates are symbolic units. Remember symbolic units? They connect semantic units (the nodes in a Class::Declarative structure) with syntactic units (the pieces of code we compile), and they are mediated by templates of varying degrees of abstraction. So at some point in the very near future, we're going to want to think hard about them.

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.)