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.
Related
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.
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.
I know it might sound strange but I would like to know one thing in this new world where Microsoft Visual F# is getting into.
There are many application of this language, I am going to learn, regarding parsing, functional programming, structured programming... But what about artificial intelligence?
Are there any applications for Fuzzy Logic? Is F# a good language to be used for Fuzzy Logic applications?
At university we are studying Prolog and similar languages. Prolog is able to create complex query in a very plain and short expresisons (by taking advantage of predicates and facts). Is F# able to do this?
Thank you in advance.
Fuzzy Logic. F# doesn't provide any types for implementing fuzzy logic calculations out of the box, but it is certainly possible to use F# in this domain. The succinctness of F# and the ability to define custom overloaded operators should make code based on fuzzy logic quite nice. I did a quick search and discovered a few articles implementing fuzzy logic in F#:
Fuzzy Logic in F#, Example 1
FuzzyAdvisor - A Simple Fuzzy Logic Expert System in F#
Prolog is a bit different question. The power (and also the weakness) of Prolog come from the fact that it has backtracking built directly in the language. This makes it very nice for implementing search algorithms based on backtracking, but it also a limitation.
F# doesn't have any direct support for backtracking, but it is quite easy to write algorithms based on backtracking using recursion (which is the main control flow mechanism in both F# and Prolog).
Also, it is possible to implement domain specific language for logical programming in F#. This means that you'd implement something like Prolog within F# and then write your search algorithms using this mini-language in F# (possibly using other F# features as needed). You can find more information about similar problems in this question.
F# is a general purpose language with some nice language features, such as computation expression/Monad and quotation. You can assume that it has about the same power as C#.
It is not like Matlab or R, where a lot of pre-implemented libraries are built-in. If you want to implement a Fuzzy Logic library or other AI algorithms from scratch, F# is a very good language for you as its language features make life easier.
But if you just want to use a Fuzzy logic library, then using other languages or specialized systems will be more appropriate because F# or .Net in general does not have very good quality libraries in this aspect.
We have a program which perform graph analysis (namely Maximum-flow problem) on several graphs.
There is also the opportunity to process these in parallel.
There is already a large C# Code base, but we are intending to rewrite a large portion of this. Would it be better to do this type of operation in F#, as opposed to say C#?
Thanks, Pete
I think that this depends largely on the composition of your team - how well do you know F#?
I feel like I am able to develop almost anything more quickly in F# than C#. In particular, highly algorithmic programs are often more concise and readable when expressed in F# thanks to type inference. However, if you don't have much experience with F# there is a significant learning curve, which means that you may be better off sticking to C# if you already know that language well.
C#'s support for doing operations in parallel is roughly equivalent to F#'s, particularly if your task doesn't require accessing any shared mutable state (which seems to be the case for your task). If I understand your problem correctly, you'd just like to run the same operation on multiple graphs at the same time, which ought to be quite easy in either language. If you were trying to parallelize the max-flow algorithm itself, then F# might be a bit easier due to its stronger support for immutable data types. Where F# really beats C# is in doing asynchronous operations, but that seems less relevant here.
What is the added value for learning F# when you are already familiar with LISP?
Static typing (with type inference)
Algebraic data types
Pattern matching
Extensible pattern matching with active patterns.
Currying (with a nice syntax)
Monadic programming, called 'workflows', provides a nice way to do asynchronous programming.
A lot of these are relatively recent developments in the programming language world. This is something you'll see in F# that you won't in Lisp, especially Common Lisp, because the F# standard is still under development. As a result, you'll find there is a quite a bit to learn. Of course things like ADTs, pattern matching, monads and currying can be built as a library in Lisp, but it's nicer to learn how to use them in a language where they are conveniently built-in.
The biggest advantage of learning F# for real-world use is its integration with .NET.
Comparing Lisp directly to F# isn't really fair, because at the end of the day with enough time you could write the same app in either language.
However, you should learn F# for the same reasons that a C# or Java developer should learn it - because it allows functional programming on the .NET platform. I'm not 100% familiar with Lisp, but I assume it has some of the same problems as OCaml in that there isn't stellar library support. How do you do Database access in Lisp? What about high-performance graphics?
If you want to learn more about 'Why .NET', check out this SO question.
If you knew F# and Lisp, you'd find this a rather strange question to ask.
As others have pointed out, Lisp is dynamically typed. More importantly, the unique feature of Lisp is that it's homoiconic: Lisp code is a fundamental Lisp data type (a list). The macro system takes advantage of that by letting you write code which executes at compile-time and modifies other code.
F# has nothing like this - it's a statically typed language which borrows a lot of ideas from ML and Haskell, and runs it on .NET
What you are asking is akin to "Why do I need to learn to use a spoon if I know how to use a fork?"
Given that LISP is dynamically typed and F# is statically typed, I find such comparisons strange.
If I were switching from Lisp to F#, it would be solely because I had a task on my hands that hugely benefitted from some .NET-only library.
But I don't, so I'm not.
Money. F# code is already more valuable than Lisp code and this gap will widen very rapidly as F# sees widespread adoption.
In other words, you have a much better chance of earning a stable income using F# than using Lisp.
Cheers,
Jon Harrop.
F# is a very different language compared to most Lisp dialects. So F# gives you a very different angle of programming - an angle that you won't learn from Lisp. Most Lisp dialects are best used for incremental, interactive development of symbolic software. At the same time most Lisp dialects are not Functional Programming Languages, but more like multi-paradigm languages - with different dialects placing different weight on supporting FPL features (free of side effects, immutable data structures, algebraic data types, ...). Thus most Lisp dialects either lack static typing or don't put much emphasis on it.
So, if you know some Lisp dialect, then learning F# can make a lot of sense. Just don't think that much of your Lisp knowledge applies to F#, since F# is a very different language. As much as an imperative programming used to C or Java needs to unlearn some ideas when learning Lisp, one also needs to unlearn Lisp habits (no types, side effects, macros, ...) when using F#. F# is also driven by Microsoft and taking advantage of the .net framework.
F# has the benefit that .NET development (in general) is very widely adopted, easily available, and more mass market.
If you want to code F#, you can get Visual Studio, which many developers will already have...as opposed to getting the LISP environment up and running.
Additionally, existing .NET developers are much more likely to look at F# than LISP, if that means anything to you.
(This is coming from a .NET developer who coded, and loved, LISP, while in college).
I'm not sure if you would? If you find F# interesting that would be a reason. If you work requires it, it would be a reason. If you think it would make you more productive or bring you added value over your current knowledge, that would be a reason.
But if you don't find F# interesting, your work doesn't require it and you don't think it would make you more productive or bring you added value, then why would you?
If the question on the other hand is what F# gives that lisp don't, then type inference, pattern matching and integration with the rest of the .NET framework should be considered.
I know this thread is old but since I stumbled on this one I just wanted to comment on my reasons. I am learning F# simply for professional opportunities since .NET carries a lot of weight in a category of companies that dominate my field. The functional paradigm has been growing in use among more quantitatively and data oriented companies and I'd like to be one of the early comers to this trend. Currently there doesn't an exist a strong functional language that fully and safely integrates with the .NET library. I actually attempted to port some .NET from Lisp code and it's really a pain b/c the FFI only supports C primitives and .NET interoperability requires an 'interface' construct and even though I know how to do this in C it's really a huge pain. It would be really, really, good if Lisp went the extra mile in it's next standard and required a c++ class (including virtual functions w/ vtables), and a C# style interface type in it's FFI. Maybe even throw in a Java interface style type too. This would allow complete interoperability with the .NET library and make Lisp a strong contender as a large-scale language. However with that said, coming from a Lisp background made learning F# rather easy. And I like how F# has gone the extra mile to provide types that you would commonly see it quantitative type work. I believe F# was created with mathematical work in mind and that in itself has value over Lisp.
One way to look at this (the original question) is to match up the language (and associated tools and platforms) to the immediate task. If the task requires an overwhelming percentage of .NET code, and it would require less shoe-horning in one language than another to meet the task head-on, then take the path of least resistance (F#). If you don't need .NET capabilities, and you're comfortable working with LISP and there's no arm-bending to move away from it, keep using it.
Not really much different from comparing a hammer with a wrench. Pick the tool that fits the job most effectively. Trying to pick a tool that's objectively "best" is nonsense. And in any case, in 20 years, all of the currently "hot" languages might be outdated anyway.