A case against standards

[Armin Rigo]

Hello Ilmari,

On Thu, Oct 16, 2003 at 02:01:11PM +0300, Ilmari Heikkinen wrote:
> If I understand correctly, you describe a system in which you specify
> the input data and the operation. And then find a way from the input to
> the operation's input.

Yes, that's the basic idea, though it is only the beginning of the draft,
which is about how we can express these constrains and relate different points
of view on them, and why the system should then be made reflective, as an
attempt to not have a single formalism.

> > believe that it is interesting for my approach not to consider conversions
> > as absolute, i.e. "convert A to B" would only have a meaning in a context.

> Context...
> 
> I think I see the light! In an A -> B -conversion, using the context as
> an argument to reason about the most probable A and B. As in, if you
> were to convert a layered psd file in Animations-dir to a gif, it'd see
> the psd layers as animation frames and try to make it an animation, but
> if it was in Images-dir, it'd merge the layers and make a static image. 

No, sorry, I guess my use of the word "context" was not most appropriate. I am
talking about the functors as providing the "context" for a concept. It is a
system which is not ambiguous: everything is precisely formalized. The system
is not allowed to convert an object from A to B arbitrarily even if the
recipient says that it wants a B. The recipient must say that it wants a C,
which is a more abstract (higher-level) concept, and A and B must be
sub-concepts in some sense -- a sense which is precisely captured by a functor
from A to C, and a functor from B to C. Only then is it allowed to use a
function f from A to B, and only if we know that this function is the identity
function when seen abstractedly as a function from C to C. This condition
means that the object after conversion is "the same" as before, when viewed as
a C.

But again this is all essentially a convenient playground, a kind of starting
point on top of which I can go on writing the rest of the draft. 
(Unfortunately the end is still pretty compact and confusing.)

> I'm using the 'property-set' of the input data in trying to preserve the
> meaning. If a conversion loses a property that exists in the input data
> then it's bad if the endpoint needs the property.

This is different. You are specifying a single formal system, and you are
expressing "interesting information" as properties. To link it with my point
of view, you could consider the concept of "object with this specific set of
properties". When you ask that properties should not be lost, you ask that the
object should remain unmodified when seen as an instance of that concept.
Moreover, you have to do some educated guesses to know what the user or the
files really mean, e.g. look for the file name extension and magic bytes. This
is unavoidable for a tool like ccp. I guess you are doing so when you first
enter a file into the model, i.e. when you build a set of properties for the
existing (input) file. In my point of view, the file is initially just an
instance of some "file" concept of another trivial model, and you are using
heuristics to know to which specific concept it maps to in the interesting
non-trivial model with properties.

To widen this comparison, consider ccp as a formalism in which to write such
models. A model is a set of conversion rules, with sets of properties as
concepts. The ambiant (ccp) formalism comes with its execution rules. It is
thus an example of the kind of formalism I describe (though it is restricted
in several respects). What I am now trying to do is to study what occurs if
you have more than one model and inter-relate them (in the "subjective models"
section); then what occurs when you try to relate different formalisms, and
how the formalisms should be meta and reflective to help about that (i.e.
representing the execution within a formalism as an operation in another (or
the same) formalism).

Does it make more sense?


Armin