Skip to content
Snippets Groups Projects
Commit 5dadec35 authored by Gusztav Adamis's avatar Gusztav Adamis
Browse files

Commented with Ericsson opinion after internal evaluation

parent 788cff9e
No related branches found
No related tags found
1 merge request!1Gusztav.adamis cf10218e patch def5
Pipeline #11568 passed
Stage: build
Stage: test
Stage: deploy
Hide whitespace changes
Inline Side-by-side
Showing
with 39 additions and 34 deletions
meetings/2024-11-19.md
+ 39
− 34
View file @ 5dadec35
......@@ -15,14 +15,14 @@
We discussed reducing the size of the TTCN-3 core language by:
* moving predefined functions, useful types and such into some kind of standard
library document.
library document.--- NO! WHY? What would be the advantage of it?
* Removing or deprecating features that could be substituted by other features
(e.g. arrays).
(e.g. arrays). --- If it will be only a shorthand of record of length (fixed value) then ok
* Moving features that are not used by the majority of users, but are
complementing the language into extension documents (e.g. procedure based
communication).
* Introducing new language concepts, that simplify the language (e.g. advanced
parameterization, closures, ...).
parameterization, closures, ...). NO, more details (adv/disadv) needed
**Extensions**
......@@ -43,7 +43,7 @@ A combination of various strategies is probable:
# Coding style
We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests).
We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests). -- Isn't it too large work?
# Templates
......@@ -93,14 +93,14 @@ template Point t := function (integer p) return Point {
};
```
Details need to be worked out in future discussions.
Details need to be worked out in future discussions. -- if possible :)
## Special Template Symbols
`all from`, `permutation`, `complement`, `subset`, `superset`, ..., do not need
to be part of the core language. They could be implemented as library
functions, as language extensions or even by user-defined dynamic matching.
functions, as language extensions or even by user-defined dynamic matching. -- Only to be moved to extension, but NOT functions, user-defined (???) dynamic (???) matchning. Semantics and syntax must be kept.
## Inline Templates
......@@ -111,11 +111,12 @@ annotations could be promoted to a type-conversion operator and template
literals are already part of the language.
//since now there is no type-conversion operator this is not true -- AG
it is NOT type-conversion, but some kind of casting; inline templates are needed, used frequently
## Modified Templates
Modified template and modified inline template syntax might be unified and simplified.
Modified template and modified inline template syntax might be unified and simplified. - HOW?
## List Templates
......@@ -139,7 +140,11 @@ var template integer i := 1;
Another simplification is to remove the differentiation between values and
templates all together. For example: `var integer i := 1` would a shorthand for
`var template(value) integer i := 1`.
This could also improve on compiler-pleasing through `valueof` and on
I guess it would be useful in the opposite direction value:= (value)template - discussion needed, for us the existing definition is ok
This could also improve on compiler-pleasing
// it is not a point how complicated the compiler is; the language shall be easy-to-use
through `valueof` and on
operations such as `omit`, `present`, ...
......@@ -148,22 +153,22 @@ operations such as `omit`, `present`, ...
We discussed several aspects of the type system to identify opportunities for
simplification:
* Substitute `anytype` with `any`. Type switch from OOP extension would be a
good addition.
* Substitute `anytype` with `any`. Type switch (---?????) from OOP extension would be a
good addition. - anytype will be in an extension; not to make backward incompatible solutions just for fun; would clash with any timer, any component, etc.
* Arrays
* remove custom indexing.
* should become short-hand notation.
* remove custom indexing. -- ok
* should become short-hand notation. -- ok
* `set` and `set of` should be reviewed (compatibility with records,
replacement possible?)
replacement possible?) -- record of and set of are different ROI := {1,2,3} SOI1:={1,2,3} SOI2 := {1,3,2} SOI1==SOI2 but ROI != SOI2
* Should automatic typing be extended to unions and generics or should it
rather be moved to an extension?
rather be moved to an extension? NO
* Map type:
* Could be harmonized with `HashMap` from OOP extension.
* One could find overlap of `unmap` operations confusing.
* Some corner cases need clarification (e.g. `h[*] := {}`).
* One could find overlap of `unmap` operations confusing. -- Unmap can be used for ports and maps; new keyword would have been better; but now will cause backward incompability
* Some corner cases need clarification (e.g. `h[*] := {}`). ---????
* Sections describing type system could be simplified by introducing better
type terminolgy (subtyping, type-alias, equality, assignment, component
variables, ...).
variables, ...). -- If only definition harmonisation, then ok; if meaning changes, not
## List Types
......@@ -204,7 +209,7 @@ function equal(record of integer a, record of integer b) return boolean {
}
return true
}
```
``` Shall be defined clearly, if the last elements are undefined it counts in the size/length or not
```ttcn3
var record of integer a := {1,9};
......@@ -236,19 +241,19 @@ removed. Further discussion is needed.
`checkstate` is used to wait for a port to be ready. Further discussion is
needed, whether `checkstate` could be improved or even removed.
The `receive` part of `check` operation could be removed probably.
The `receive` part of `check` operation could be removed probably. //check(template) is a shorthand of check(receive(template)) ?? shall be checked if parsr can handle it in a simple way
The `trigger` could be substituted by `check`.
The `trigger` could be substituted by `check`. // no, the trigger takes the value out of the queqe, while check do not
Decoded field references, `decmatch`, `@decode` could be simplified. It needs to be checked whether `=>` can be removed.
Decoded field references, `decmatch`, `@decode` could be simplified. It needs to be checked whether `=>` can be removed. //=> is used in OOP for a different purpose. One of them shall be be modified (probably in OOP)
We discussed whether `goto` could be removed or substituted by named loops.
Component's `call` operation might be moved into an extension document.
External actions (`action`) do not need to be part of the core language.
External actions (`action`) do not need to be part of the core language. //Shall be, this is how something can be written to screen during execution
Modifiers (pe.g. `@deterministic`, `@nocase`, `@nodefault`, ...) or often overlooked. Further discussion is needed whether there's opportunity to generalize them.
Modifiers (pe.g. `@deterministic`, `@nocase`, `@nodefault`, ...) or often overlooked. Further discussion is needed whether there's opportunity to generalize them. //@deterministis - fuzzy/lazy; the other two are useful
Attributes might be simplified:
* remove `display`
......@@ -258,12 +263,12 @@ Attributes might be simplified:
## Module organization
`import` will be simplified if possible.
This would make `group` superfluous. However groups are used to structure
`import` will be simplified if possible. // supported only import all
This would make `group` superfluous. However groups are used to structure //group of instructions are useful
modules and groups are also used by some language mappings.
Simplifying import would further require to discuss importing of imports.
Visibility features (`friend`, `private`, `protected`) are used by testers,
Visibility features (`friend`, `private`, `protected`) are used by testers, //in many other languages these 3 categories exist
seldom. It's used primarily by framework developers. Possible improvements need
further discussion.
......@@ -281,8 +286,8 @@ Language features that were neither removed nor moved into the core, will
probably be merged into a common extensions document.
* Performance and real-time extension:
* `wait` --> core
* `timestamp` --> core
* `wait` --> core //discussion needed
* `timestamp` --> core //discussion needed
* remaining features --> extension
* Configuration and Deployment features mostly stay as they are.
* Advanced parameterisation:
......@@ -291,14 +296,14 @@ probably be merged into a common extensions document.
* Value parameterisation of types: Could be removed.
* Behaviour types:
* Behaviour types (and closures) will probably move to core to help
simplification.
* Deferred behaviour will be removed.
simplification. // Further rationale is needed, just for fun is not enough
* Deferred behaviour will be removed.
* Continuous signals will probably go to historic state
* Advanced matching:
* Dynamic matching will probably move to core.
* Dynamic matching will probably move to core. //needs further discussion
* Other features need further discussion.
* Object oriented features:
* Exception-feature will probably move to core
* Some type operations (`=>`, `select class`) probably, too
* Exception-feature will probably move to core //But how?
* Some type operations (`=>`, `select class`) probably, too //select class without class?; => is used for another purpose in core
* If and in what form user defined object will be merged into core is not
clear yet.
clear yet. // What is user defined object?
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment