Reduction rules mapping

Oleg,

Where is your $COPY_SRC$ macro? In reduction rule?

The possible answer for your question is that your "output" node may have not been generated yet when $COPY_SRC$ is executed.

You can investigate it using "show mapping partitioning" action or/and by enabling main menu->generation->save transient models and looking on your transient models (if the model generated before applying your rule doesn't have your output node in place, there is no guarantee that it will be in place when your reduction is applied).

If the problem is like described, you should use generator priorities to adjust the geeration so that the output node is generated before the macro is applied.

If you have any questions, please ask.

Regards,

Mihail

See test project in attachment.

See COPY_SRC macro in the RootClass at the generator model. I suppose in this case macro must returns "true" value.

Oleg,

Sure this won't work. When your root mapping rule (where the $COPY_SRC$ macro is) is applied, reduction rules are not yet executed.

Actually, what you want is much more simplier than what is written :-)

Reduction rules are applied while copying automatically, you don't choose the reduction rule to apply to node in $COPY_SRC$. That's your mistake. This macro just copies node automatically applying all suitable reduction rules. To include a result of template application, we have the $INCLUDE$ macro

In your case you have 2 opportunities:

1) if you choose template based on some condition, you can write this condition in reduction rule and just insert $COPY_SRC$ with node.childConcept into your root mapping template:

2) if you need to apply some template based on the place where the concept is used, you can remove reduction rules at all (but convert your inline templates to regular templates and leave them) and use $INCLUDE$ macro:

Regards,

Mihail

Mihail,

But I can't use $INCLUDE$ or $SWITCH$ macroses.

Look at the my project. Checkout it from https://asn-mps.googlecode.com/svn/trunk/

Look at the Test solution, Test2 model, Seq type assignment.

Here in the SEQUENCE type present two named types.

At the generator output I must get:

public class Seq extends SequenceType {

  public IntegerType a1 = Builtin.primitiveDescriptors.get("INTEGER");

  public BooleanType a2 = Builtin.primitiveDescriptors.get("BOOLEAN");

}

Seq class creates TypeAssignment rule,

"extends SequenceType" creates SequenceType rule,

public <Type> a1 = <Init>; here works NamedType rule.

The trouble is that at the left side of equation I must use ClassifierType, but at the right it must be some initializer. So, I can't use reduction rules here, only weaving rules are remains.Is it right choice??? May be you have some construct, like an "extensible SWITCH"? AISI - in the ASN language I write two switch templates, first - produces the ClassifierTypes, second - produces type initialization and I must save opportunity to extends this switches in languages, which use the ASN language.

TIA

I found the way... Every type themselves creates in the parent class field. But here the trouble is appears again. The generator can't find context node at the weaving rule. I have two identical rulesets for IntegerType and BooleanType, for IntegerType all works perfectly, but for BooleanType the error is appears. What a problem?

P.S. The project you may found at the above link.

Regards,

Oleg

Ah, I see.

The solution you described in your last comment is right.

On trunk version, no problems appear while generatng; I'll try this on 1.1 a bit later.

Btw, now I can't offer a way to reuse the "public <Type> name = <Init>" construct as you wrote in your previous post, but in 1.2 a new feature will be available so that it will be possible (parameterized templates)

Regards,

Mihail

No problems with generation on b.5266 (1.1 release build)

Generated text:

public class Seq extends SequenceType {
  public BooleanType a2 = (BooleanType)Builtin.primitiveDescriptors.get("BOOLEAN");
  public Seq.a3_type a3 = new Seq.a3_type(this);
  public IntegerType a1 = (IntegerType)Builtin.primitiveDescriptors.get("INTEGER");

  public Seq() {
  }

  public class a3_type extends SequenceType {
    public IntegerType b1 = (IntegerType)Builtin.primitiveDescriptors.get("INTEGER");

    public a3_type() {
      super();
    }

    public a3_type(ASNDescriptor descriptor) {
      super(descriptor);
    }
  }
}

What build are you using and what errors exactly do you have when  generating?

I've looked at the generator code and it seems that it  should work fine.

Regards,

Mihail

I'm sorry, but I commit without b2 field at the inner sequence by accident. Try again. Problem with the b2 field.

I'm already understand the problem - it appears because rule for inner sequence runs before rule for the outter sequence.

Errors:

  couldn't find context node

  -- was input node: [type] SequenceType <no name>[1267847971805199623] in Test2@1_0

  -- was template: [weavingMappingRule] Weaving_MappingRule <no name>[6938031656093927510] in ASN.generator.template.main@generator

P.S. MPS 1.1 build 5250

Oleg,

In your case I would suggest to try to generate inner classes using reduction rules (they are more appropriate when generating tree-like structures as you o for your types). So, inside the class generated from outer sequence, you can write something like

in $LOOP$ macro you could iterate through all the elements for which you need to generate classes, $INCLUDE$ macro will "reduce" each item.

Though nothing is said about weaving rules priorities in documentation, it's quite strange that they were applied not in order of copying.

In current build, weaving rules are applied correctly, your generator works (so will it in 1.2, I suppose). I'll discuss this problem with the team at the beginning of the week and will write here about the result - maybe after 1.1 a more strict conventions about weaving rules were introduced.

Sincerely,

Mihail

Thanks, Mihail.

INCLUDE macro it isn't good idea, because it's also non extensible as the SWITCH. I will think about it, may be I will found the more admissible way.

>> Btw, now I can't offer a way to reuse the "public <Type> name =  <Init>" construct as you wrote in your previous post, but in 1.2 a  new feature will be available so that it will be possible  (parameterized templates)

It's good news! :-)

Regards,

Oleg

Oleg,

The result of meeting with team: we can't guarantee the weaving rule application order, and it works in 1.1 by accident. We only can say that in process of generation of the same model under the same version of MPS the generation process will be the same.

In your case, our generator guru ;-) recommended doing what I wrote about in the previous post - to "reduce" tree-like structures, not to "weave".

>INCLUDE macro it isn't good idea

I meant <<some macro to "reduce" your code>> - include, switch, map.

Regards,

Mihail

I must thank you and your guru for helping and patience :-)

Ok, I will try do this via COPY_SRC macro.

In the end I have one question as well. How I understand MAP_SRC macro this is just dictionary, where key - label and input node, value - generated node or what?

Regards,

Oleg

About $MAP_SRC$ - it is an ordinary macro which helps to "map" a node to another node (see mapping func in inspector).

It is used to add mapping labels just because this is the easiest way to add a macro when no real macro is needed (map function is trivial in this case and not specified in editor). You can add mapping labels to any node macro and to mapping/weaving/reduction rules theirselves.

Regards,

Mihail