cuplv / cuanto Goto Github PK

We need to define the subset of Java that we want to support in the current iteration in scoot.

The initial idea is to handle:

• Integer types and their operations
• Boolean types and their operations
• Access static fields
  An idea is to look at the subset of MiniJava: http://www.cs.tufts.edu/~sguyer/classes/comp181-2006/minijava.html

Once defined the subset we have to identify the Jimple statments that we want to support.

Tasks:

• Identify the Jimple syntax for the restricted language
• Identify the classes (and other restriction) implementing the syntax

• Need to brew cask install nix on Mac. Add to CONTRIBUTING.

The goal of this task is to be able to run the following program in a concrete interpreter:

class C {
    int m(){
        int x = 3+1;
        int y = 4;
        return x*y;
    }
}

Now we import soot through the paderborn nightly build web site.
We should understand if we can run the CI as soon as the remote jar for soot changes to understand if soot does not break our tests.

Maybe add it in a "Troubleshooting" section in the CONTRIBUTING.md file.

There are several implementations of SMT we can use for logic representations and model-checking in Cuanto.

• scala-smtlib from EPFL-LARA, developed in service of their Leon and Inox projects
• mq-scala-smtlib, originally forked from scala-smtlib but largely redesigned by MQ for their Skink project
• scala-smtlib-interface, less developed than scala-smtlib, but with some particular design advantages which may or may not be useful to us
• java-smt, much more mature and well-documented than the others, but with a Java interface

For now we are proceeding using scala-smtlib, but it's worth understanding what concrete theoretical and operational features each of these options give us, so let's explore that.

I believe we should just push through and implement the concrete interpreter to handle the following features.

• Control flow
• Functions
• Objects/Dynamic dispatch
• Exceptions
• Primitive data types (Float, Bool, Double etc)

Excluded language features:

• Concurrency
• Reflection
• Class loading
• System Calls

My argument for this list is that I believe all the Jimple commands will be covered by the list of included features. This will drive development and documentation of our interface. I believe all of the excluded features show up as method invocations of library code.

See https://gitlab.com/cuplv/csci7135-s17/issues/34

Some things about implementing let-binding. This can easily get to bike-shedding, so let's try to refrain (myself included). This is about syntax, and I can't believe I am about to start a conversation about it 😄 when I always that this is not what PL is about. But there are some things that are bit tricky.

The underlying principle for JavaScripty is that we want to accept syntactically valid JavaScript, though we may accept more programs to be more natural with the abstract syntax. I don't want a separate statement and expression language in the abstract syntax, so JavaScript's statements get collapsed to expressions. (And I guess perhaps that internally for real interpreters, that's the case as well, and the statement-expression divide is simply at the concrete syntax level. For example,

if (true) { true } else { false }

at the top-level in node yields true.)

So, we want to support { let x = 3; x } or

{ let x = 3
  x }

I think the simplest implementation is to treat the tokens let x = 3, ;, and x as a sequence of expressions with ; being the "no-op" expression, which would permit the above two programs, but it would also parse the concrete syntax { let x = 3 x } into the same abstract syntax, which is a bit weird.

A still relatively simple alternative (and one that I implement in 3155) is to stratify into statements and expressions and to consider declarations like let x = 3 as statements. Then, ; becomes the empty statement (and not expression). So{ let x = 3 x } becomes syntactically invalid because 3 x is not an expression. We can still embed statements in expressions as blocks { _stmt_ }, so we can still express everything in the abstract syntax. I believe this is what Scala does (though I have not consulted the spec). The cost is a little bit greater disconnect between the concrete and abstract syntax.

I am leaning towards this latter option (slightly more complex but closer to JavaScript).

PR: #17

The goal of this issue is to understand how cuanto can support Verivita.

The questions that we should try to answer are:

• How can we support the next steps of the project? What do we need to support dynamic verification/static verification/learning?
• What did we implement in Verivita (trace runner, the verifier) that should be refactored/improved/reused across projects?

We want to write an analysis to figure these questions and identify the functionalities that we want to refactor or implement from scratch in cuanto.

We want to have clear top-level languages corresponding to

• numerical constraints
• lambda-calculus
• imperative procedural
• core JavaScript

Please correct me if I am wrong but my understanding is that the Apron work is put on indefinite hold for now. In light of this is there a way we can we set things up so we can check out/compile/test develop without installing Apron?

We should figure out a way to retain this code without having it add to the complexity of using our library. I propose we move it into either a submodule or another project which relies on cuanto as a dependency.

When running the "Push" Travis tests for japron-fresh, we got a failure in the FixFunSpec. The failure did not appear during the second "PR" test run, which makes me think that this failure is non-deterministic (meaning it might have been hanging around a while!).

The particular test uses ScalaCheck to generate random test cases, so there must be some form of expression that ScalaCheck produces very rarely which sends the eval function into infinite recursion.

[info] FixFunSpec:
[info] plusexpr.pretty
[info] - should pretty-print N(1) to 1
[info] - should pretty-print Neg(N(2)) to (-2)
[info] - should pretty-print Plus(N(1),N(2)) to (1 + 2)
[info] - should pretty-print Neg(Plus(N(2),N(3))) to (-(2 + 3))
[info] plusexpr.eval
[info] - should evaluate N(1) to 1
[info] - should evaluate Neg(N(2)) to -2
[info] - should evaluate Plus(N(1),N(2)) to 3
[info] - should evaluate Neg(Plus(N(2),N(3))) to -5
[info] - should not crash on arbitrary expressions *** FAILED ***
[info]   StackOverflowError was thrown during property evaluation.
[info]     Message: "None"
[info]     Occurred when passed generated values (
[info]   
[info]     )

• Failing build log
• Succeeding build log (run immediately after on the same code)

I'm documenting some concerns from a recent review. The modular parser system in place in jsy is very powerful and composable, but built bottom-up. This allows arbitrary combinations of program components, but requires implementers to be careful about program-wide structure, like making sure that a new function definition parser uses a statement parser that can handle multiple statements, and works within any module-level code.

I don't think this is a priority at the time of this writing, but eventually we may want some main parser packages that handle the global structure of a program and delegate to individual parsers that are written for their section of the code. Within a section, we'll still want all the composability that exists now.

Comment the implementation of implicit.scala to document how to use reflection in scala.

implicit.scala

Concrete goal: implement constant propagation in Scoot

There's a lot of analysis infrastructure in the Aiwala repo that could be a useful component for cuanto. I will look into what makes sense to add, refactor, or combine with existing soot infrastructure, and then make a PR proposal for people to consider.

Get rid of hardcoded paths.

Things tried:

• Nix plugin looks brittle and outdated looking at the issues but may still be worth trying: https://github.com/NixOS/nix-idea

• run intellij from nix shell: dependencies seem broken. More debugging could be done here.

  • the intellij executable that can be run from the shell in OSX is here: /Applications/IntelliJ IDEA.app/Contents/MacOS/intellij

When we want "wrappers" that would parallel an existing project, we create a cuanto.existingproject name package and inside should parallel existing project package naming (e.g., cuanto.soot.jimple).

It the code is conceptually a client of the existingproject, then use a separate package (e.g., cuanto.scoot).