Re: List cons functor (was Re: The meaning of module overriding syntax mod:goal in di

On 2005-03-03, Brian Hulley <brianh@metamilk.com> wrote:
> A change is an opportunity!

Changes in software standards are a nightmare.  Actually many changes are
mostly a nightmare.  I agree not a lot of code will be broken, but most
textbooks will be incorrect and code using functor/2 or =.. on lists will
break.  Addressing ./2 from foreign code is generally not necessary, but
not completely uncommon.

There is something to say for making sure we can use . as an infix
operator. Actually we can, but we have to be uncomfortably careful with
whitespace. Using the convention that . terminates a clause only if
followed by a newline is an option.  This too will break code:

foo(bar). gnu(gnat).

is suddenly read completely different!  Its not in my code, but I've
seen this too often.

It also breaks some nice goodies like validating a clause in an editor
as a . is typed (already broken by floating point numbers, but this way
it gets worse).

Otherwise, if . is an infix operator, there is no problem using it for
modules.  <Module>:XYZ now requires <Module> to be an atom.  Seeing a
list there is not ambiguous:

:- module(foo.bar, ...).

..,
foo.bar:hello,
..,

all make perfect sense, also with lists using .(a,b).

--- Jan