On Wed, Jul 16, 2014 at 1:12 PM, j verzani <[email protected]> wrote:
> Here is a small argument: in SymPy the negation prints with that > character. So to match the output I was hoping > to utilize (U+00AC) as ! for input. Easy to work around, but it might be > nice to have. > > On Wednesday, July 16, 2014 4:04:07 PM UTC-4, Steven G. Johnson wrote: >> >> >> On Wednesday, July 16, 2014 3:40:31 PM UTC-4, Ben Arthur wrote: >>> >>> julia> const ∪ = union >>> >> >> ∪ is already defined to union in Julia. >> >> julia> const ¬ = ! >>> >>> ERROR: syntax: invalid character "¬" >>> >> The ¬ character (U+00AC) is in category Sm (math symbols), and Julia does >> not allow all possible math symbols as identifier characters. The reason >> is that, for each math symbol, we need to individually decide whether it >> will be parsed as part of an identifier or as an operator. And, if it is >> parsed as an operator, we need to decide the precedence. >> >> In consequence, there is a whitelist of math symbols allowed in >> identifiers >> https://github.com/JuliaLang/julia/blob/master/src/flisp/ >> julia_extensions.c#L51-L93 >> and another whitelist of symbols treated as operators >> https://github.com/JuliaLang/julia/blob/master/src/julia- >> parser.scm#L6-L22 >> Both of these lists will probably grow over time. >> >> In the case of ¬, I think it would make sense to parse it as a prefix >> operator (with the same precedence as !), and probably to define >> const ¬ = ! >> >> I actually thought about ¬ when I recently whitelisted a bunch of unicode >> math symbols in Julia. My hesitation was that I'm not sure what useful >> purpose ¬ would serve in Julia code, other than as a synonym for !. It's >> not any shorter than !, and in general in Julia we have tried to avoid >> introducing redundant syntax (e.g. "and" and "or" synonyms for && and >> ||). Following the "when in doubt, leave it out" philosophy, I therefore >> left ¬ out of the patch. >> >> However, if an argument can be made for the utility of ¬ in Julia, it >> would be easy to include. >> >> --SGJ >> > How about making ¬ parse as a unary operator with precedence like ! but leave it undefined. It would be pretty weird for ¬ to be part of an identifier and not as a unary operator and that's all we really need to decide.
