I'm new Isabelle/Hol user and I have some confusion regarding using the existing definitions in Isabelle. I have to define a Complete lattice structure and Complete Partial Order (CPO) structure in my model. I found that those defintion already exists as Classes in the HOLCF Porder.Thy and Lattice.thy. So If I wanted to include those definitions in my model how should I proceed ? Like I copy paste all the definition or there is a specific command for that ?
Thanks
In the header of your own theory, you can import other theories. Complete lattices already exist in the Main theory (which you would usually import anyway if you're using HOL). Other theories can be referenced using ~~/src/HOL/... (Isabelle automatically substitutes ~~ for the home path of your Isabelle installation).
For the precise syntax, I recommend reading through prog-prove, especially ยง2.1.
Related
The project I'm working on uses some 3rd-party libraries in which a main module defines classes that are imported and extended by other, associated modules. In my case the main module is three.js, a JavaScript 3D computer graphics library, and the other modules are extensions that extend the features of the main module. These superclasses are an important part of the interface to the extensions, and I would like to include their contribution. Flow has been a great tool for typechecking the rest of the project, but I haven't been able to describe this particular situation well.
I've played with the existing three.js libdef and looked through several others for ideas, without luck. You can certainly declare/export a class in one module and import its type into another, but while that can be used to describe function parameters and such, you can't define a class that extends the imported type: flow complains that it "Cannot reference type ... [1] from a value position. [type-as-value]". I tried using the Class utility type, but that doesn't seem to be available in a libdef: using it causes a "Cannot resolve name Class. [cannot-resolve-name]" error. Am I missing something obvious here? Perhaps there's an well-known workaround?
Thanks in advance for any suggestions.
What is the difference between resource and library file in robot framework?
I searched google but couldn't able to find the answer
The resource file content is in the Robot Framework syntax. When it's imported in a suite, you can use all its keywords and variables, defined in the corresponding sections. Also all its imports (other Resource and Library it defines in the Settings section) are now available for usage.
The libraries on the other hand are (usually) written in the Python language. They can be ones installed through pip, or standalone scripts or modules. In the simplest case, all public functions of a module (more specifically - not-hidden) are available as keywords to be used in the suite. For more advanced usage (scope, state upkeep), they have to follow specific structure (usually accomplished through classes, and using identifiers/decorators expected by RF).
There is a third type of import, for which you haven't asked but I'm adding for completeness - the Variables files. Their format is once again Python code, which makes them quite versatile and powerful compared to vars defined in RF syntax (you can set the variables' content through complex programming constructs).
One caveat to keep in mind with them - the framework expects every attribute of the module to be a variable, and makes it accessible in your suite; this includes even other modules the file imports :). Thus you have to hide them through the _ name suffix (or, abuse this side effect for silent imports in some exotic cases :)).
I've included links to the relevant sections of the user guide, for further information.
I understand that you can create a separate yang file (Something like a textual Convention to store syntax values for MIBS)and import it into another yang file to make the data more organised and structured, but I can't seem to understand what the include statement does differently?
Does it "import" the entire file into the file that's including it - and if so would this be read before the file including it...?
Please help :)
YANG relies heavily on a concept known as "namespaces", which stems from XML naming conventions. Each namespace has a unique resource identifier and allows definitions (in different namespaces) to have same names at same definition levels while avoiding name clashes. When you define a YANG module, you are actually defining a namespace.
An import statement is used to access definitions from a foreign namespace (another module), while an include statement introduces a mechanism that allows a single namespace (single module) to be logically split into several files, conveniently named module and submodules. For includes, there is always exactly one module file, which includes all submodule files that belong to it. A submodule may only belong to a single module and may not be imported (directly). To an importing module, a module that includes submodules, looks like a single entity. Submodules may include eachother, but with YANG version 1.1, this has become unnecessary, since a submodule immediately gains access to all definitions in all submodules and the module they all belong to. In YANG version 1 you had to explicitly include a submodule to use definitions from it in another submodule, while never being able to access definitions in the module to which they belonged.
An import does not "inline" definitions into the importing module, while an include does exactly that. Importing a module gives you access to its top-level definitions (typedefs, groupings, idenitites, features and extensions) and allows you to use schema node identifiers that identify nodes in the imported module (for the purpose of augmentation and deviation, for example).
Definitions from a foreign namespace are always accessed via a prefix, which are part of an import statement's definition. Definitions that come from includes do not need to be prefixed when used, and if they are, are prefixed with the including module's (or submodule's) prefix.
YANG "compilers" usually process these files when they hit either an import or an include statement. They need to process them in order to be able to resolve definitions in body statements of the defining module. That is why these statements are required to appear in a module's header section.
There is an entire section in YANG specification dedicated to modules and submodules, where you can read more on the topic.
In principle, I could keep these extensions not-exported, and this would also allow me to not-add redundant documentation for these already well-documented methods, while still also passing R CMD check myPackage without any reported WARNINGs.
What are some of the drawbacks, if any? Is this possibly recommended to keep extensions of basic methods compartmentalized within the package that defines them? Alternatively, will this make it more difficult for another package to depend on mine, if certain core method-extensions are not exported?
For example, if I don't document and don't export the following:
setMethod("show", "myPackageSpecialClass", function(object){ show(NA) })
I'm trying to flesh-out some of these finer details of best-practices with namespaces and base method extensions.
If you don't export the methods, then users (either at the command line or trying to use your classes and methods in their own package via imports) won't be able to use them -- your class will be displayed with the show,ANY-method.
You are not documenting the generic show, but rather the method appropriate for your class, show,myPackageSpecialClass-method. If in your NAMESPACE you
import(methods)
exportMethods(show)
(note that there is no way to export just some methods on the generic show) and provide no documentation, R CMD check will complain
* checking for missing documentation entries ... WARNING
Undocumented S4 methods:
generic 'show' and siglist 'myPackageSpecialClass'
All user-level objects in a package (including S4 classes and methods)
should have documentation entries.
See the chapter 'Writing R documentation files' in the 'Writing R
Extensions' manual.
Your example (I know it was not meant to be a serious show method :) ) is a good illustration for why methods might be documented -- explaining to the user why every time they try and display the object they get NA, when they were expecting some kind of description about the object.
One approach to documentation is to group methods with the class into a single Rd file, myPackageSpecialClass-class.Rd. This file would contain an alias
\alias{show,myPackageSpecialClass-method}
and a Usage
\S4method{show}{myPackageSpacialClass}(object)
This works so long as no fancy multiple dispatch is used, i.e., it is clear to which class a method applies. If the user asks for help with ?show, they are always pointed toward the methods package help page. For help on your methods / class, they'd need to ask for that specific type of help. There are several ways of doing this but my favorite is
class ? myPackageSpecialClass
method ? "show,myPackageSpecialClass"
This will not be intuitive to the average user; the (class|method) ? ... formulation is not widely used, and the specification of "generic,signature" requires a lot of understanding about how S4 works, including probably a visit to selectMethod(show, "myPackageSpecialClass") (because the method might be implemented on a class that myPackageSpecialClass inherits from) or showMethods(class="myPackageSpecialClass", where=getNamespace("myPackage")) (because you're wondering what you can do with myPackageSpecialClass).
is there a simple way to generate a JAR file, that contains only the classes that depend transitive from a certain "main" class (reflection omitted of course).
I want to provide a little part of my application to someone else but do not want to export the whole application.
Thanks,
M.
Probably the easiest approach is using a tool like yGuard which "...provides elaborate code shrinking functionality through dependency analysis." This would also solve the same problem where you give it an entry point, and it performs dependency analysis to work out which classes can be excluded from the Jar.
However, I have throught about this problem myself a few times and fancied having a go at it myself for the challenge. All it would take would be to parse the import statements of Java source files and build a dependncy graph of how the classes interact with each other. Each reference from the main class should be recursively scanned until a complete graph is assembled. Then once the graph is assembled it would be a case of outputting this in a way that some packaging logic could process (or if you are feeling daring, the JDK has its own built in Jar creating/modifying code to do it yourself). Granted, this approach would require writing this custom utility and would also miss fully qualified class references in the code.