I understand the restrictions on ‘|’ as an operator, but what about ‘||’? Defining it with op/3 seems to be fine but when it’s used, the parser seems to get struck:
?- current_op(P,A,'||').
P = 500,
A = yfx.
?- X = a||b.
|
|
Action (h for help) ? | abort
% Execution Aborted
You have defined '||'/2 as operator, not ||/2. So you should use X = a'||'b.
I think there’s more to it. The atom defined by || should be exactly equivalent to '||'. In fact if I define the operator as:
op(500, yfx, ||).
and query it:
?- current_op(500,A,F).
A = yfx,
F = ('||') .
Note that || (without the quotes was just fine inside the op/3 definition.
An even simpler test; nothing to do with operators:
?- X = ++ .
X = ++ .
?- X = || .
|
Action (h for help) ? | abort
% Execution Aborted
An operator that requires quoting isn’t particularly useful IMO.
That error message is probably a good clue although I’m not sure how quasi quotations get involved in this.
My best guess is that term reading already does something special with a single bar; you never get to the second bar.
Quasy quotations get dragged in probably because there is a special case for term reading for quasy quotations. Since those are written as:
{|Syntax||Quotation|}
They need special treatment for the double bar. But at this point you are inside the {|.
The fact that reading with || seems to be non-terminating is a bug. Other then that, | is a singleton and thus should never glue to a longer atom without using quotes. There is simply now way to turn || into legal syntax, which is why it was chosen to act in quasi quotations.
Digging a little deeper, I see that, according to the manual, SWIP syntax is founded on ISO Prolog syntax. I, and I suspect the vast majority of Prolog users, aren’t going to pay money to the standards organization for the privilege of using it, so I went to the Eclipse documentation for the syntax definition of atom:
ATOM = (LC ALP*)
| (SY | CM1 | CM2 | ES)+
| (AQ (NES | ESCSEQ)* AQ)
| SL
| []
| {}
| |
and indeed | is a singleton atom and not allowed in a “symbolic” atom (second alternative). Alas, another useful operator character lost.
So is Eclipse syntax equivalent to ISO syntax in this regard? Possibly a lot of work, but perhaps the SWIP manual needs an expanded syntax section equivalent to the Eclipse Syntax Appendix.
Sorry, I should have said for the privilege of reading their document.
Thanks for sharing the atom syntax specification. Perhaps you could also provide the BNF for LC (assume lowercase letters), ALP (assume alphanumerics), and SY (equivalent to Eclipse definition?).
First, thank you for that link to the draft of the ISO appendix. I had seen it before but it completely slipped my mind. In the absence of anything else, the SWIP manual should link to it. (Maybe even capture it before it disappears.)
For operators, I would prefer to stick to characters which you commonly find on pretty much any keyboard/OS combination. I think it’s all about convenience - reading and writing. That said Unicode does open up a whole new world of possibilities.
It would be really great if we would use more than just ASCII for programming. It is of course possible, but input is a real pain in the neck. Which is actually stupid: Chinese have been using 2- and 3-keystroke combinations for typing for decades now.
Does anyone know of a working setup for using that kind of input?
You are not seriously suggesting that I write code by typing hex representations and copy-pasting the result, right? 
One approach that works is to use the \LaTeX math symbols, and type the names of the symbols. So to get something like || (but actually just a double vertical line) we would type \| or \Vert. I guess most modern text editors/IDEs would provide some support for that.
Unicode is reader friendly but not currently very writer friendly which IMO limits its usefulness in operators.
But my main takeaway form all this is the somewhat idiosyncratic nature of Prolog’s unquoted atom syntax. I can perhaps understand why some of those characters are in the singleton set, but don’t really understand why | is one of those. In fact why isn’t | just a non-associative infix operator?
Anyway, it is what it is; no point in debating Prolog syntax anymore.
I agree it is a chicken-and-egg problem, in the sense that no one seems to be doing it, so everyone assumes it is a bad idea.
There are problems, of course. I guess the biggest problem (and probably the reason why it will never catch up) is that it is difficult to tell what exactly you are looking at. Too many characters look like other characters. Exactly how long is that arrow? How close to each other are those vertical bars? and so on.
Suggestion: use and and or rather than && and ||. (This is Python-ish rather than C/Java/Javascript-ish). '/\'/2 and '\/'/2 would continue to used for bit-wise operations (and and or are “short-cut” operations which can avoid evaluating the 2nd operand).
I went down the pretty-printing rabbit-hole once. It works for math, maybe because the symbols have been in use for long enough and we know them from school/childhood. But for programming, it was somehow not worth the effort, at the end. It mostly obfuscated stuff. Maybe the math I’ve had to do is too simple anyway.
Hi!
I use user snippets in Visual Studio Code for writing special logical symbols. You define a mapping between a string and a symbol. Then you just start typing such a string and press enter when the appropriate autocompletion is shown. Very easy and fast. More info about using SWI Prolog and Visual Studio Code can be found here (under 2.1Installation). In the video on this page you can also see autocompletion in action (at around 01:05; note though that this part of the video is sped up by x2, it’s not that fast ).
Initially i got an error when inserting special unicode characters on Mac. The solution for me was to use the file type UTF-8 with BOM.
Cheers/JCR