May 17, 2005 Meeting Minutes

People: Hans, Marc, and Philippe

Topics:

• Philosophical question about the AToM3 kernel:
  
• Should everything be considered a graph? If so, we could define standard transformations applicable to all graphs (e.g. docs).
  
• Modularisation of type checking:
  
• Each node would hold a "generative semantics" that would check whether an instance is legally a part of the node's instantiation set.
  
• Bootstrapping of central metamodel formalism:
  
• Along with pyGK, which is intended to represent everything in AToM3, there needs to be a minimal constraint language. The language should have a usable concrete syntax that would allow for easy specification of constraints on pyGK graphs. Other than the usual algebraic and boolean expressions, potential operations for the language would include simple comparisons between ints, floats, etc., iteration through graph nodes, navigation though a graph given a path, and so on. If the same language is to be used in the context of graph grammars, some action semantics should be added, such as assignment. Also, on first glance, we can think of a few things that should be doable on a pyGK graph that would demand action semantics: addElement, removeElement, connect, disconnect, setValue.
  
• It can be foreseen that, on top of this very minimal kernel (graphs + constraints), any other formalism like Class Diagram could be built.
  
• The great advantage of developing such a language would be to have a language- independent kernel from which code in any other language could be generated after parsing to an AST. This language, combined to the decision of representing everything as a graph, would be lead to a very nicely closed system.
  
• On pyGK:
  
• Should SymbolTable and List be removed from the PrimitiveTypes library? If we want our kernel to be as small as possible, it would be a good idea to do so. However, graphs will now support the same notation as SymbolTable (i.e. node["attrName"] to assign and extract an attribute), as it was modified to support insideness of nodes. Lists, on the other hand, are still not yet crucial to the kernel, but they could potentially be very usefull for elegance. Some implementation options for Lists were discussed, such as the idea of specializing Graph to have an "ordered graph" in which the nodes would have some kind of order when iterated through. It was also discussed whether this "ordered graph" should be indexable or simply follow linked list semantics.