I want to know the semantics of Z3_get_ast_id(). When will two expressions have same id? If two expressions are created using same context using same arguments and opcodes, will the id be same?
I also see that there is Z3_get_ast_hash(). Please tell the semantics of this function too.
The identifier is unique up to structural equality. Thus, two ast nodes
created by the same context and having the same children and same function symbols
have the same identifiers. Ast nodes created in the same context, but having
different children or different functions have different identifiers.
Variables and quantifiers are also assigned different identifiers according to
their structure.
You can use Z3_get_ast_id interchangeably with Z3_get_ast_hash
Related
I am working with antlr4 to parse some inner language.
The way I do it is the standard way of creating a stream of tokens, then creating a parse tree with set tokens. And the last step is creating a tree.
Now that I have a tree I can use the walk command to walk over it.
The walk command and the parse tree being created are an extension of the BaseListener class.
For my project I use many lookaheads, I mostly use the visitors as a sort of look ahead.
A visitor function can be applied on a node from the parser tree. (Assuming you implement a visitor class)
I have tried creating a smaller listener class to act as my look ahead on a specific node. However, I'm not managing to figure out if this is even possible.
Or is there another / better / smarter way to create a look ahead?
To make the question seem shorter:
Can a listener class be used on a node in the antlr4 parser tree-like visitor can?
There’s no real reason to do anything fancy with a listener here. To handle your example of resolving the type of an expression, this can be done in a couple of steps. You’ll need a listener that builds a symbol table (presumably a scoped symbol table so that each scope in your parse tree has a symbol table and references to “parent” scopes it might search to resolve the data types of any variables.). Depending upon your needs, you can build these scoped symbol tables in your listener, pushing and popping them on a stack as you enter/exit scopes, or you may do this is a separate listener attaching a reference to scope nodes to your parse tree. This symbol table will be required for type resolution, so if you can reference variables in your source prior to encountering the declaration, you’d need too pass your tree with a listener building and retaining the symbol table structure.
With the symbol table structure available to your listener for resolving expression types. If you always use the exit* method overrides then all of the data types for any sub-expressions will have already been resolved. With all of the sub-expression types, you can infer the type of the expression you’re about to “exit”. Evaluating the type of child expressions should cover all of the “lookahead” you need to resolve an expression’s type.
There’s really nothing about this approach that rules out a visitor either, it would just be up to you to visit each child, determining it’s type, and then, at the end of the listener, resolve the expression type from the types of it’s children.
I would appreciate some Cypher-specific theory for why there are, effectively, two different assignment operators in the language. I can get things to work, but feel like something is missing...
Let's use Neo4j's movie database with the following query:
match (kr:Person {name:"Keanu Reeves"}), (hw:Person{name:"Hugo Weaving"}), p=shortestPath((kr)-[*]-(hw)) return p
Sure, the query works, but here's the point of my question: 'kr', 'hw' and 'p' are all variables, right? But why is it that the former two are assigned with a colon, but the latter takes an equal sign?
Thanks.
It's important to note that the : used for nodes and relationships really doesn't have anything to do with variable assignment at all, it's instead associated with node labels and relationship types.
A node label and a relationship type always start with a :, even if there isn't a variable present at all. This helps differentiate a node label or relationship type from a variable (a variable will never begin with a :), and the : naturally acts as a divider between the label/type and the variable when both are present. It's also possible to have a variable on a node or label, but omit the type...in that case no : will be present, which again reinforces that it doesn't have anything to do with assignment.
In the context of a map {} (such as a properties map, including when it's inlined within a match on a node or relationship), then the : is used for map key/value pairs, and is common syntax, used in JSON representation.
Actual assignment (such as in SET clauses, and in your example of setting the path variable to a pattern within a match) uses =.
I do not think there is a deep theoretical reason for it. The original idea of Cypher was to provide an ASCII art-style language, where the MATCH part of the query which resembles a graph pattern that you'd draw on a whiteboard.
In many ways, a graph instance is quite similar to a UML Object Diagram (and other common representations), where you would use name : type to denote an object's variable name and type (class) or just use : type for anonymous instances.
Now paths do not really fit into that picture. On a whiteboard, I'd just put the relevant part in a dashed/circled area write p or p= next to it. Definitely not p:.
Note that it is possible to rephrase your query to a more compact form:
match p=shortestPath((kr:Person {name:"Keanu Reeves"})-[*]-(hw:Person {name:"Hugo Weaving"}))
return p
Here, using colons everywhere would look out of place, think: p:shortestPath((kr:Person {name:"Keanu Reeves"})
Remark 1. If you try to use a variable to capture relationships of a variable length pattern, you will get a warning:
Warning. This feature is deprecated and will be removed in future versions.
Binding relationships to a list in a variable length pattern is deprecated. (org.neo4j.graphdb.impl.notification.NotificationDetail$Factory$2#1eb6644d)
MATCH (a)-[rs:REL*]->(b)
^
So you would better use a path and the relationships function to get the same result:
MATCH p=(a)-[:REL*]->(b)
RETURN relationships(p)
Remark 2. I come from an OO background and have been writing Cypher for a few years, so it might just be me getting used the syntax -- it might be odd for newcomers, especially from different fields.
Remark 3. The openCypher project now provides a grammar specification
, which gives you an insight of how a MATCH clause is parsed.
I am using OWLAPI for a project, and I need to compare two ontologies for differences between them. This would ignore blank nodes so that, for instance, I can determine whether the same OWL restrictions are in both ontologies. Not only do I need to know whether there are differences, but I need to find out what those differences are. does such functionality exist in the OWLAPI, oz is there a relatively simple way to do this?
The equality between anonymous class expressions is not based on the blank node ids - anonymous class expressions only have blank nodes in the textual output, in memory the ids are ignored. So checking if an axiom exists in an ontology will by default match expressions correctly for your diff.
This is not true for individuals - anonymous individuals will not be found to be the same across ontologies, and this is by specs. An anonymous individual in one ontology cannot be found in another, because the anonymous individual ids are scoped to the containing ontology.
Note: the unit tests for OWLAPI have to carry out a very similar task, to verify that an ontology can be parsed, written and parsed again without change (i.e., roundtripped between input syntax and output syntax), so there is code that you can look at to take inspiration. See TestBase.java - equal() method for more details. This includes code to deal with different ids for anonymous individuals.
given an expression x'=x+1, I wish to rename x' to y. How to do using z3?
There are a number of API functions that let you modify terms and substitute new subterms for old ones. They are described under the Modifiers section that contain the modifiers Z3_update_term, z3_substitute, and Z3_substitute_vars (there is also Z3_translate to port terms between two contexts).
Here is the link:
http://research.microsoft.com/en-us/um/redmond/projects/z3/group__capi.html#gaa7497c70a827db2d61ba98889fe657b5
You can also traverse terms directly and write utilities to modify terms.
The display_ast example shows the main cases for recursively traversing terms:
http://research.microsoft.com/en-us/um/redmond/projects/z3/group__capi__ex.html#ga807b5fe0e26acdec09e52a77318208d0
I am able to understand immutability with python (surprisingly simple too). Let's say I assign a number to
x = 42
print(id(x))
print(id(42))
On both counts, the value I get is
505494448
My question is, does python interpreter allot ids to all the numbers, alphabets, True/False in the memory before the environment loads? If it doesn't, how are the ids kept track of? Or am I looking at this in the wrong way? Can someone explain it please?
What you're seeing is an implementation detail (an internal optimization) calling interning. This is a technique (used by implementations of a number of languages including Java and Lua) which aliases names or variables to be references to single object instances where that's possible or feasible.
You should not depend on this behavior. It's not part of the language's formal specification and there are no guarantees that separate literal references to a string or integer will be interned nor that a given set of operations (string or numeric) yielding a given object will be interned against otherwise identical objects.
I've heard that the C Python implementation does include a set of the first hundred or so integers as statically instantiated immutable objects. I suspect that other very high level language run-time libraries are likely to include similar optimizations: the first hundred integers are used very frequently by most non-trivial fragments of code.
In terms of how such things are implemented ... for strings and larger integers it would make sense for Python to maintain these as dictionaries. Thus any expression yielding an integer (and perhaps even floats) and strings (at least sufficiently short strings) would be hashed, looked up in the appropriate (internal) object dictionary, added if necessary and then returned as references to the resulting object.
You can do your own similar interning of any sorts of custom object you like by wrapping the instantiation in your own calls to your own class static dictionary.