Monday, March 28, 2011

Coding patterns?

I'm wrestling again with what, exactly, I think I mean by "semantic programming". Clearly (sometimes) it's to develop some kind of structure that represents the purpose of program parts, their semantics.

In short, design patterns, except maybe at a very small level.

It's astoundingly hard to define this.

Perl Design Patterns is something along the lines of an attempt to codify this stuff. Kind of. And people talk about more and less Pythonic code - the very idea of programming language "accents" is something along these lines, as the semantic structures behind certain language features can vary broadly.

I want code that understands other code. Just not sure how to get there from here.

Usually, it seems that the notion of "design patterns" is intimately associated in people's minds with object orientation and Gang of Four thinking - which is pretty natural given that the GoF originated the term. But it's clear to me that even the humblest for loop or if embodies a design pattern of its own. That's the level I want to target.

It's what you perceive when you look at some code and say, ok, here's a function, here's a loop, here's a variable. It's all the low-level concepts you use to understand code.

Update: back to the Google well I went, and I found! The key was "loop patterns" - beware; 1997 = broken links! That led me to "Pattern Languages of Programs" = PLoP = ChiliPLoP, which appears to be managed by the Hillside Group. Here's a good place to start. A "pattern language" is not what I think it should be. Honestly, what people call a "pattern language" is more what I'd call a "pattern library", and it essentially describes a bunch of nouns that people use to make sense of things. It's in the right direction, but ... not far enough in the right direction. Yet.

Also: workflow patterns. Really, at one level, Decl is going to be about machine-readable patterns.

No comments:

Post a Comment