Parser rejects operators as plain atoms in term position (require quoting) #19

New issue

Closed

opened 2026-06-02 17:42:47 +00:00 by navicore · 1 comment

navicore commented

2026-06-02 17:42:47 +00:00

Owner

Summary

The parser rejects operators (+ - * < = mod …) when they appear as plain atoms in argument or list position. Standard Prolog (e.g. SWI) reads an operator in these positions as the corresponding atom; patch-prolog requires it to be quoted.

Repro

p(+).            % Error: Unexpected token Plus
L = [<].         % Error: Unexpected token Lt
p(mod).          % Error: Unexpected token Mod    (word-operators too)
L = ['-'].       % OK — quoting works

It affects symbolic and word operators alike.

This is reader-only

The atom itself is fine everywhere else — =.. produces it and round-trips:

?- (2 + 3) =.. [Op, L, R], Back =.. [Op, L, R], Back =:= 5.
true.            % Op is bound to the atom +, rebuilds and evaluates

So the gap is purely in how the reader handles an operator token in term position, not in the term representation.

Expected

Per ISO 6.3.1.3 / common practice, an operator name used as an atom (in an arglist, list, or via =) should read as that atom: [+, -, *] is a 3-element list of atoms, X = (+) binds X to +.

Impact

Blocks the natural way to teach "operators are just compound terms" / =.. without quoting, and anyone arriving from SWI will trip on it. Workable around by quoting ('+'), which is what I've done in the loglings exercises.

Found while building the loglings Prolog exercises against the installed engine.

## Summary The parser rejects operators (`+ - * < = mod` …) when they appear as plain atoms in argument or list position. Standard Prolog (e.g. SWI) reads an operator in these positions as the corresponding atom; patch-prolog requires it to be quoted. ## Repro ```prolog p(+). % Error: Unexpected token Plus L = [<]. % Error: Unexpected token Lt p(mod). % Error: Unexpected token Mod (word-operators too) L = ['-']. % OK — quoting works ``` It affects symbolic and word operators alike. ## This is reader-only The atom itself is fine everywhere else — `=..` produces it and round-trips: ```prolog ?- (2 + 3) =.. [Op, L, R], Back =.. [Op, L, R], Back =:= 5. true. % Op is bound to the atom +, rebuilds and evaluates ``` So the gap is purely in how the *reader* handles an operator token in term position, not in the term representation. ## Expected Per ISO 6.3.1.3 / common practice, an operator name used as an atom (in an arglist, list, or via `=`) should read as that atom: `[+, -, *]` is a 3-element list of atoms, `X = (+)` binds `X` to `+`. ## Impact Blocks the natural way to teach "operators are just compound terms" / `=..` without quoting, and anyone arriving from SWI will trip on it. Workable around by quoting (`'+'`), which is what I've done in the loglings exercises. --- Found while building the `loglings` Prolog exercises against the installed engine.

navicore referenced this issue from a commit

2026-06-02 18:04:33 +00:00

● Every repro from the issue now works. Issue #19 is fixed.

navicore referenced this issue

2026-06-02 18:04:55 +00:00

● Every repro from the issue now works. Issue #19 is fixed. #24

navicore commented

2026-06-02 18:05:11 +00:00

Author

Owner

#24

https://git.navicore.tech/navicore/patch-prolog/pulls/24