A case against standards

[Ilmari Heikkinen]

Hello Armin,

> On the other hand, in my approach I try to look at what occurs if we 
> want to take *operations* as the starting point, and conversions as 
> a mean to combine seamlessly operations; the conversions are not the 
> end goal in my draft.

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. Convert input to operation's input format, put it
through the operation. Thus enabling the chaining of operations with the
conversions as glue.

> It is also a result of a personal point of view that I am always looking for
> notions that we consider absolute and trying to see if they really are. I
> 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. This
> is because some operations do different things with the same objects, and it
> doesn't always make sense to convert objects under their feet in the
> "intuitive" sense.

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. 

Using the context to decrease ambiguity and allow better inference.
I think this could be written into the gettype-script mentioned below.

> The point in my draft is that operations specify what exactly
> they are interested in: "get-file-size" is interested in a "file", whereas
> "show-on-screen" is only interested in the more abstract concept of "image"
> and thus you can convert between file formats before show-on-screen as long as
> you don't change the "image" meaning of the file.

Specifying types by operations is what ccp is doing internally - edges
specify their endpoints. The "reality->graph-interface" is a script that
takes input data and converts it to types in the graph.

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. The actual Types are
seen as abstractions for definition reuse; predefined sets of properties
that the function properties can override. None of this is written yet
though, just got the prototype doing its first chained conversions
yesterday. The fancy stuff'll come later if everything works out.

If we're working on different aspects of a similar system, maybe there's
a way to unify the effort?


-Ilmari