A case against standards

[Armin Rigo]

Hello Ilmari,

On Sun, Oct 19, 2003 at 09:44:39AM +0300, Ilmari Heikkinen wrote:
> So, hmm, suppose we have an object O of set A, and a function that
> accepts members of set B with the context C. The function would accept
> O's projection to B if and only if O-as-A's projection to C equals
> O-as-B's projection to C.

Yes, this is exactly the idea.  No conversions with "do-what-i-mean"  
semantics;  instead, C is used to specify exactly what aspect of the object
you are interested in preserving.  Another example is with the typecast in C:  
it has several different meanings according to what types you use it with.  
For example, if 'f' is a float, then (int)f means "an int which represents
roughly the same number"; but if 'pf' is a 'float*', then '(int)pf' means "a
machine word with the same bit pattern as the pointer 'pf'". If you want an
int with the same bit pattern as a float, you must figure out a tweaked cast
that will prevent the compiler from guessing that you want to convert a
numerical value, e.g. '*(int*)(&f)'.  In my mind, these cases can be well
defined by expressing whether you are interested in preserving the approximate
numerical value or the bit pattern.

> And C could be anything, but would usually be
> used to specify the exact information the function is interested in, so
> the common use-case for context would be an abstract model C written in
> the formalism B.

This is where I differ a bit in my draft, by trying to see what can be done
without actually formalizing C at all.  There is no need for any specification
of what an "Image" is for the conversions to actually work, if the conversions
advertize that they won't change the "Image" aspect of objects.  See the lines
of code at the end of section 2.2.

> Or am I glossing over something? Also, what is your definition of
> subclass? A class related to another via the sharing of one or more
> abstract pieces of information?

No, I'm using the usual OOP definition of inheritance, which I'm contrasting
with.  Prototype-based languages provide a slightly different OOP model but
they are of no help to me here.

> Um, let's see. Would expressing a program written in language A as one in
> language B be an example of relating models and formalisms? Also, would
> information expressed in a specific format be a model written in the 
> formalism that is the format?

It is an example of relating models and formalisms.  You can seldom translate
a program written in A into a program written in B by respecting absolutely
all the semantics.  Often, there are specific language- or even
implementation-dependent details that are not relevant to your program.  For
example you cannot guarantee that the two programs will take exactly the same
amount of memory and processor time!  Still, you can write a translated
program that behaves like the original one in all *relevant* aspects.

It is not possible to design the "ulimate" programming language in which you
could write programs by expressing exactly and only what is relevant.  It is
only a pure ideal.  But you can compare two programming languages, and a
program and its translation, and say what was relevant (and thus has been
preserved during translation) and what was not (and thus might have been done
differently), though you might not be able to express it in either language, 
but only by hand-waving.

I'm saying is that we need to be able to express the *existence* of aspects
(the "context"), and that it can be useful even if we do not necessarily
formalize these aspects, because we can say which ones are considered relevant
in particular cases (it may not be the same ones from program to program), and
say which of these aspects conversion routines preserve.

> As for the goals.. Finding out the limits of translation between formats
> and how the formats could be written to best help in doing (automated)
> translation?

At this point, I'm hoping to apply this model to languages as described above.  
So my goal is to figure out how best to do inter-language translations.  Of
course this is not really different from other kind of inter-formalism
translations, but I guess that as long as I don't have anything powerful
enough for expressing translations between very different programming
languages it won't be enough.  I want it to be complete enough so that the 
inference engine itself is available to the formalism, and can be translated 
from language to language as well.  This is how I expect to "chain" 
conversions (A -> B -> C): a program written in C knows about B, so it can 
import B's knowledge about A.


A bientot,

Armin.