Re: Adding dot-notation in an ISO conforming manner

Jan Wielemaker:
>> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO#adding_conforming_dot
>
>It is an interesting thought.  I don't really understand the example.
>Looks like a typo, as doing op(400,xfy,.) turns ON (I assume) the
>special meaning of the . and the query should fail, no?

In ISO Prolog, a syntax extension must not change the meaning of
existing valid syntax (5.5.1 a and b).  However, if there is no valid
syntax present, there is some space for extensions.  And there is no
other place for syntax extensions.

If a user issues op(400,xfy,.), then there is no space for
interpretation what a.b means. It means [a|b] resp. '.'(a,b).
However, as long as a.b is invalid syntax, there is this space.  I
cannot see a reason why you want to permit that priority and specifier
of . is altered anyway.  You want op(100,yfx,.) and any change to this
will cause problems.  BTW, does it make sense to have a
left-associative operator?  Do you use a.b.c? Meaning what exactly?
I'd rather see this as a.(b.c).  Similar to (:)/2.

There are some areas of overlap to regular syntax.  Like
X = 1 mod.mod 2.  which is valid syntax in the absence of .

A possible restriction to avoid any overlap could be that for
prefix.stem to be valid syntax (without an op declaration for .),
prefix must not be an operator.  I believe that is the only possible
problem.  For, if a and b are not operators, then a b is always
invalid syntax no matter what tokens surrounds them.

>Compatibility wise, this seems a step ahead.  Consistency wise, it
>creates a difficult story.  .(A,B) \== A.B is weird at best.

If . is not defined as an infix operator this statement is meaningless
since it is a syntax error.  And if a user defined . it is == .

In any case, much better than [A|B] \== .(A,B).

>The most nasty real problem this would solve is that read/write terms
>using `canonical syntax' is currently broken. SWI7 reads/writes lists as
>[H|T], unless the option dotlists(true) is given to read_term/3 or
>write_term/3.
>
>In itself, I already consider this a step in the right direction instead
>of the wrong one.  Reading deeply nested terms in canonical syntax is
>pretty hard without running out of stack because after reading f(, you
>can do little else but reading arguments and pushing them onto a stack
>until you see ) which allows you to count the pushed arguments and
>create an f/N term.  Just try something to the equivalent of this in
>various Prolog systems with an increasing list length:
>
>1 ?- numlist(1, 10000, L),
>      tell('x.pl'), write_canonical(l(L)), writeln(.), told.
>2 ?- [x].

The common way to read terms is to tokenize them (that is, copy the
tokens into a list) and then parse them.  In this context there is
already considerable space overhead.  Still, major implementations do
it that way.

>Using list notation for write canonical

.. is not conforming.  There are 2 systems that do this currently.
Minerva and XSB.  The others are conforming.

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment#34

>   - Makes it way simpler to avoid this because you know [...] creates
>     terms with arity 2.
>   - Makes it way easier to write simple parsers/generators in other
>     languages (one of the aims of the canonical syntax).
>   - Does not introduce any ambiguity

There is no ambiguity in ISO.

>   - Is easier to read by us, humans.

The major point is that existing terms can no longer be read.  And you
cannot negotiate with the past.

The second is that write_canonical/1 is defined that way.

What you want is another way of writing.  Why not! Make a new write
option. You could write out {} and even , to a limited degree: the
arguments must not be atoms.