Difference between revisions of "STATOR:Establishing code-base"

From STATOR
Jump to navigation Jump to search
Line 1: Line 1:
 
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].
 
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].
  
== Preferences to main implementation language  ==
+
== Main implementation language  ==
  
 
=== Java ===
 
=== Java ===
  
 
* <b>pros</b>
 
* <b>pros</b>
** a
+
** Many students know it
 +
** Huge standard library
 +
** There is of lot of program analyses related code written in Java. E.g. CPAchecker and Stanse already have established interfaces to CFG representations of programs.
  
 
* <b>cons</b>
 
* <b>cons</b>
** a
+
**  
  
 
=== F# ===
 
=== F# ===
  
 
* <b>pros</b>
 
* <b>pros</b>
** a
+
** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
 +
** We can move to Windows and thus develop STATOR in Visual Studio.
  
 
* <b>cons</b>
 
* <b>cons</b>
** a
+
** 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.
  
 
=== OCaml ===
 
=== OCaml ===
  
 
* <b>pros</b>
 
* <b>pros</b>
** a
+
** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
  
 
* <b>cons</b>
 
* <b>cons</b>
** a
+
** Not many people knows it, but the situation improves.
 
 
  
 
=== C++ ===
 
=== C++ ===
Line 44: Line 47:
 
** a
 
** a
  
== ==
+
== Preferences to features/structure of the internal program representation ==
 +
 
 +
 
  
  

Revision as of 16:09, 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].

Main implementation language

Java

  • pros
    • Many students know it
    • Huge standard library
    • There is of lot of program analyses related code written in Java. E.g. CPAchecker and Stanse already have established interfaces to CFG representations of programs.
  • cons

F#

  • pros
    • May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
    • We can move to Windows and thus develop STATOR in Visual Studio.
  • 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.

OCaml

  • pros
    • May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
  • cons
    • Not many people knows it, but the situation improves.

C++

  • pros
    • a
  • cons
    • a

Java

  • pros
    • a
  • cons
    • a

Preferences to features/structure of the internal program representation

pros of CPAchecker

cons of CPAchecker

pros of Stanse

cons of Stanse

pros of PAGAI

cons of PAGAI

pros of FramaC

cons of FramaC

pros of Predator

cons of Predator