Let's say I have several proofs based on data structure (or lemma) A. Then, I refactored A to A', is there a general practice / tool facility for Coq to know all proofs are impacted by my refactoring?
Thank you for shedding some light on this matter.
edit1: thank you for all your suggestions, I will give them a try, and get back on this.
Another tool that might be useful is dpdgraph, which makes it possible to display all the usage dependence between various objects.
There is no such tool available, as far as I am aware. What I usually do is to refactor the code and try to repair it. Because of Coq's proofs and typing discipline, once the code compiles again, it is usually the case that it works.
You might want to take a look at PUMPKIN PATCH (GitHub repo). Here's a quote from the project readme file:
This is a prototype plugin for finding patches for broken Coq proofs. To use PUMPKIN, the programmer modifies a single proof script to provide an example adaptation of a proof to a change. PUMPKIN generalizes this example into a reusable patch which can be used to fix other broken proofs.
Not sure if this is exactly what you're looking for but it might be of interest.
Related
In the paper Declarative UIs are the future -- and the future is comonadic by Phil Friedman, he makes the claim, when introducing the cofree comonad that:
...this approach is reminiscent of the approach taken in the Halogen user interface library.
This claim is echoed in several other places, I assume originating from this paper, and until recently I just put this on my "think about more later" pile, because I was not familiar with how Halogen worked. However, now that I am somewhat familiar with Halogen, I tried looking into this matter more. However, even now that I understand the basics of Halogen, this claim is still not immediately obvious to me, and at least as far as I've searched, I have not found anywhere online that attempts to elaborate on or explain this connection between the cofree comonad and Halogen.
Has anyone attempted to actually build a UI framework using the cofree comonad? If not, could someone at least help explain this idea a little bit better? For instance, by taking some basic example of a component in Halogen, and constructing a structure that describes that component using a cofree comonad? Or even better, describing how these "cofree components" can be combined in a similar way to how Halogen components can be composed?
The paper says "Under certain conditions on f, the Co (Cofree f) monad is isomorphic to a free monad which is determined by f." and HalogenM is a free monad. I don't think there's more to it than that.
I am using Eclipse (version: Kepler Service Release 1) with Prolog Development Tool (PDT) plug-in for Prolog development in Eclipse. Used these installation instructions: http://sewiki.iai.uni-bonn.de/research/pdt/docs/v0.x/download.
I am working with Multi-Agent IndiGolog (MIndiGolog) 0 (the preliminary prolog version of MIndiGolog). Downloaded from here: http://www.rfk.id.au/ramblings/research/thesis/. I want to use MIndiGolog because it represents time and duration of actions very nicely (I want to do temporal planning), and it supports planning for multiple agents (including concurrency).
MIndiGolog is a high-level programming language based on situation calculus. Everything in the language is exactly according to situation calculus. This however does not fit with the project I'm working on.
This other high-level programming language, Incremental Deterministic (Con)Golog (IndiGolog) (Download from here: http://sourceforge.net/p/indigolog/code/ci/master/tree/) (also made with Prolog), is also (loosly) based on situation calculus, but uses fluents in a very different way. It makes use of causes_val-predicates to denote which action changes which fluent in what way, and it does not include the situation in the fluent!
However, this is what the rest of the team actually wants. I need to rewrite MIndiGolog so that it is still an offline planner, with the nice representation of time and duration of actions, but with the causes_val predicate of IndiGolog to change the values of the fluents.
I find this extremely hard to do, as my knowledge in Prolog and of situation calculus only covers the basics, but they see me as the expert. I feel like I'm in over my head and could use all the help and/or advice I can get.
I already removed the situations from my fluents, made a planning domain with causes_val predicates, and tried to add IndiGolog code into MIndiGolog. But with no luck. Running the planner just returns "false." And I can make little sense of the trace, even when I use the GUI-tracer version of the SWI-Prolog debugger or when I try to place spy points as strategically as possible.
Thanks in advance,
Best, PJ
If you are still interested (sounds like you might not be): this isn't actually very hard.
If you look at Reiter's book, you will find that causes_vals are just effect axioms, while the fluents that mention the situation are usually successor-state-axioms. There is a deterministic way to convert from the former to the latter, and the correct interpretation of the causes_vals is done in the implementation of regression. This is always the same, and you can just copy that part of Prolog code from indiGolog to your flavor.
Could anyone give me more information about the first-class module in Coq? I know that module in Coq is not a first-class. I would like to know the reason why? and is it possible that in the future module in Coq can be first-class?
Thank you very much
I’m not certain, but as I understand it it comes from essentially two points:
Coq is conservative. Because some of its main applications are in verification, Coq mostly restricts itself to constructs whose semantics are reasonably well-understood.
In the dependent-types setting, first-class modules are rather subtle and not fully understood. In particular, how much of the computational/reduction behaviour of definitions do you want visible outside a module? If none at all, then this is already available, as record types. But if some or all of the reduction behaviour is visible, then it’s hard to quantify exactly how much is, so it’s quite hard to analyse the semantics of the resulting modules.
I’m not an expert on the relevant literature, so I may well be wrong about 2, but I’ve gotten the impression that this is the basic situation.
I've been playing with go for a week and something I miss from C is preprocessor macros.
What could I use to get this feature, besides hacking a build script that pipes go files through clang -E ?
As mentioned in the comments, build flags are probably the best way to solve whatever you need. For example, if you wanted to have some features only available in development, use a dev flag:
File constants_dev.go:
// +build dev
const DEVELOPMENT = true
File constants_pro.go
// +build !dev
const DEVELOPMENT = false
Then in your code, just do a simple if DEVELOPMENT { blah... }. I find this much more readable than any preprocessor. This can get quite messy if you have a lot of build flags, but at that point you should probably be using command-line arguments instead.
In your comment, you mentioned duplication of code. If your code is really that repetitive, you should probably be putting it in a function anyway, or possibly restructure code to reuse the bits that are repetitive. Personally, I find that anything beyond simple boolean checks ends in hard to maintain code, especially with C-style macros.
It's the same thing with generics. In one Java library I've used, the class signature was something like this:
class Thing<A, B, C, D, E>
The library wasn't very well documented, so I had to read a significant amount of the code (both implementation and code that uses the library) to understand what was going on.
In Go, the language forces a style that generally leads to better, self-documenting code. I think the Go developers omitted things like a preprocessor and generics to avoid temptation to write hard to maintain, but clever, code.
I would advise you to try out the Go way before looking back on old idioms that you used before. I think you'll find that most of what macros and #defines were used for are largely irrelevant.
I think cpp, m4 or whatever may fulfill your desire to have Go preprocessed. If it's a good idea or not is a decision of yours, but be warned that any preprocessing is a substantial obstacle for adoption of any published Go code. (And for example, the build being dependent on makefiles is the same story.)
I have taken over a large code base and would like to get an overview how and where certain classes and their methods are used.
Is there any good tool that can somehow visualize the dependencies and draw a nice call tree or something similar?
The code is in C++ in Visual Studio if that helps narrow down any selection.
Here are a few options:
CodeDrawer
CC-RIDER
Doxygen
The last one, doxygen, is more of an automatic documentation tool, but it is capable of generating dependency graphs and inheritance diagrams. It's also licensed under the GPL, unlike the first two which are not free.
When I have used Doxygen it has produced a full list of callers and callees. I think you have to turn it on.
David, thanks for the suggestions. I spent the weekend trialing the programs.
Doxygen seems to be the most comprehensive of the 3, but it still leaves some things to be desired in regard to callers of methods.
All 3 seem to have problems with C++ templates to varying degrees. CC-Rider simply crashed in the middle of the analysis and CodeDrawer does not show many of the relationships. Doxygen worked pretty well, but it too did not find and show all relations and instead overwhelmed me with lots of macro references until I filtered them out.
So, maybe I should clarify "large codebase" a bit for eventual other suggestions: >100k lines of code overall spread out over more than 100 template files plus several actual class files pulling it all together.
Any other tools out there, that might be up to the task and could do better (more thoroughly)? Oh and specifically: anything that understands IDL and COM interfaces?
When I have used Doxygen it has produced a full list of callers and callees. I think you have to turn it on.
I did that of course, but like I mentioned, doxygen does not consider interfaces between objects as they are defined in the IDL. It "only" shows direct C++ calls.
Don't get me wrong, it is already amazing what it does, but it is still not complete from my high level view trying to get a good understanding of how everything fits together.
In Java I would start with JDepend. In .NET, with NDepend. Don't know about C++.