-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unicodes \forall and \exists not working #19012
Comments
We do not currently parse these. I suppose we could parse them as macro calls to allow customization, or parse them as something that calls the |
Kevin wants this to work: |
What's the official representation of negation (~ or !)? Sarnoff, if I follow the unicode list, it should actually be A macro call with the |
It means they can be tab-completed to unicode characters by typing Of course we can make these parseable, we just need to decide exactly what the syntax is and what it parses to.
|
Okay, so why not start with |
We need a proposal for the exact grammar of that form (i.e. which non-terminals are used to parse each subexpression), and the structure that it parses to in terms of |
It looks like it would suffice, and be simplest, for That disallows |
|
I think parsing them as binary operators is not sensible. Eliminating that possibility eliminates the need to choose a precedence.That leaves the following options:
1 seems dubiously useful to me. Chances are that these operators will only be useful within specific DSLs anyway, so 2 is acceptable for most cases even without macro parsing. 3 is strictly more flexible than 2 but is also strictly more complex. 4 is interesting but, I would venture, extremely hard to get right. Only 4 allows constructs like Note that all of 2, 3, and 4 allow |
One argument for 2 is that none of the other binary connectives (and unary negation) operators, nor any of the operators that could look like implication, are parsed as macros. So most consumers of this syntax will require |
Yes, parsing them as unary operators seems the most sensible and conservative choice. However, I'm reluctant to implement anything absent a real application (as opposed to idle speculation on the mailing list). |
The application https://github.com/hpoit/Kenya.jl |
Kenya.jl seems to only consist of empty files? |
I need FOL before anything else. |
In any case, FOL will be around for a long time, and there will probably be many others after me wondering if FOL can be used with Julia. I think ultimately I would like to see FOL being used with Julia, on the blockchain. |
|
You don't need a special symbol to write code; you can always use ASCII symbols like |
MLN already exists http://i.stanford.edu/hazy/felix/. You're right, I don't need a special symbol to code. |
@hpoit, by real application I mean practical (non-vaporware) code in Julia with a clear reason why and how the code clarity would benefit from using Felix is written in Java and hence presumably does not (cannot) use |
I just want to use the least verbose notation possible for the universal and existential quantifiers, that's all, and this value appears to be in line with Julia. Since you and Bezanson offered to help given that I propose an exact grammar in terms of |
If you have a good proposal (that Jeff and Steven like too), I can implement it. (Though, I think the best implementation is just adding these operators to the unary operator list, but if you have other ideas, all the better.) I have a (barely started) FOL package that I've been meaning to work on sometime soon, and this will help with the syntax for me also. |
Magnifique |
Does the proposal have to be or would make easier if it was of Type 1 Grammar, like I understand is Julia? Apparently, MLN by default uses Type 2, probabilistic CFG, and doesn't offer an exact grammar in the sense that Bezanson mentioned, but learns the grammar from a corpus of texts. In Markov logic, universal quantifiers are also probabilistic. |
This seems to mean that PCFG is at times context-sensitive, like Julia, in the case when the probable parse is highly probable. |
Steven, there's some info here on parsing semantics like you asked, slide 84. |
@hpoit from a quick glance, that slide show contains nothing relevant. Semantic parsing is beyond the scope of the Julia parser. |
Is this helpful see section 4? |
@JeffreySarnoff, no. We know what the symbols mean in mathematics and logic; that's separate from the question of how they are parsed. |
We can all just assume they will be parsed as unary operators, right Steven? |
As I already said above, other operators parse as function calls but these might not: |
My suggestion was to require |
The whitespace-delimited form is closer to standard notation. But if |
I intend to build Isabelle.jl to introduce Isabelle/HOL formal methods to Julia. Isabelle.jl should reuse Julia's compiler parsing and type-checking front-end to subsequently derive verification conditions to be solved by Isabelle. References With this, I'm not sure this issue is relevant any longer. The formal representation of these quantifiers should be in Isabelle, which will then be mapped to native Julia. |
We should still eventually decide what to do with these symbols in the parser. |
I will check out what Isabelle does with them and post it here.
… On Feb 27, 2017, at 09:39, Steven G. Johnson ***@***.***> wrote:
We should still eventually decide what to do with these symbols in the parser.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
In case you missed this (as I haven't heard from anyone in here), perhaps this is also a good reference to understanding what to do with quantifiers in the parser: Julia was used in the development of ACAS-X and a theorem prover was used to guarantee properties of the code. Maybe they've already figured it out. I will eventually come back to this. |
I did find myself wanting to write assertions in this style for some Pkg3 code: @assert ∀ v ∈ inc ∃ p ∈ pairs p[1] ≲ v ≲ p[2]
@assert ∀ v ∈ exc ∄ p ∈ pairs p[1] ≲ v ≲ p[2] Of course, what I actually ended up writing was not too terribly far away from that: @assert all(any(p[1] ≲ v ≲ p[2] for p ∈ pairs) for v ∈ inc)
@assert all(!any(p[1] ≲ v ≲ p[2] for p ∈ pairs) for v ∈ exc) I'm not sure if that's suggestive of a useful syntax, but that's what I wanted to write. |
+1 |
+1 too -- I think this would allow for some very expressive syntax |
Any updates on when this could be included? |
There needs to be a definite proposal before there's a "this" to be included. |
IMO, the following code is very readable. I'm not a fan of the other math-like version. @assert all(any(p[1] ≲ v ≲ p[2] for p ∈ pairs) for v ∈ inc)
@assert all(!any(p[1] ≲ v ≲ p[2] for p ∈ pairs) for v ∈ exc) |
I agree, but I think we should make some syntax with |
Yeah, that is what I wanted. Just nice syntactic sugar |
The simplest option here would be to just allow |
julia> Symbol('∀')
Symbol("∀")
julia> Expr(:call, Symbol('∀'), :(x ∈ something), :(cat(x) => mammal(x)))
Expr(:call, Symbol('∀'), :(x ∈ something), :(cat(x) => mammal(x))) I guess treating \forall and \exists as valid identifiers by now can be OK, the originally desired syntax could be handled with macros. For example, @∀ (x ∈ something) cat(x) => mammal(x) |
The association of Even if we want to break that pattern and introduce the syntax I agree that |
This issue is closed by #42314, I think. |
julia> parse("∀x(cat(x) → mammal(x))")
LoadError: ParseError("invalid character "∀"")
while loading In[16], in expression starting on line 2
in parse at parse.jl:180
in parse at parse.jl:190
julia> parse("∃x(sister(x,Spot) & cat(x))")
LoadError: ParseError("invalid character "∃"")
while loading In[15], in expression starting on line 7
in parse at parse.jl:180
in parse at parse.jl:190
The text was updated successfully, but these errors were encountered: