Difference between revisions of "STATOR:Establishing code-base"
Jump to navigation
Jump to search
Marek Trtik (talk | contribs) |
Marek Trtik (talk | contribs) |
||
Line 17: | Line 17: | ||
* <b>pros</b> | * <b>pros</b> | ||
** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ||
− | ** We can take a C front end from tools like CPAchecker | + | ** We can take a C front end from tools like CPAchecker, Stanse, Bugst, or Predator with minimal effort. It only requires to dump internal CFG representations of the tools to disc and load them into equivalent data structures syntactically expressed in F#. |
** When we are in .NET we can freely use any other .NET language (C#, Visual basic, managed C++, ...). Since many students know C# and C# is similar to (or better then) Java, so from this point of view F# is better choice then Java. Moreover, there is also implemented integration of non-managed languages, but portability is then a question. | ** When we are in .NET we can freely use any other .NET language (C#, Visual basic, managed C++, ...). Since many students know C# and C# is similar to (or better then) Java, so from this point of view F# is better choice then Java. Moreover, there is also implemented integration of non-managed languages, but portability is then a question. | ||
** We can move to Windows and thus develop STATOR in Visual Studio. (Visual Studio can really speed-up development (e.g. excellent debugging, edit&continue, ...) | ** We can move to Windows and thus develop STATOR in Visual Studio. (Visual Studio can really speed-up development (e.g. excellent debugging, edit&continue, ...) | ||
Line 30: | Line 30: | ||
* <b>pros</b> | * <b>pros</b> | ||
** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ||
− | + | ** We can take a C front end from tools like CPAchecker, Stanse, Bugst, or Predator with minimal effort. It only requires to dump internal CFG representations of the tools to disc and load them into equivalent data structures syntactically expressed in OCaml. | |
− | ** We can take a C front end from tools like CPAchecker | ||
* <b>cons</b> | * <b>cons</b> | ||
+ | ** OCaml development environments are still immature and primitive. This can slow down whole development. | ||
** Not many people knows it, but the situation improves. | ** Not many people knows it, but the situation improves. | ||
Revision as of 16:37, 25 July 2014
Here we list pros and cons of all our approaches towards establishing STATOR's code-base. All pros/cons are listed in the order from the most important to the least one. We further assign for all listed pros/cons a global "importance level", which is a number in [1,...,10].
Contents
Main implementation language
Java
- pros
- We can take a lot of code from tools like CPAchecker and Stanse with minimal effort.
- Huge standard library
- Many students know it.
- cons
- May slow down implementation of program analyses, since symbolic manipulations of data structures may require more programming effort then in languages like OCaml or F#.
F#
- pros
- May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
- We can take a C front end from tools like CPAchecker, Stanse, Bugst, or Predator with minimal effort. It only requires to dump internal CFG representations of the tools to disc and load them into equivalent data structures syntactically expressed in F#.
- When we are in .NET we can freely use any other .NET language (C#, Visual basic, managed C++, ...). Since many students know C# and C# is similar to (or better then) Java, so from this point of view F# is better choice then Java. Moreover, there is also implemented integration of non-managed languages, but portability is then a question.
- We can move to Windows and thus develop STATOR in Visual Studio. (Visual Studio can really speed-up development (e.g. excellent debugging, edit&continue, ...)
- cons
- Not many people knows it, but the situation improves.
- Development in Mono can be less comfortable. Also support of F# in Mono known to us yet. Similarly, state of standard library is not know.
- Portability mostly depends on qualities of Mono.
OCaml
- pros
- May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
- We can take a C front end from tools like CPAchecker, Stanse, Bugst, or Predator with minimal effort. It only requires to dump internal CFG representations of the tools to disc and load them into equivalent data structures syntactically expressed in OCaml.
- cons
- OCaml development environments are still immature and primitive. This can slow down whole development.
- Not many people knows it, but the situation improves.
C++
- pros
- a
- cons
- a