<br><font size=2><tt>Vamshi wrote on 04/24/2005 01:34:50 PM:<br>
<br>
> I'll try to make the example clearer:<br>
> 1)<br>
> Lets say I've defined a language with delay, gain, adder and patch-cord
<br>
> components (L1), using MetaGME (MG). This gives me a simple language
for <br>
> describing digital filters. It also gives me a nice visual environment
<br>
> (V1) to do this. Now I give my environment to a signal processing
expert <br>
> and ask him to describe a language that contains predefined filters
like <br>
> feedforward comb filters (FFCFs), feedback comb filters (FBCFs), allpass
<br>
> filters (APs), etc using this environment. The description of this
new <br>
> language L2 is much more concise and clear in L1, than in MG. So one
<br>
> motivation is readability/maintainability.<br>
> 2)<br>
> Now lets assume the expert was able to define L2 and it's corresponding
<br>
> environment V2 using L1-V1. This would give me L2-V2 which has FFCFs
and <br>
> FBCFs, whose parameters are defined visually in V1. (So people familiar
<br>
> with the notation from a typical electrical engineering textbook could
<br>
> use V1 with little training to create the new language+environment
of <br>
> L2-V2). Further, I could define, similar to GReAT, *patterns*/sequences
<br>
> of filters/filter-networks, using the V1 notation. Describing these
<br>
> patterns in the MG notation (class diagrams), might be difficult or
<br>
> impossible for the domain expert, but maybe possible with little effort
<br>
> using V1 + a pattern language.<br>
> So the other motivation is reuse. Can the "domain-specific visual
<br>
> modeling" idea be extended to "domain-specific visual metamodeling"
?<br>
> <br>
> I hope that was a better description.<br>
> One solution I can think of is to write an *interpreter* for L1 which
<br>
> generates and registers the paradigm L2 and the corresponding <br>
> metaconfiguration file for V2. Perhaps I should take a look at the
<br>
> GME-GUI code to see how this is done? Or maybe I can do this with
GReAT?<br>
</tt></font>
<br><font size=2><tt>Now I understand the motivation better. As Mat suggested
you can use the type/subtype/instance feature of GME. This will give a
dynamic type system where say signal processing experts can create more
complex type based on the simple types defined in the meta. Users can use
these concepts by attaching the complex types as libraries.</tt></font>
<br>
<br><font size=2><tt>The other alternative as you mentioned is to write
an interpreter that could convert an instance of P1 to produce a new metamodel
P2. Here you have to be careful because you will be using P1 in two roles,
(1) as a metamodeling environment and (2) as a modeling environment. You
can however, define clear semantics for both and then write the interpreter.</tt></font>
<br>
<br><font size=2><tt>Since the MetaGME paradigm is the same as any other
modeling paradigm in GME, you can use any of the model access API's to
write such an interpreter. GReAT would actually be quite useful for this
task as these are the kind of scenarios it has been designed for.</tt></font>
<br>
<br><font size=2><tt>Thanks,</tt></font>
<br><font size=2><tt>Adi</tt></font>
<br>
<br>