Libelektra: data types

[markus2330]

Because of planned changes in the type system (e.g. #1092) now is the last chance to change it. You can raise your voice for which basic data types Elektra should use for its validation/code generation/APIs. Possibilities include:

1. CORBA types (+ currently used in Elektra, + defines mappings to some languages, - quite old, - unpopular)
2. SQL types (+ popular, - defines binary types and large object types)
3. XSD types (+ define hierarchy, + popular, - defines too much?)
4. C (or Rust) fixed types, e.g. float, double, int32, uint64,... (+ popular, + names are self-describing, + many mappings, + no mappings needed for APIs, - unusual for persistent data)
5. JSON types (+ popular, - a bit too minimalistic, e.g. no decimals)
6. Ada types (+ contains nearly everything types offer, - unpopular, - unknown)
7. YAML core or even extensions
8. nothing built-in, every type is an extension (like service oriented architectures)
9. further suggestions?

@ElektraInitiative/elektradevelopers Please suggest further type systems, tell us further pro/cons, and say which you like best!

[sanssecours]

I think one problem with this issue is that usually people prefer type systems they know. I only have very basic knowledge about some of the type systems you listed (SQL, C, Ada) or no knowledge at all (CORBA, XSD, JSON).

Keeping that in mind, I would prefer a small high level set of data types. For example, in my opinion it would make sense to offer only one integer type, which is able to store numbers of variable size (like Haskell‘s Integer type or Python’s int). It might also be a good idea to offer data types for common data structures like lists and dictionaries.

I did not read that much about YAML’s type system yet, but according to the documentation of the core schema it looks like a good fit for my preferences. According to the documentation YAML’s core schema is an extension of JSON’s type system. Since it also offers an integer data type, YAML’s core schema should also address the problem you noted about JSON’s data types:

…- a bit too minimalistic, e.g. no decimals

.

[markus2330]

Thanks for your input!

I think one problem with this issue is that usually people prefer type systems they [k]now.

Yes, I am aware of this but I would also be interested what you know and want to have supported well. Thanks for starting the discussion.

I would prefer a small high level set of data types ... in my opinion it would make sense to offer only one integer type

In XSD they solve this issue by having an integer type if you do not care which size it should have exactly. But if you want to specify it further, you can do so. (within the given type hierarchy)

YAML’s type system

Thanks, I added your suggestion! Did you also notice http://yaml.org/type/?

Implicitly you also stated another very good point: If we use a type system with very few types we might have an issue to represent all types that are found within configuration files and have a hard time to communicate them to the applications.

[sanssecours]

In XSD they solve this issue by having an integer type if you do not care which size it should have exactly. But if you want to specify it further, you can do so. (within the given type hierarchy)

While customization is usually nice from a user perspective, it also means that we have to write more code and the possibility of additional bugs increases. I assume most people prefer a variable sized integer class if they have the choice, since this type removes a class of possible errors (underflow, overflow). I see two issues with providing only one variable sized integer type:

1. Processing of a variable sized integers is usually slower, than fixed integer types, because we need to provide additional checks.
2. Neither C nor C++ offer native support for integers of unlimited size, as far as I know.

Did you also notice http://yaml.org/type/?

Not yet, thank you for providing the link. I think it would make sense to include most of the data types mentioned on this page. Some of them might be not that useful (!!omap, !!pairs, !!merge) though.

Implicitly you also stated another very good point: If we use a type system with very few types we might have an issue to represent all types that are found within configuration files and have a hard time to communicate them to the applications.

YAML also supports custom application specific types via so called local tags, specified via a single exclamation mark !. However, I think it would be a good idea to only support global tags (like !!int, !!float, !!binary, …) first. Can you think of an important type of configuration data that is not part of YAML’s type system?

[markus2330]

Neither C nor C++ offer native support for unbounded int

No, they do not. And it would not be ideal if people specify they need an unbounded int while in reality they support numbers from 1 to 15.

Can you think of an important type of configuration data that is not part of YAML’s type system?

If you mean with "important" "popular"---enums or special cases of it (like tristate) are found/needed quite often.

But you are right: YAML supports everything needed for configs, or is even at the edge of being too complicated.

[sanssecours]

And it would not be ideal if people specify they need an unbounded int while in reality they support numbers from 1 to 15.

Oh, I did not think of that use case at all 😀.

[markus2330]

If there are no proponents of the proposal we will simply clean up the CORBA types (see #1092) and keep it (simply because it is minimal effort). Additionally types (such as fixed-sized) can of course be added as extension.

[markus2330]

@sanssecours Thanks again for your input! I like your positions on simplifying Elektra!

To avoid having programs fail during runtime (and also not ending up implementing unbounded data types for all languages not having unbounded data types), we would need to add the bits+sign as extra specifications.But then it somehow also loses the property of being simpler?

The question is if it is worth the effort, the data types are certainly not the biggest issues of Elektra.

[markus2330]

As discussed, we will continue to use CORBA. We will deprecate and remove non-standard extensions such as empty and FSType.

Making all types consistent in Elektra is discussed in #1092.