Guys,
I ask this out of curiosity more then anything else. In the define-type statements I see have what looks like a generated id field. How does this id field get generated? If its not generated how does it get calculated?
Thanks, Eric
Afficher les réponses par date
On 6-May-06, at 3:23 AM, Eric Merritt wrote:
Guys,
I ask this out of curiosity more then anything else. In the define-type statements I see have what looks like a generated id field. How does this id field get generated? If its not generated how does it get calculated?
Here's a type definition that I write in program A:
(define-type point ; a 2D point x y)
Here's a type definition that you write in program B:
(define-type point ; a point in a list x next)
Even though they have the same name these two types are semantically different (in the sense that they serve different purposes). But that's OK because they are not in the same scope.
But in a distributed system, programs A and B might exchange instances of these types (serializing/deserializing them with object-
u8vector and u8vector->object) and then it becomes important to
distinguish them, otherwise the programs might silently perform illegal operations.
OK, so the name of the type, which is chosen locally by the programmer, is not sufficient to distinguish it from other types.
To solve this problem Gambit attaches a type "identifier" to every type defined with define-type. A type identifier is a symbol. It can be specified explicitly when the type is defined, using an "id:" keyword. If this keyword is not used, as in the above examples, then an uninterned symbol is automatically generated when the type definition is evaluated. Automatic generation is useful to guarantee that the type will never be confused with a type definition evaluated elsewhere. However, in a distributed system you need to guarantee that two programs that communicate agree on the type of data they exchange. For example, if programs A and B need to exchange a 2D point, then BOTH of these programs would include a type definition such as this:
(define-type point ; a 2D point id: F006B7EE-BDD2-4CBC-8E68-D2CAD2A4E702 ; generated with uuidgen x y)
That way it is possible for programs A and B to agree on the semantics of the "point" type and to test at run time that "point-x", "point-x-set!", etc operate on the right type. Of course this works as long as there is a disciplined way of choosing type identifiers that are unique in the whole distributed system. To be safe I generally use universally unique identifiers generated with uuidgen.
Marc
Marc,
Thanks for the detailed response, this clears up the question very well.. I have a minor additional question. define-type and define-structure seem very similar (with the exception of the id field). Why two different expressions for, what seems to be, the same model?
On 5/5/06, Marc Feeley feeley@iro.umontreal.ca wrote:
On 6-May-06, at 3:23 AM, Eric Merritt wrote:
Guys,
I ask this out of curiosity more then anything else. In the define-type statements I see have what looks like a generated id field. How does this id field get generated? If its not generated how does it get calculated?
Here's a type definition that I write in program A:
(define-type point ; a 2D point x y)Here's a type definition that you write in program B:
(define-type point ; a point in a list x next)Even though they have the same name these two types are semantically different (in the sense that they serve different purposes). But that's OK because they are not in the same scope.
But in a distributed system, programs A and B might exchange instances of these types (serializing/deserializing them with object-
u8vector and u8vector->object) and then it becomes important to
distinguish them, otherwise the programs might silently perform illegal operations.
OK, so the name of the type, which is chosen locally by the programmer, is not sufficient to distinguish it from other types.
To solve this problem Gambit attaches a type "identifier" to every type defined with define-type. A type identifier is a symbol. It can be specified explicitly when the type is defined, using an "id:" keyword. If this keyword is not used, as in the above examples, then an uninterned symbol is automatically generated when the type definition is evaluated. Automatic generation is useful to guarantee that the type will never be confused with a type definition evaluated elsewhere. However, in a distributed system you need to guarantee that two programs that communicate agree on the type of data they exchange. For example, if programs A and B need to exchange a 2D point, then BOTH of these programs would include a type definition such as this:
(define-type point ; a 2D point id: F006B7EE-BDD2-4CBC-8E68-D2CAD2A4E702 ; generated with uuidgen x y)That way it is possible for programs A and B to agree on the semantics of the "point" type and to test at run time that "point-x", "point-x-set!", etc operate on the right type. Of course this works as long as there is a disciplined way of choosing type identifiers that are unique in the whole distributed system. To be safe I generally use universally unique identifiers generated with uuidgen.
Marc
-
Eric Merritt -
Marc Feeley