Changes between Version 15 and Version 16 of CurrentlyProposedLanguage


Ignore:
Timestamp:
Nov 5, 2010 4:31:48 PM (14 years ago)
Author:
sunshine
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CurrentlyProposedLanguage

    v15 v16  
    8686
    8787We should have a notion of events matching each other, like a reply matches a request. To support this there's a function '''match(event1, event2)''' which is defined in the domain knowledge base for each request/reply pair. In the timeline of events part of a meta-description if we want a reply to match a request we must explicitly say so using '''such that''' operator or have a condition on reply matching the request to proceed with the rest of the events in the sequence.
     88
     89= Meta-descriptions =
     90
     91A meta-description starts with
     92
     93'''define MDName:'''
     94
     95and may be followed by import statements if it uses/extends some other metadescriptions, such as
     96
     97'''define MDName: import MD1 m1, MD2 m2'''
     98
     99It has the following sections
     100
     101'''Logical topology'''
     102
     103   '''Objects'''
     104   
     105    All relevant objects are defined here. If some are imported from other meta-descriptions and use the same name, are of the same type and have the same initialization they are not mentioned. If some are imported but the name/type/initialization are changed they are mentioned here, linked to the object they extend from the imported meta-description and any changes are noted. For example:
     106
     107    Name := m1.name, Name := {String n, state = Assigned}
     108
     109   '''Relationships'''
     110 
     111   Relationships between objects are defined here. For now we use only '''collocated''' function.
     112
     113'''Timeline of events'''
     114
     115   '''Definitions'''
     116
     117   This section defines all events and states. We may use '''each''', '''some''' operators and aliases for state definitions. Event types may extend other event types. All events/states must be defined here. If we inherit some events from other meta-descriptions and customize inherited ones, we have to redefine them. In case of inheritance relevant events will be checked against both meta-descriptions. If we inherit events from other meta-descriptions as they are, without customizations, we can just note that without redefining them. For example if we imported from m1 that had defined event e2 as event of type INFO without any parameters we'd do the following in order to customize it:
     118
     119   e1 := m1.e2, e1 := {type = INFO, content = x}
     120
     121   vs doing the following if we're not customizing:
     122 
     123   e1 := m1.e2
     124
     125
     126   If we are importing all events from a metadescription we don't have to say anything in this section.
     127
     128
     129
     130   '''Timeline'''
     131
     132   This section describes ordering of events, i.e. the scenario of the experiment. In case of inheritance, the inherited scenario should be possible to obtain from the given one. If we are combining two or more meta-descriptions we can either interleave their events manually such as
     133
     134    m1.e1 -> m2.e1 -> m2.e2 -> m1.e3
     135
     136  or we can say that all events from one meta-description occur in some given order with events from other meta-description, such as
     137
     138  timeline(m1) -> timeline(m2)
     139
     140  The above means that all events from m1 must happen before any events from m2.