> Our approach is inherently "network" specific (i mean, "my network"
> versus "your network"), because the semantics of this network are tied
> up in the syntax of our language of abstraction. When you solve the
> problem, some of the lessons learned may be useful for me, but some
> will undoubtedly be overly simplistic or not complex enough to avoid
> unwanted looping or halting states.
You seem to misunderstand the actual scope of my hammer, but then,
I haven't shown you my hammer, so this is obviously my error.
I'm not actually coming at this from network configuration land;
I'm coming from some place that is somewhat harder in one key aspect:
non-commodity software staging. Networks don't change vocabulary as
often as bleeding edge new software does. This change stresses
configuration generation concepts enormously. I had to go back to the
blackboard for a little bit in order to think about what's going on
with software staging. But anyway...
What I would like to give you should have "well formed" semantics
where termination of the base cases is promised by the semantic. If I
can't deliver on this, I have nothing.
Given such a promise, nothing prevents you from mis-expressing
your domain as non-terminating in all or only some conditions.
Programming is programming, as always.
I would like to give you all is a means of description of
semantics and knowledge "issues". Solutions to my own problem
requires such a means.
However, keep in mind that my code is a very small thing; it
isolates a key pattern that will always be, but your problem is still
your own. I just give you a framework for the common pattern your
problem always falls into and provide means to relate how your program
interacts with the broader world.
As network operators, you want something that deals in your own
domain; this code is not in that domain. You make the domain of
networks out of other domains, all of which eventually come down to
the domain of domains.
What I have in hand is something like a recursion combinator.
It's not a recursion combinator, in that a recursion combinator
typically enables recursion and no more. This combinator mixes the
recursion concept with a multiplexing concept.
Logical "today"'s project (which will probably not happen today)
is to produce a pair of mutually recursive functions that express this
mutual recursion within my framework. Producing this is likely to
exercise the multiplexing portion of the combinator in some fashion or
another. The only example I've had time to write at this layer only
exercises recursion.
Obviously, this seems to have little to do with "can I program my
cisco router with that?". Like I said, there was a bit of going back
to the blackboard involved.
Code, examples, prior art refrences, etc, etc available upon
request, as long as you keep in mind that it's all a work in progress,
and it's very early in the game.
I'll mention that asking me "how would you reason with...?" sounds
like a fun game to play, and would be helpful for me in finding many
people's different examples.
Follow-Ups:
References:
|
|
