|Anonymous | Login | Signup for a new account||2021-05-11 11:09 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000835||Taste||[All Projects] OpenGeode||public||2019-02-28 16:03||2019-03-04 09:56|
Use of NEWTYPE in SDL
I would like to be able to declare my own types in SDL, for example:
DCL myList T_MyIntList;
OpenGeode accepts the NEWTYPE definition (which is legal SDL) but barfs on the declaration:
[ERROR] Type T_MyIntList not found in ASN.1 model - "myList T_MyIntList"
It would be good to be able to use this SDL feature. As things currently stand, I have to include definitions in my ASN.1 data model that are only needed for the internal implementation of the SDL model.
A good example is emulating the "save" symbol:
The SeqOf type is only ever needed in the SDL, but since it appears in the ASN.1, it becomes available as a type across the whole project. It also gets its own encode/decode functions as if it were a message type.
|Tags||No tags attached.|
There are various things to consider here.
First of all, yes, I agree on the fact that local types are useful when you consider the context of a TASTE application. It is convenient to declare types without having to come back to the dataview.
(in the context of standalone opengeode applications, however all types are local anyway.)
There are however some questions and issues.
1) newtype/syntype/synonym (SDL types) vs native ASN.1 type (syntax-wise)
In most cases, the semantics for the types themselves is similar. There is one notable exception for arrays. SDL allows to index arrays with anything:
This is very powerful - the second one is basically like a Python dictionary (or a map).
But maps don't exist in ASN.1, so if maps and enumerated indexing is what you need, then the SDL syntax is indeed the only option, and other part of the tool to support them would be modified. This is not the most important issue.
SDL also allows to define operators for the custom types, so that if you e.g declare a type named Stack you can define operators Pop and Push that are associated to it. It's useful in some cases but standard procedures can do the same thing (just less OO).
SDL additionally supports the definition of axioms that describe some kind of contracts associated to the types and their operators. This is extremely powerful (in theory) and could be translated to provable SPARK contract at code level.
The tool could therefore support the SDL syntax or directly ASN.1 syntax to declare new types within SDL textboxes. SDL syntax would offer more power but ASN.1 would make it more consistent (only one syntax to learn).
In both cases, we need to define a "reasonable" subset to be supported. Axioms are in the spirit of TASTE but clearly out of short-term scope. Re-implementing a complete ASN.1 parser would be extremely complicated too.
2) Code generation
When you work with variables, the tool generates code that uses the ASN1SCC data structures.
For example, your array:
needs to be internally translated to
We need to feed this to the ASN.1 compiler to get a structure that is identical to native ASN.1 types and avoid generating custom types in the target language. Otherwise we would need different implementations of the operators (append, length..) depending on the type.
But if we do that, we cannot support maps and enumerated-indexed arrays, since no equivalent types exist in ASN.1
The simulator is in Python and uses a interface with the generated code using a "ctypes" interface (handled by the DMT tools). This allows to work with ASN.1 from Python to exchange data with the SDL model, fill in the value with the ASN.1 GUI (Value Editor), etc.
The interfaces (PI and RI) are always in ASN.1 but the simulator also allows to inspect and modify all internal variables of the model (this will also be used for model checking).
If we introduce non-ASN.1 types, all this would stop working and would require major refactoring.
CONCLUSION (for now)
The only custom/local types that are reasonably easy to implement are types that can directly map to ASN.1 types (as described in point 2 above).
The ASN.1 syntax would use underscores instead of dashes, and would not be case sensitive, making things nicer to the user.
I did a proof of concept already in the latest version of opengeode (2.0.23)
to get this version and see the example:
|2019-02-28 16:03||shd01||New Issue|
new => assigned
|2019-02-28 16:03||shd01||Assigned To||
|2019-03-04 09:56||maxime||Note Added: 0003579|
|Copyright © 2000 - 2011 MantisBT Group|