Re: Quoted atoms are no longer operators

On 28/11/2013, at 4:26 AM, Jan Wielemaker wrote:

> True. I've never seen them in the wild though.

You haven't read some of my code then.

One of the things that drives me wild in family life
is when someone else
	*I* am not hungry so *NOBODY* will get a big meal.

Jan is at liberty to do whatever he wants with his own
system.  It's open source.  I am at liberty to switch
to another system or to fork his and do my own maintenance.

But the argument
	*I* haven't seen this in the wild so it does
	not matter to anyone
which seems to be offered here is not a valid one.

It is an ESPECIALLY invalid argument for a language that
has an actively maintained standard.

> Putting white space inside identifiers is a pretty bad idea
> anyway because many reformatting tools (or editor commands)
> can silently change this, breaking your code

Presumably, other people who do this, like me, do not use
such tools.  Or they use hyphenated operators like
'is-an-instance-of', to which the "spaces can break"
argument is inapplicable.

> and anyway, the difference between 'a<space>b' and 'a<tab>b' may be
> invisible

Which is why careful programmers do not let tabs survive in their
code.  For a couple of years how I've been using an AWK script to
check that source files have at most one TAB character and that in
a what(1) string.

> and the difference between 'a b' and 'a  b' is poorly visible,
> in particular when using variable pitch fonts.

Well there again, (a) using proportional pitch fonts for code
is still pretty silly; careful tabular layout can drastically
improve the readability of a program, which is another reason
why tools that casually change layout are to be vehemently
avoided.

Jan, did you notice that you just gave an argument against
putting spaces in *any* quoted things?  If your argument
were valid, nobody should ever use 'foo bar' or "foo bar"
or `foo bar` for ANY purpose, lest some weird program break
them.  We should always write \s.  And we should never put
the characters "-" or _" in a quoted thing because in some
fonts they are hard to tell apart.  Nor should we use
lower case l, the digit 1, or vertical bar, because they can
be hard to distinguish.  And don't get me started on 0 vs O
vs Ø.  In fact, the power of Jan's argument here is so that
it demonstrates convincingly that we should only ever use
\uXXXX escapes in quoted things and no literal characters.

If the argument *doesn't* demonstrate that, it doesn't demonstrate
anything.

For what it's worth, I do have a pretty printer for Prolog,
and one of the things it does _not_ do is change the white space
inside quoted tokens or break them without inserting appropriate
backslashing to ensure the character sequence is unchanged.
Even indent(1) manages to get this right for C strings.

> Richard's A '\uXXXX' B argument makes a little more sense. On the other
> hand, if you want it this ugly, '\uXXXX'(A,B) is just as good (or should
> I say ugly).

It seems that you did not at all understand what I was on about.
I was talking about using a *SIMPLE* SYNTAX-UNAWARE TOOL to
*TRANSPORT* source code.  Your recommended substitute requires
either (a) a human being not a SIMPLE MECHANICAL TOOL, or (b)
a complex fully operator-aware parser, not a SIMPLE SYNTAX-
UNAWARE program.

The requirement here is
	- be able to convert a Prolog source file from any
	  encoding that has a mapping to Unicode,
	- to an encoding using only the characters
	  explicitly listed in the ISO Prolog standard,
	- using a simple mechanical tool,
	- which has no knowledge of Prolog syntax, only
	  of Prolog lexical structure (this implies that
	  tokens cannot be reordered)
	- such that the output is as it stands a legal
	  Prolog program with the same meaning as the original.

That is what you currently have.
That is what you are proposing to break.

> This is a quite isolated issue.  A quite large majority I spoke to think
> it is a good idea.

How about letting them speak for themselves here, giving the reasons
why they think it is a good idea.  And how many people was this?

Look, if you spoke to me face to face, such is my admiration for
your labours and achievements, I would have a hard time saying "no"
to anything, up to and including "let's use ';' as a statement
terminator".  Here I am at a safe distance and can give my frank
opinion that the only thing I can see coming from this change is
a reduction in portability and utility.  I do *not* see any benefits
whatever.

By the way, the argument that double quotes should be the string
delimiters because that's what string delimiters are in "most"
languages fails for me, because several of the languages I use on
a regular basis use single quotes for strings.

I wonder how long it will be before SWI Prolog 7.* sports a >>> operator?