Higher abstraction level for Integral types

[GoogleCodeExporter]

I tried to start a discussion on this on the Franca Forum, but as I haven't 
seen any reaction, I'm now entering it as a feature request.

Currently in Franca integral types are defined as UInt8, Int8, etc. This 
doesn't provide any abstraction (w.r.t. programming languages) and leads to 
mapping problems. For example Java doesn't have unsigned types. Without further 
knowledge, a UInt32 Franca type has to be mapped to a 64 bit long in Java.
It would be much better if in Franca you could specify:
Integer(range 1..31) dayOfMonth
This makes it possible:
- that the generator automatically selects the optimal type for a specific 
language. There may still be general deployment settings, e.g. to optimize for 
speed or size.
- to create a code generator which also generates code to check preconditions 
(to check whether the dayOfMonth is in the specified range).

Also for enumerations it should be possible to specify a range. This relates to 
Issue 2: "Add configuration options for Franca=>DBus transformation". If the 
range is specified by Franca, there's usually no need to specify the base type 
for enumerations in the deployment model.

For a smooth introduction, a new notation could be added and the current fixed 
types could be deprecated.

Original issue reported on code.google.com by peter.go...@gmail.com on 2 Apr 2013 at 12:27

• Blocking: #98

[GoogleCodeExporter]

Setting the issue type to RFC, as this issue requires further discussion.

Original comment by klaus.birken@gmail.com on 5 Apr 2013 at 3:21

[GoogleCodeExporter]

Second try for setting type to RFC..

Original comment by klaus.birken@gmail.com on 5 Apr 2013 at 3:22

• Added labels: Type-RFC

[GoogleCodeExporter]

Original comment by klaus.birken@gmail.com on 14 May 2013 at 7:46

• Changed state: Accepted
• Added labels: Component-IDL, Priority-Medium

[GoogleCodeExporter]

there are 2 questions within this issue:
1. mapping of types: each language binding may define its own mappings, so Java 
might find an other solution than C++ to map UInt64. In some cases the type 
mapping can be influenced by the deployment model: e.g. with CommonAPI C++, 
there is the possibility to change the backing type of enums (int16, int32, 
int8, ...). Similar there is such an option for Strings to be mapped to ASCII, 
UTF-8, UTF-16 etc.

2. validate range of data types: this is out of scope for an IDL, and hard to 
implement efficiently within a language binding. It would require generation of 
classes for each data type, and to perform validation after any change. 
CommonAPI implementation would ignore any such validation in the interest of 
efficiency.

Original comment by manfred....@bmw.de on 15 May 2013 at 11:36

[GoogleCodeExporter]

I think the primary idea of defining the ranges is not to be able to do an 
extended static analysis or validation. Mainly, it should lift the integer data 
types on a more abstract level.

We did some analysis and comparison to other type systems we are facing here at 
itemis and reached the following proposal: 
- a range-like typed as described above could be added to the IDL
- in order to provide backward compatibility, the current set of concrete 
integer types would be kept (without deprecating them in the first place)
- a "type constraint engine" would be added to Franca, which allows to compute 
a mapping from range-types to the current primitive types. This would use some 
configuration data (e.g., are unsigned types available?) and apply some 
well-defined rules. This way, existing trafos and code generators would not 
have to be adapted (best case). 
- later, the currently hard-coded basic integer types could be replaced by a 
fixed set of typedefs, which implement the basic integer types in terms of the 
range-based types.

It is very important that these steps do not change the current semantics of 
the basic integer types. The benefits of this solution are: The type system of 
Franca would be lifted on a more generic level, without dismissing the very 
concrete type semantics which is currently hard-coded.

Pls. comment on this proposal. We will try to fix a design solution in 
June/July 2013. A proper deadline for this RFC will be set in early June.

Original comment by klaus.birken@gmail.com on 17 May 2013 at 8:37

[GoogleCodeExporter]

Good proposal.

There should be some information added to the documentation on using the fixed 
types:
- if you use it, without limiting a range, you probably didn't think well 
enough about the possible values.
- if you use the unsigned types, without limiting the range, the consequence is 
that for languages that don't support unsigned types, a twice as big type is 
needed. E.g. in   Java a 64 bit integer is needed to support the max value of 
UInt32.

Original comment by peter.go...@gmail.com on 2 Jul 2013 at 2:23

[GoogleCodeExporter]

However I'd still also like it for enums.
In the end, enums are only integer constant. So if I can specify the range of 
an integer value, I should also be able to specify the range for integer 
constants.
There is a fundamental difference in specifying the range in Franca, or in a 
deployment model. If you specify it in Franca, the restriction is by Design, in 
the deployment model it is an implementation restriction.

Original comment by peter.go...@gmail.com on 2 Jul 2013 at 2:51

[GoogleCodeExporter]

I do understand the problem to be solved, to simplify the mapping of 
programming languages with kind of incomplete type subsystem like Java. Even 
D-Bus lacks an signed 8-bit type.
But I doubt that a Franca feature to specify ranges can solve that problem, as 
it is still possible and valid to to define an UInt32 with range of 32 bit.
In that case Java would still have to use a 64 bit long value and the 
"workarounds" do not really disappear, only their number might decrease.

Original comment by manfred....@bmw.de on 3 Jul 2013 at 2:58

[GoogleCodeExporter]

More design details about the "type constraint engine" mentioned in #5:
- we will implement this engine as a model2model transformation on 
Franca-IDL-models
- this m2m-transformation can be used as a preprocessor for an existing code 
generator
- configurable modes of this transformation (choose exactly one):
  - mode 1: replace all integer types with ranges by the corresponding primitive integer type, example: "Integer (1..30)" will be replaced by "UInt8"
  - mode 2: replace all primitive integer types by the corresponding range type (with maximum range for this primitive), example: "UInt8" will be replaced by "Integer (0..255)"

Original comment by klaus.birken@gmail.com on 10 Jan 2014 at 3:49

• Added labels: Milestone-v0.9.0

[GoogleCodeExporter]

Original comment by SteffenW...@gmail.com on 14 Mar 2014 at 1:30

• Changed state: Started

[GoogleCodeExporter]

The "type constraint engine" has been implemented on develop with commits 
7505935 and e592682.

Original comment by klaus.birken@gmail.com on 7 May 2014 at 1:04

[GoogleCodeExporter]

Original comment by klaus.birken@gmail.com on 7 May 2014 at 3:25

• Now blocking: #98

[GoogleCodeExporter]

The basic functionality described by this issue is available in Franca 0.9.0:
- ranged integer types can be defined, e.g., "Integer(1,30) month"
- the IntegerTypeConverter is available to preprocess Franca models and replace 
ranged integers by predefined int types and vice versa.

The remaining issues (further changes required in Franca's typesystem etc.) 
will be tackled for Franca 0.9.1, see issue 98.

Original comment by klaus.birken@gmail.com on 7 May 2014 at 3:29

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by klaus.birken@gmail.com on 25 Jan 2015 at 12:33

• Added labels: Type-Enhancement
• Removed labels: Type-RFC