Edit properties with generator?

The generator language is read-only with respect to models. (You can create a new graph by generating MXM and using internal 'fileInPatch: new.mxm' execute, but that won't update existing models.)

There are three good reasons for keeping the MERL generator language read-only: <pontification>

MERL is a domain-specific language, aimed at the task of turning a model of objects into text. By focusing on one task, it can do it well.
Processing a set of objects to change some of them is a generic programming task, and for that there are many good existing languages like Java or C#. Everybody has their own favourite, so rather than fixing MetaEdit+ to one language, or trying to build our own to compete with the existing standards (!), we give you the API. That lets you use the language of your choice to do the tasks of your choice.
Having a tool do operations for you on the model data means that it stores the results in the models. It must then cope with both the initial case (empty :name property, in your example) and the result (:name being P1, P2, P3 etc.). And when you update the model, it must cope well - e.g. if you delete P2, should it renumber everything after P2, or leave it missing? When you create a new object, should it then be P4 or P2?

Rather than dirty the model with what should be a temporary result, created by a computer on the basis of other information input by humans, we aim to keep the model created by people. If there's anything extra a computer can figure out from that input, it should do that when we generate code. This keeps the model as small as possible, gives us the maximum flexibility (we can improve the rules later without having to deal with data created automatically with earlier rules), and avoids the problem of syncing automatically created data to match later model edits (e.g. P2 deletion). The algorithmic work for the metamodeller is the same (e.g. the numbering scheme), but instead of having to do part of it via the API on the fly (e.g. the numbering), and part later when generating code, both parts are kept in the same generator.

</pontification>

So as an example for your case, I'd consider whether you need a :name property at all. Does the user need/want to enter specific names? If not, and assuming your generated output needs to have names for points, simply use a running index, 'P' $++ix. If your users sometimes want to enter names, e.g. just for special points, but you also need to have names for the other points, you can use the running index when the user hasn't supplied a name, e.g. if :name; then :name; else 'P' $++ix endif. If you don't really care what the number is, you could use 'P' oid, which would make life easier if you had to refer to the same Point at several places in the generated code (where a naive $++ix would give a new number). It's also easy enough to make a mapping from each oid to a number, by creating associative variables:

/* set up the mappings from each Point to a number, e.g. $ix3_100=1, $ix3_106=2 */foreach .Point { variable 'ix' oid write $++ix close }
/* and later, in a given Point, to output P1 etc. for it */
   'P' variable 'ix' oid read

Edited by stevek - 17.May.2017 at 20:24