Unicodes \forall and \exists not working

[hpoit]

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

[JeffBezanson]

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 all function. What would you propose?

[JeffreySarnoff]

Kevin wants this to work: parse("∃x( sister(x,Spot) & cat(x) )")

[hpoit]

What's the official representation of negation (~ or !)?

Sarnoff, if I follow the unicode list, it should actually be parse("∃x(sister(x,Spot) ∧ cat(x))")

A macro call with the all function seems appropriate for \forall and a macro call with logical or for \exists. Should I do it? Where is this all function defined? Does it just include all x in X?

[JeffBezanson]

It means they can be tab-completed to unicode characters by typing \forall<tab> in the REPL and editor modes. Many, many characters are supported in this way, including some emoji. Characters you can type are a superset of characters that can be parsed, which are in turn a superset of characters with default meanings.

Of course we can make these parseable, we just need to decide exactly what the syntax is and what it parses to.

~ and ! are functions, so they parse to function calls. An expression like ∃ x f(x) presumably can't just be a function call; in particular it might bind x.

[hpoit]

Okay, so why not start with parse("∀x(cat(x) → mammal(x))")? For any object x, if x is a cat then x is a mammal.

[JeffBezanson]

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 Expr objects.

[TotalVerb]

It looks like it would suffice, and be simplest, for ∀ to parse as a unary macro (like a unary operator except as a macrocall instead of a call). I really don't think it's a good idea to make a separate parallel grammar for this logic stuff; the macro can implement those rules

That disallows ∃ x f(x) but ∃ x(f(x)) is not that much worse.

[stevengj]

∀ and ∃ are not parsed because it was not clear to me (when I initially expanded the list of parsed math symbols) whether they should be identifiers, operators, macros, etcetera, and what their precedence should be. Once we make a decision, it is hard to change, so it is best not to make a choice casually here.

[TotalVerb]

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. just allow them as identifier characters
2. parse them as standard unary operators
3. parse them as unary macros (like if ~ were parsed like a unary operator instead of a binary one)
4. parse them as if they were macrocalls directly, i.e. as if the token ∀ was basically equivalent to @forall.

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 ∀ x f(x), but at the expense of such constructs being extremely brittle.

Note that all of 2, 3, and 4 allow ∀ x -> f(x). 3and 4 allow accessing the body and arguments of such an expression. That way seems preferable for expressing something like a universal or existential type, or a logical statement.

[TotalVerb]

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 @type(X -> Y) anyway, and then parsing these operators as easily as possible (as simple function calls) will be most easily useful.

[stevengj]

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).

[hpoit]

The application https://github.com/hpoit/Kenya.jl

[hpoit]

FOL in MLN http://homes.cs.washington.edu/~pedrod/papers/mlj05.pdf

[KristofferC]

Kenya.jl seems to only consist of empty files?

[hpoit]

I need FOL before anything else.