What is the correct way to add separators when using COPY_SRCL macro?

Hi,

Sometimes we'd need to generate a list of nodes separated by a constant string (for example, comma-separated list of function parameters). At the moment we can do this using COPY_SRCL macro in function template...


   > function  $[name] ( $COPY_SRCL$[parameters] ) {

... and IF macro in the function parameter template

<TF * $IF$[,] $[name] TF>

where IF contains the following condition:


node . parent : Function . parameters . first != node

It works, but... this way seems a bit ugly, as separator (from my point of view, at least) shouldn't be a part of function parameter definition.

So, the question is if there's a "more correct" way to add separators in this case. Could you give a clue, please?

6 comments
Comment actions Permalink

Hello, Konstantin,

COPY_SRC macro is applied to a syntax tree. Syntax tree doesn't contain any separators they are part of presentation. This means thatt they are added automatically to editor so you don't need to do anything to add separators.

Regards,

Konstantin

0
Comment actions Permalink

Thanks, I see.

But the problem is that

a) we eventually attempt to transform the original language AST to the 'gtext' language AST to generate text files;

b) sibling nodes in original AST won't necessarily transform to sibling nodes / subtrees in 'gtext' AST

For example consider the following AST:

Function [foo]

- FunctionParameter [bar]

- FunctionParameter [baz]

... which is transformed to the following gtext tree:

GLine

- GText [function ]

- GText [foo]

- GText [ (]

- GText [bar]

- GText [,]

- GText [baz]

- GText [)]

I believe that this situation will arise more or less often in real tasks, so it would be nice to have a mechanism simplifying this.

Best wishes,

B.K.

0
Comment actions Permalink

IMO, it's a very rare situtation. If someone wants to generate a lot of code in a given language, he should create a first-class support in MPS for this language. It will save him a lot of time. GText is only a temporary solution.

0
Comment actions Permalink

Hm... So, in general, I should prefer text generation based on *_textGen classes to the 'gtext' language, should I?

Kind regards,

Konstantin.

0
Comment actions Permalink

TextGens aren't official part of API. The recommended way is to use gtext.

BTW, we can add a separated list construction to gtext which will simplify the thing that you described.

0
Comment actions Permalink

Thanks, that would be great.

Kind regards,

Konstantin.

0

Please sign in to leave a comment.