Back in the old days (ie. last year), we used to be able to use theory plugins as a hack to implement custom simplifiers. The Z3 doc even contained an example of "procedural attachments".
My question is very simple; is there any way to achieve the same goal with Z3 4.x?
In particular, I'm interested in a way to provide Z3 with externally computed evaluations for ground terms.
The theory plugins are currently marked as deprecated in Z3 4.x. So, although they can still be used to implement custom simplifier, the user would be forced to use deprecated APIs.
In Z3 4.x, custom simplifiers should be implemented as Tactics. The new build system makes it fairly easy to extend the set of available tactics.
I will try to write a tutorial on how to write tactics inside the Z3 code base.
Of course, in this approach, we have to write C++ code. The main advantage is that the tactic will be available in all front-ends (C, C++, .Net, Java, Python, OCaml, SMT2). Moreover, external developers can contribute their tactics to the Z3 codebase and they will be available for all Z3 users.
We also plan to support an API for creating a simplifier tactic based on callbacks provided by the user. This API would allow users to write "custom simplifiers" in their favorite programming language. This new API is conceptually simple, but there is a lot of "hacking" needed to make it available in every front-end (C++, .Net, Java, Python, OCaml) . It would be great if some external developer is interested in implementing and maintaining this feature. I'm sure it would benefit many users.
Related
I'm completely new to z3. I wonder what the difference is between the two inputs, Are C API more problematic than standard inputs SMTLIB2 for z3? I would appreciate it if you could answer_(:з」∠)_
I'm not sure what you mean by "problematic." You'd use the C-API if you want to integrate z3 into a C/C++ based framework. You'd use SMTLib if you want a common language understood by many solvers, not just z3. So, it really depends on what your goals are.
If you're just experimenting with it, I'd advise using an interface in a higher level language like Python, as it is much easier to get started. SMTLib is generally not intended for human consumption, but rather generated by other programs. Only use the C/C++ API if you have some other requirement that requires you to stay in C/C++.
Long story short, it really depends on what your goal is; if you tell us more about what your use case is, we can recommend something more specific.
They are from Microsoft and seem like they are proof assistants? Besides syntactical differences are there practical aspects that make them different from one another (say ability to do automation, expressive power, etc)? I am new to formal verification.
Edit: I am not asking for which one is better, am merely interested in a technical comparison between the different features offered by these tools. I'm looking for something like this
Each tool has a unique design, and is built and influenced by different people with different goals and philosophies, but the authors are all friends and have sat within a few offices of each other for many years.
Rustan Leino designed Dafny as a successor to many of the systems he built before including ESC Java, and Spec#.
Dafny is based on a Java or C# like imperative language with the ability to write Hoare logic style state invariants, this allows users of the languages to verify properties about methods, and objects that use mutable state, loops, arrays, and so on. Dafny's core theory is a custom program logic mostly designed by Rustan and a handful of collaborators. Dafny discharges the verification conditions it generates by compiling them to Boogie an intermediate verification language, which in turn compiles them into queries which are passed to an SMT solver such as Z3 or CVC4 to discharge.
Dafny's design goal is to feel very similar to imperative object oriented languages users are familiar with the added ability to verify your programs.
F* is based on a new type theory designed by Nikhil Swamy and collaborators, it began as an ML like programming language with the addition of refinement types which were discharged in the style of Dafny, but has evolved substantially in the past few years due to numerous outside additions, as well as influences from Dafny, Lean, LiquidHaskell, and so on.
F*'s also translates its verification conditions to SMT solvers like Dafny, but does not use an intermediate verification language like Boogie. F* has recently gained the ability to use tactics heavily influenced by the Lean tactic language.
F*'s main innovation over tools like Dafny and other refinement types is the use of Dijkstra Monads a way to describe the "effect" of code, giving the effect designer control over the verification conditions generated. DMs allow users to reason at different levels, for example code in the Pure effect can not use state, or throw exceptions and the user is able to ignore effectful features they don't use.
Lean's design is heavily influenced by Coq and other intensional type theories and is much more similar to them, the goal of Lean is to marry the best of automated and interactive theorem provers, by bringing techniques from the automated (SMT) world to the type theory world. It has very powerful meta-programming abilities, and has been gaining more and more automation. Lean does not require an SMT solver and reimplements many of the core procedures in a specialized way for Lean's type theory.
You can view F* and Lean as covering to a similar spaces but emphasizing different ways of getting there.
I am happy to elaborate more if this doesn't clarify.
Source: core developer of Lean, developer of F*, and sometime user and contributor to Dafny, worked at MSR for ~7 months and personally know all of the tool authors.
I'm starting to study Dart. It seems a nice language and in some aspects a real improvement over JavaScript. Since it claims to come with "batteries included" and to be meant for "structured web apps", though, I fail to understand how to actually structure a web app with it. Almost all the tutorials concentrate on language features, but Dart is quite simple and with many familiar bits, so that's the easy part.
Recently I fell in love with AngularJs. Now routing, two way binding, nested scope, clean separation of concerns... This actually means "structured" to me. But all the Dart examples I find are about selecting HTML elements and attaching listeners to them. This is old-style jQuery-like web programming and quite frankly the opposite of what I think of when I read "structured".
I don't want to compare a language and a framework and I know that Angular Dart is out, but I fear I'm missing something of vanilla Dart, because if it's all about a shorter syntax for lambdas, class based OOP vs prototypical OOP and the like, I don't see how it's supposed to be a game changer: there are many other languages that provide an alternative JS syntax (à la CoffeeScript) and compile to it, and they don't come at the price of losing a perfect integration with existing JavaScript libraries and tools.
Sure, it has optional static typing, which may be great, but this comes more to a matter of preferences. I'm a full time Python and Ruby developer and I'm perfectly fine with dynamic languages. Is this what they mean by "structured"?
Thanks for any clarification that will eventually come.
I work on AngularDart and have some experience structuring web apps.
When building a web app in Dart you would pick a web app framework, for example AngularDart or polymer.dart. Web app frameworks have a lot of opinion which is something that doesn't fit in the core libraries. In that respect, "vanilla Dart" is fairly vanilla.
Since I'm most familiar with Angular, I'll discuss the Angular + Dart combination. However, the rest of this post is also true for polymer.dart.
Angular provides a lot of structure to your app. We've been able to provide a similar structure for both Dart and Javascript. The concept of directives, data binding and dependency injection exist in both.
Dart provides more structure and we've been able to use that structure while building AngularDart. e.g. the directive API is defined in terms of annotations which means that IDEs understand them and can help you code.
There are a number of "structure" features in Dart. One of my favourites is tooling. With types and annotations comes better tooling support.
Types in Dart are most useful when combined with tools. Auto-complete is great but for large web projects, static analyze is even better. For example, in AngularDart, since directives are annotated classes, we can assert that the annotation is correct. Even more interesting is the potential to build tools. In AngularDart, we have a tool that extracts and analyzes all directives. This type of tooling is possible in Javascript but easy and supported by the language in Dart.
libraries, packages
integrated dependency management with pub package manager
class based instead of prototype based
scopes of variables as one would expect in a modern language
static syntax check
better tooling support like code completion
I'm currently reading Real-World Functional Programming, and it briefly mentions in-fix operators as being one of the main benefits of custom operators. Are there any sort of standards for when to use or not use custom operators in F#? I'm looking for answers equivalent to this.
For reference, here is the quote to which #JohnPalmer is referring from here:
3.8 Operator Definitions
Avoid defining custom symbolic operators in F#-facing library designs.
Custom operators are essential in some
situations and are highly useful notational devices within a large
body of implementation code. For new users of a library, named
functions are often easier to use. In addition custom symbolic
operators can be hard to document, and users find it more difficult to
lookup help on operators, due to existing limitations in IDE and
search engines.
As a result, it is generally best to publish your
functionality as named functions and members.
Custom infix operators are a nice feature in some situations, but when you use them, you have to be very careful to keep your code readable - so the recommendation from F# design guidelines applies most of the time. If I was writing Real-World Functional Programming again, I would be a bit less enthusiastic about them, because they really should be used carefuly :-).
That said, there are some F# libraries that make good use of custom operators and sometimes they work quite nicely. I think FParsec (parser combinator library) is one case - though maybe they have too many of them. Another example is a XML DSL which uses #=.
In general, when you're writing ordinary F# library, you probably do not want to expose them. However, when you're writing a domain specific language, custom operators might be useful.
I'm trying to find a straightforward way to consume arbitrary iOS libraries from MonoTouch. At the moment, I need this calendar functionality, but the question applies to any such component.
I've read the Xamarin article on creating iOS bindings, but the process of building these bindings looks so complex (and tedious and likely error prone) that I think it would actually be easier for me to re-implement the given functionality in C# from scratch than it would to go through this process. Creating these bindings would require a deep dive into ObjectiveC, and I'm using Xamarin precisely so I don't have to do that.
As it stands, I am torn because I really want the ability to access some iOS libs, but don't have the time to master this process enough to create these bindings. Is there any other way to access these libraries?
(I wonder if there is or could be any sort of automated binding generator? It seems to me that 95% of the work is boilerplate translation of ObjectiveC headers to C# idioms, and an automated tool could do this, and then the final tweaking could be done by hand.)
You can:
Consume the ones that are already bound: you can find many on github, in particular in monotouch-bindings, and in the (just announced) Xamarin's Components Store;
Bind them yourself. That does require some Objective-C knowledge. Some tools/scripts exists but, in the end, the manual by hand editing is where the Objective-C knowledge is needed. There are general unit test (e.g. for Touch.Unit) that you can re-use that will dramatically reduce the number of bugs in them (blog post will be coming up soon to describe them in details).
Convert (or write from scratch) some into C# components;