JavaModelingLanguage / RefMan

4 stars 0 forks source link

Naming - method specs #43

Open davidcok opened 2 years ago

davidcok commented 2 years ago

I'd like to settle on any changes in clause names, in the interests of consistency and intuitiveness. So here is the first of a set of issues on this point.

Loop specs -- separate issue

Statement specs -- Everyone OK with these I presume: assert assume set unreachable refining

Type-level specs-- Also OK I think: invariant axiom represents initially constraint readable...if writable...if monitors_for initializer static_initializer

Model programs: returns, continues, breaks, choose, or , extract -- Gary - should that be extracts instead of extract? -- I think we need to add 'throws'

Block specs, in addition to regular method specs clauses, have: returns, continues, breaks. Also needs 'throws'

Method specs clauses. My preference is for active verbs with consistency across the clauses. Gary likes the connotation of the 'able' suffix. And there is always past experience/backwards compatibility to consider.

requires - OK ensures - OK signals, exsures -- deprecate exsures? 'throws' would be better than signals signals_only -- maybe 'throws_only'? accessible -- I'd prefer 'reads' captures -- OK with me. Does Gary want capturable? callable -- maybe 'calls' ? diverges - OK (anyone proposing 'divergable?) working_space, duration - inconsistent, but no better alternatives and not yet used, so OK measured_by -- OK, but should this be 'decreases' when - OK old - OK, but could be 'let' ('old' is a reminder that it is a pre-state evaluation)

And the biggie: assignable/assigns/modifiable/modifies/writes -- separate issue

leavens commented 2 years ago

Yes, I'm okay with the statement specification decisions we have made.

The list of type-level specifications seems fine to me.

For model program specifications, extract is correct, as it is a directive to the JML tool to extract a model program specification from the code (see section 4.2 of Sharner, Leavens, Naumann "Modular Verification of Higher-Order Methods with Mandatory Calls Specified by Model Programs" in OOPSLA’07, October 21–25, 2007, Montréal, Québec, Canada, pp. 351-367, https://doi.org/10.1145/1297027.1297053).

For both model programs and block specifications, the idea of throwing an exception is already handled by the signals clauses in JML specifications, so I don't think that a new kind of clause (throws) is needed. But I am okay with adding throws as a synonym for signals. If we do that, then we should add throws_only.

You are right that I like the "-able" suffixes for assignable and accessible, as well as callable.

It would be fine to deprecate exsures, that was added for compatibility with ESC/Java.

I would not argue for capturable, although that would be logically consistent with my position, it doesn't sound right as an English word. The same holds for divergable.

The working_space and duration keywords were taken from RESOLVE. But I'm okay with alternatives if someone has better ideas.

I would agree to replacing measured_by with decreases (or decreasing).