I started my review and I found the example below got an error of "Cannot override a binding feature value." Is that correct validation? Note that the error disappeared when :=5 was removed.

package ST6R815 {
	struct Vehicle {
		var milage := 5;
	}
	feature v : Vehicle {
		const :>> milage = 5;
	}
}

Also I felt strange that the example below was not marked as an error:

	struct Vehicle {
		const milage := 5;
	}

while

	struct Vehicle {
		milage := 5;
	}

gets an error of "Initialized feature must be variable."

started my review and I found the example below got an error of "Cannot override a binding feature value." Is that correct validation? Note that the error disappeared when :=5 was removed.

This is correct. This is an existing validation that is not actually changed by this PR: A non-default feature value cannot be overridden, whether it is initial or not. The validation check does check to see if the overriding value is consistent with the original value, because this would, in general, require arbitrary expression computation -- i.e., it could not generally be checked statically.

Also I felt strange that the example below was not marked as an error:

	struct Vehicle {
		const milage := 5;
	}

while

	struct Vehicle {
		milage := 5;
	}

gets an error of "Initialized feature must be variable."

This is also correct. A non-variable feature is not the same as a constant feature.

Odd as it may seem, any feature with isConstant = true must also have isVariable = true. That is, a feature can't be declared "constant" unless it first has a snapshots as its featuring type, so it would otherwise have been able to vary if not declared constant. Therefore, a constant feature can be initialized, but then it should just never change from that initial value.

On the other hand, a feature that is not variable cannot have an "initial" value. This is because the semantics of "initial value" is that it is the value of the feature on the starting snapshot of its owning type. So, for this to make sense, the feature must have snapshots as its featuring type -- that is, it must be variable.

Thank you. So in my understanding, const or var may have temporal semantics in the sense of 4D but without either (by default), we are not allowed to give any temporal semantics, and such temporal semantics are totally different from the concept of typical programming language of mutations. That is fair by itself. My remaining concern is that it would be quite confusing for typical programmers (especially who know JavaScript/TypeScript) since these are the same keywords.

I think I tested most of the pattern. May I ask one more question? Currently we do not get an error with the example below. I think it is not semantically correct but the current validator does not check it. Is that a correct understanding?

	part p1 {
		constant attribute a1 default:= 4;
		snapshot {
			constant attribute :>> a1 = 3; 
		}
	}

Thank you. So in my understanding, const or var may have temporal semantics in the sense of 4D but without either (by default), we are not allowed to give any temporal semantics, and such temporal semantics are totally different from the concept of typical programming language of mutations. That is fair by itself. My remaining concern is that it would be quite confusing for typical programmers (especially who know JavaScript/TypeScript) since these are the same keywords.

I am afraid I really don't understand your description of your understanding. Indeed, the temporal semantics of var and const are, by intent, just about like what would be expected by a programmer for variables and constants. What is different are the 4D semantics of features that are not var or const. But this is because KerML is a modeling language, not a programming language, and the 4D semantics are necessary to be able to declaratively define both temporal and spatial constraints.

But, also by intent, this is all largely hidden for SysML modelers, for which temporal modeling remains intuitively much like it was in SysML v1 and UML. The compromise is that SysML modelers then have to largely use constructs formally specified at the KerML level to model temporal relationships (like succession, etc.).

I think I tested most of the pattern. May I ask one more question? Currently we do not get an error with the example below. I think it is not semantically correct but the current validator does not check it. Is that a correct understanding?

	part p1 {
		constant attribute a1 default:= 4;
		snapshot {
			constant attribute :>> a1 = 3; 
		}
	}

Yes, the current validation is simply that a default feature value can be overridden, but a non-default one cannot. Now, the time of the snapshot in your model is not given, it is possible that it is the start snapshot, in which case it would override the default without any semantic inconsistency. Or it could be generally deduced that the the declaration in the snapshot implies that the attribute has to have value 3 for all other snapshots, too, overriding the default.

But, really, this is again something that probably will have to be detected at "run time". I think we will need to work it out as we complete the description of execution semantics.

I am afraid I really don't understand your description of your understanding. Indeed, the temporal semantics of var and const are, but intent, just about like what would be expected by a programmer for variables and constants. What is different are the 4D semantics of features that are not var or const. But this is because KerML is a modeling language, not a programming language, and the 4D semantics are necessary to be able to declaratively define both temporal and spatial constraints.

I think I understand your intent. I agree that KerML is a modeling language and more or less is designed to capture the meta level of execution semantics, in contrast, the typical programming languages represent executions themselves. Still, var or const reminds typical programmers of the concept of mutable or immutable variables, which are different from 4D semantics.

But, also by intent, this is all largely hidden for SysML modelers, for which temporal modeling remains intuitively much like it was in SysML v1 and UML. The compromise is that SysML modelers then have to largely use constructs formally specified at the KerML level to model temporal relationships (like succession, etc.).

I agree on this. Typical users do not need to care about these because they exist only in KerML.

Yes, the current validation is simply that a default feature value can be overridden, but a non-default one cannot. Now, the time of the snapshot in your model is not given, it is possible that it is the start snapshot, in which case it would override the default without any semantic inconsistency. Or it could be generally deduced that the the declaration in the snapshot implies that the attribute has to have value 3 for all other snapshots, too, overriding the default.

But, really, this is again something that probably will have to be detected at "run time". I think we will need to work it out as we complete the description of execution semantics.

Thank you for your answer. That helps me a lot to understand it.

@TheKorpos
I am having trouble merging this branch. To resolve the merge conflicts, the SysML parser needs to be regenerated. However, I cannot get that to complete without Java heap space out-of-memory errors.

The problem is not with this branch, because I can't regenerate the SysML parser on master, either. The problem seems to come from the addition of the optional global qualification to qualified names on branch ST6RI-830. Commit c15a0d7 says that you "Re-generated sysml xtext infrastructure". But, if I check out that commit, I cannot reproduce the generation -- I get an out-of-memory error (and strange grammar warning messages). I have tried increasing the heap space considerably, with no luck.

Did you have to do anything special to get the SysML parser generation to complete? Are you able to regenerate the parser on master? Note that the problem isn't the parser splitter, because your "count" update is in place (and, anyway, the error seems to happen before the splitting).

Did you have to do anything special to get the SysML parser generation to complete? Are you able to regenerate the parser on master? Note that the problem isn't the parser splitter, because your "count" update is in place (and, anyway, the error seems to happen before the splitting).

@seidewitz
Yes, I totally forgot that we had to increase the maximum heap size in the Generate SysML (sysml) Language Infrastructure runconfig (arguments > vm arguments) to get it working. It was working with 16 gig but maybe it works with less too.

Update: master works with 10gigs

Did you have to do anything special to get the SysML parser generation to complete? Are you able to regenerate the parser on master? Note that the problem isn't the parser splitter, because your "count" update is in place (and, anyway, the error seems to happen before the splitting).

@seidewitz Yes, I totally forgot that we had to increase the maximum heap size in the Generate SysML (sysml) Language Infrastructure runconfig (arguments > vm arguments) to get it working. It was working with 16 gig but maybe it works with less too.

Update: master works with 10gigs

I had previously only tried up to 8G. Before I saw your update, I got it to work with 12G.

This grammar is really getting out of hand, but w can go with this for now!