Re: Magic, Oracles, tomatos, and meaning questions not to ask

[Daniel Hagerty <hag @ linnaean . org>]

 >  	So magic is saying:
 > -	The map is not the territory
 > -	Here, use my map and see if that helps
 >
 >  	?

    That could be magic.  What you just said could read to me as
"there is an abstraction underlying my concrete; apply this
abstraction to your concrete and see if it helps" or similar (perhaps
that isn't what I said originally, but it's certainly a useful
expression here).  There will no doubt be other things in the world
that I would consign to "magic" if I wasn't careful.


 >  	So the oracle includes the items below:
 > -	Language X (for want of a better term) which is standard, and
 >  	specifies the config you want
 > -	The implementation of Language X which takes language X and makes
 >  	it happen on hardware a, b, and c
 > -	Our own configuration in language X
 >
 >  	Yes?

    Took several attempts to parse, but if I see what you meant, yes.

    I can't be sure, due to the nature of communication.  In
particular, when we get to the point of needing precision, we need to
examine key words like "language" and "configuration" to give them
"proper" definitions.  "Configuration" is *definitely* a problem word.

 >  	By which you mean that networks don't fit the abstract machine
 > model?

    No; it's more that programming language semantics typically gets
to dismiss a lot of cases we end up caring about as not very
interesting or not worth chasing, whereas we *need* to chase this kind
of stuff a little more closely.

    Also, programming semantics usually don't think of "configure" as
a seperate thing.  It turns out that when you *do*, you discover that
the math problem on your hands was a little bigger than you thought.
"Configure" inherently means closure problems.  If there were no
closure problems, you wouldn't offer "configure".

    You can still do abstract machines, they just need to be pretty
big abstract machines.  And they have to give you tools for dealing
with the closure problem in a way that nothing I've seen really does.

    To build an example of what I mean by the previous, consider the
evil scheme program that asked you what time it was, and its meaning
before: it is actually possible to provide some degree of reasoning
with such a program (short of the point where you wire it up to the
humans and start asking unclosable questions).

    You *want* to be able to express a semantic of scheme that
includes expressing "what will happen when I say '(newline)'?"; the
questions in the realm of "is the output wired up to /dev/null" versus
"is the output going to humans?" need to be seperable from the scheme
semantic (or whatever the foobar is).

    Also, just to point in the direction of some obligatory prior art,
it's not as if math isn't "somewhere" here in the realm of big
systems; see for example "Communicating Sequential Processes" (CSP),
"Calculus of Communicating Systems" (CCS), The Z Specification
Language, Pi calculus, and way too much other stuff that I haven't had
the time to try to digest all of myself either.

 >  	You could instead speak for the fact that some of your content is
 > actual hard content :).  If I don't make the time to grapple with it,
 > that's not your problem :).  But I do when I can.

    Well, I appreciate you taking the effort involved to debug my
horrific content generator -- getting debugging time on this stuff
anywhere has been, um, "difficult".  We're all busy.

 >  	So magic is fine by me, as long as it's *well-defined* magic :).

    As we shall see, getting to "well defined" is complex here: we are
dealing with questions of meaning of language and such.  As you said,
the topic at hand is actual hard content -- there is a great deal of
circularity involved in breaking definitions apart.

 > [snipped lovely example which I think I managed to understand :) ]

    Good.  Knowing that my writing is getting better if I focus on
providing the right examples does help.

 >  	s/abusing/stress-testing/ as well :).

    Yup, yup.

    Now, I'm going to hit the fast forward button a bit here; this
will look a little blurry if only because I'm making this stuff up as
opposed to having been taught it.


Denotational semantic approaches boil down to producing some function
such that

denoted = f(sense)

where "sense" could perhaps be a scheme program like "(set! foo 25)",
or a perl program, or what have you.  Magic is in figuring out the
function f (and thus, denoted) for your language (scheme was intended
to be "easy".  Don't try to figure out f for perl.)

Part of what is implied by the form above is that it is possible for
the semantic to have a platonic, context free meaning.  In the real
world, it almost never works like that.  I can run the "evil scheme
program" that asks about the time, and depending on where I run it,
different things will happen.  If I send it out in mail to you as I
have, that's one thing to the world's state; if I direct its output to
/dev/null, that's another.

"Configuration" is pretty much by definition dealing with questions of
the form

denoted = f(sense, context)

where the concept of context becomes increasingly complicated.  I
could say more on the subject of context, but that would be getting
ahead of myself.

To justify the previous, consider the perl program:

while($ARGV[0]){}

This obviously is a "complete" perl program.  However, its termination
behavior is dependant upon "configuration"; there is state drawn from
the broader world that affects what happens.  Most any kind of
interesting question we're likely to deal with is more likely to be
specified in this form of a context, rather than the other form where
the program is complete.

As we're talking about producing languages (in this list, we're
talking about "Network Management Systems" that can, for example
"rollback") with well defined semantics, you should be noting the
mathematical flames licking at the tension between trying to say

denoted = f(sense)

to our established mathematical tools, but asking questions of the
form

denoted = f(sense, context)

in a fairly general fashion within the smaller expression.

Anyway, much more that could be said to perhaps clarify the above, or
further muddy it with "so what do you do about this problem?".