Supported built-in primitive types

[enikao]

• boolean
• string of arbitrary length
• integer
  • Do we support negative values?
  • Do we define the supported range?
• JSON
  • This implies: object (aka map), array, string, boolean, number, null
  • Do we map number to our integer?

Rationale for JSON support:

• Widely used
• Supported by every platform
• Representing structured data is core aspect of modeling
• Relieves the model user from (de)serializing structures to string

[ftomassetti]

One thing to consider is that integer is not present on all platforms. For example, it is not present in Javascript

[enikao]

Regarding integer constraints: I'd prefer to avoid C-style "it's something like a natural number, everything else is platform specific" undefined mess. OTOH, any hard requirement could only be the lowest common denominator (i.e. 31/32 bit).

What about this: By itself, it does not say anything about range or signedness. But we provide default annotations, and if they are present the LIonWeb implementation has to adhere and enforce them OR (if unsupported) refuse the Metamodel.

Examples:

• num: int // don't know anything
• @size(32 bit) @unsigned nodeId: int
• @size(64 bit) @signed nanoSeconds: int // JavaScript implementation would need to use complex type, or refuse as unsupported
• @range(0<=..<120) age: int
• @range(-100<=..<=+100) percentage: int

[markusvoelter]

We have ranges in KernelF. It was a mistake. They are complex to implement (if you want to track them in the type system). Many users don't want them and we have to "disable" them. The error messages are default from the system, which users hate. So I strongly suggest to not have ranges on integers (or any other constraints directly on types). You can always write a checking rule.

[dslmeinte]

Wouldn't bool, int (default: 32 bit signed, possibly 64 signed), and string already be (more than) enough. Saying something accurate about floats is already tricky, and usually you really don't want floats in models.

[enikao]

ad int: I think it would be useful to have some kind of guarantee of supported range. E.g. 64 bit is not supported in JavaScript, 32 bit unsigned is not supported for int in Java, etc.

ad float: I agree we don't want them in a model. If any, we could think about a decimal type similar to SQL, with defined size and fractional part.

ad JSON: The rationale for this datatype is mentioned above. Especially in combination with typedefs (#10) they seem very useful.

[dslmeinte]

ad int: I agree that 32 bits would be most logical. The alternative would rather be integers of unlimited size than 64 bits.

ad float: I'm afraid that introducing anything for decimal opens the flood gates for parametrization, and then we'd need to have a type system within the M3/LIonCore after all. I'd rather force people to serialize floats as strings, and have to think about what these kinds actually mean.

ad JSON: Can we name this opaque and define its semantics to be (in principle) that it's structured JSON (and/or XML?) that's not defined in the M2?

[enikao]

The discussion about JSON was like "something structured is very useful, and everybody is using JSON anyways". We touched on YAML, but thought the deliberate limitation on JSON avoids parsing and security issues (e.g. no comments, no labels/references). XML would be even worse in this regard.

[dslmeinte]

Good points. I tend to avoid verbiage that's technology-specific, but I also see that it's very hard to ultimately avoid that, and then JSON is clearer.

[enikao]

We could call the datatype structured, and say the format is JSON.

[dslmeinte]

Then I think JSON is closer to the mark, as it can only be just a string.

Did some experimentation here: LionWeb-io/lionweb-typescript@feature/further-dev-m3...feature/built-ins

[ftomassetti]

This is an experiment about defining builtins in Java: https://github.com/LIonWeb-org/lioncore-java/blob/master/lib/src/main/java/org/lionweb/lioncore/java/LionCoreBuiltins.java

We could have a metamodel containing the PrimitiveTypes we want to ship with LionCore.

[enikao]

In #34, we decided all types are to be encoded as strings.
I think this means we remove the JSON type?

[slisson]

These are different APIs. There is a low level one that has no knowledge about the meta model and property types. There everything is a string. Then there is a meta model specific API (generated from the meta model definition) that knows the type of the properties. The conversion from string to the bool/int/... happens between these APIs.

[enikao]

These are different APIs.

Makes sense. We should come up with names to distinguish them.

[enikao]

On 2023-01-13, we decided that default primitive types are always implicitly imported.
They use ids similar to M3 elements (#53), to be specified here.

[enikao]

For reference: The agreed ids and keys are listed in metamodel docs