Does GraphDB offer configurability on materialization strategies to allow for non-monotonic entailment? I.e. adding new explicit statements to the graph might require retracting existing implicit statements that were already inferred based on previous assertions made to the graph.
From the GraphDB documentation this does indeed seem possible to some extend:
GraphDB stores explicit and implicit statements, i.e., the statements inferred (materialised) from the explicit statements. So, when explicit statements are removed from the repository, any implicit statements that rely on the removed statement must also be removed.
I.e., if a new triple causes a previously implicit/explicit triple to be removed, any implicit triples related to this removed triple will also be removed.
You can read more on GraphDB reasoning strategies here.
The GraphDB inference engine (and it's rule language) do not support negation in any form, so a non-monotoning reasoning is not supported by it.
Related
Both internal procedures and functions are accepting the parameters to give the output. So what is the use of using Internal procedures instead of functions.
A user-defined function is used when you want to perform some calculation and return a single value. In this respect it is the same as a built-in ABL function, like the SUBSTRING or EXP functions. Putting this calculation code in a FUNCTION block instead of inline in your code allows you to put it in one place and reference it multiple times without code duplication.
An internal procedure is also an encapsulated piece of code that does some work, but it is more general-purpose. While a function must return a single value, an internal procedure may or may not have input parameters or output parameters.
https://docs.progress.com/category/openedge-archives
Also functions (like methods) parameters and return value type are checked at compile time, which removes some potential problems at run time later.
The question acknowledges that both functions and internal procedures allow OUTPUT parameters and asks "what is the use" of internal procedures instead of functions.
To me, this implies that the poster is contemplating always using functions and deprecating internal procedures and is asking: "what would I lose if I do that?"
Two things spring to mind:
Sort of the opposite of Jean-Christophe Cardot's point: you would lose some automatic type conversions and syntactic flexibility about the parameter lists. Some people see that flexibility in a negative light. Others see it as a positive.
You need to "forward declare" your functions or use dynamic invocations. With an internal procedure you can RUN it without providing a declaration earlier in the code.
If you tend to think that strict type checking is useful then these are probably not benefits that you think of as being lost. If you prefer more flexible behaviors, then you may regret choosing functions rather than internal procedures.
I'm in a situation where I'm modifying an existing compiler written in OCaml. I've added locations to the AST of the compiled language, but it has cause a bunch of bugs, because equality checks that previously succeeded now fail when identical ASTs have a different location attached.
In particular, I'm seeing List.mem return false when it should return true, since it relies on equality.
I'm wondering, is there a way for me to specify that, for any two values of my location type, that = should always return true for any two values of this type?
It would be a ton of work to refactor the entire compiler to use a custom equality everywhere, particularly since many polymorphic functions rely on being able to use = on any type.
There's no existing OCaml mechanism to do what you want.
You can use ppx to write OCaml syntax extensions, and (as I understand it) the behavior can depend on types. So there's some chance you could get things working that way. But it wouldn't be as straightforward as what you're asking for. I suspect you would need to explicitly handle = and any standard functions (like List.mem) that use = implicitly. (Note that I have no experience with ppx.)
I found a description of PPX here: http://ocamllabs.io/doc/ppx.html
Many experienced OCaml programmers avoid the use of built-in polymorphic equality because its behavior is often surprising. So it might be worth converting to a custom comparison function after all.
What an annoying problem to have.
If you are desperate and willing to write a little C code you can change the representation of locations to Custom_tag blocks, which allow customising the behaviour of some of the polymorphic operations. It's a nasty solution, and I suggest you look hard for a better approach before resorting to this one.
One possibility is that most of the compiler does not use locations at all. If so, you might be able to get away with replacing every location in the AST with the same dummy location. That should allow equality to behave as if locations were not there at all. This is rather hacky, and may not be possible if passes later in the compiler make any use of location info.
The 'clean' solution is to define a sane equality operation for ASTs (or to derive one using ppx) and to change the code to use that. As you say, this would be a lot more work.
Context
I'm building an application that benefits from versatile collection wrappers, so I've set my sights on the Hack collection interfaces. Two of them are particularly promising: KeyedContainer<+Tk, +Tv> and ConstIndexAccess<Tk, +Tv>. The square-bracket access syntax allows Tk to be covariant in the former which has proven very useful — getter methods otherwise would require Tk in the argument (contravariant) position. That means I can access elements in sublinear time (argument-position Tk), or loop over the collection and access keys (return-position Tk) as I wish. The downside is that KeyedContainer is impossible to extend usefully: it doesn't define any methods.
At the moment, I need a mutable keyed collection type with an immutable ancestor. With this restriction on KeyedContainer, I'm considering biting the bullet by giving up keyed foreach and using ConstIndexAccess, which defines an explicit getter and has a mutable IndexAccess child from which MutableMap and MutableVector inherit.
Issue
The invariance of Tk makes ConstIndexAccess less powerful of a type, but also suggests that maybe there is some way to read keys from them. Is this the reason that ConstIndexAccess isn't contravariant on Tk? None of its descendants are covariant on Tk, and it is not possible to iterate using foreach. All other standard Hack contracts as far as I can tell have as flexible variances as possible except this one.
I am learning OCL (using "USE"), I've a question about the isUnique() constraint here's the following example:
We want to establish the unique constraint of customer numbers through the class full as follows
context Client
inv NoClientUnique : Client.allInstances -> isUnique(noClient)
but this expression is far from optimal , because it is possible that the constraint is validated repeatedly. Please anyone can explain me when this is the case and why, and please if you could give me another way to express the unique constraint of Client.noClient using an optimal. i'll appreciate any help.
OCL is a declarative language. Therefore you express what you want to happen, not how to do it. It doesn't make sense to discuss about how optimal is an OCL expression when optimal referes to the execution time. The translation engine should then be able to translate this declarative expression into the most efficient imperative traversal of the object graph in order to verify it.
Today, you can avoid the inefficiency by placing the constraint in a neutral scoping class such as perhaps the ClientManager that just needs to assert once that all-my-clients are unique.
Realistically there should always be such a scoping class, since if you take your subsystem and instantiate it multiple times, the Constraint that all Clients are unique is a fallacy. There is no reason why two different companies shouldn't have the same client if uniqueness is defined by a set of attributes rather than object identity.
(It has been suggested that it should be possible to have Package constraints so that in this case you could have used the Package as the neutral location.)
Is there a set of general rules/guidelines that can help to understand when to prefer pragma Pure, pragma Preelaborate, or something else entirely? The rules and definitions presented in the standard (Ada 2012), are a little heavy-going and I'd be grateful to read something that's a little more clear and geared towards the average case.
If I wanted to be thorough without fully understanding the "why" of it, can I simply try:
Mark the package spec with pragma Pure;
If it doesn't compile, try pragma Preelaborate;
If that fails, then I've done something tricky and either need to pragma Elaborate units on a with-by-with basis, or rethink the package layout.
While this might work (does it?), because it's recommended to mark a package as Pure whenever possible (likewise with Preelaborate), however it seems a bit brain damaged and I'd prefer to understand the process a bit better.
pragma Pure
You should use this on any package which does not have an internal state. It tells the user of the package that calls to any subprograms cannot have side effects, because there is no internal state they could change. So a function declared at library level inside a pure package will always return the same result when called with the same parameters.
The Ada implementation is allowed to cache return values of functions of a pure package, and to omit calls to subroutines if their return values won't be used because of these requirements. However, you can violate the constraints by calling imported subroutines (e.g. from a C library) inside your pure package (these may change some internal state which the Ada compiler doesn't know of). If you're evil, you can even import Ada subroutines from other parts of the software with pragma Import to bypass the requirements of pragma Pure. Needless to say: If you're doing anything like this, don't use pragma Pure.
Edit: To clarify the circumstances when calls may be omitted, let me quote the ARM:
If a library unit is declared pure, then the implementation is permitted to omit a call on a library-level subprogram of the library unit if the results are not needed after the call. Similarly, it may omit such a call and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters are of a limited type, and the addresses and values of all by-reference actual parameters, and the values of all by-copy-in actual parameters, are the same as they were at the earlier call. This permission applies even if the subprogram produces other side effects when called.
GNAT, for example, additionally defines that any subroutines that take a parameter of type System.Address or a type derived from it are not considered pure even if they are defined in a pure package, because the location the address points to may be altered, but GNAT does not know what kind of structure the address points to and therefore cannot run any checks about whether the referenced value of the parameter has been changed.
pragma Preelaborate
This tells the compiler that the package won't execute any code at elaboration time (i.e. before the main procedure starts executing). At elaboration time, the following constructs will execute:
Initialization of library-level variables (this can be a function call)
Initialization of tasks declared at library level (they may start executing before the main procedure does)
Statements in a begin ... end block at library level
You generally should avoid these things if you don't need them. Use pragma Preelaborate wherever possible, it tells the caller that he can safely use the package without executing anything at elaboration time.
If something doesn't compile with one of these pragmas when you think it should, look into why it doesn't compile. It may help you discover problems with your package implementation or structure. Don't just drop the pragma when it doesn't compile. As the constraint affects possible constraints on any packages that depend on yours, you should always choose the strictest applicable pragma.
Elaboration Order Handling in GNAT is a helpful guide. Ideally, the standard rules will suffice for most programs. The pragmas tell the compiler to substitute your elaboration order. They should be applied to solve specific problems, rather than used empirically.
Addendum: #ajb underscores an important distinction among the pragmas. The article cited agrees with the approach outlined in the question (bullets one and two): "Consequently a good rule is to mark units as Pure or Preelaborate if possible, and if this is not possible, mark them as Elaborate_Body if possible." It goes on to discuss situations (bullet three) "where neither of these three pragmas can be used."