Re: Ann: SWI-Prolog 6.5.3

On 21/11/2013, at 11:45 PM, Jan Wielemaker wrote:

> On 11/21/2013 04:05 AM, Richard A. O'Keefe wrote:
>> 
>> On 20/11/2013, at 10:43 PM, Jan Wielemaker wrote:
> 
>> memchk(X, cons(H,T)) :- ( X = H -> true ; memchk(X, T) ).
>> 
>> If this behaves differently from memberchk/2, you make my
>> life as a programmer *HARDER*.
> 
> My viewpoint has always been that a predicate behaves sensibly in a
> specified domain. In this case that is the domain of cons(H,T) pairs.
> Outside that domain, it should basically throw as many errors as
> possible because that greatly helps debugging your program.

I want to agree with you.
But the code you find in Prolog textbooks
and in a lot of Prolog practice *doesn't* throw many errors.

And having gone through Quintus Prolog trying to make that
bullet-proof, I can testify that adding thorough error checks
is *hard*.

The point I am complaining about is that the new definition
of memberchk/2 *DOESN'T* ensure that its second argument is
confined to the intended domain.  It does a half-hearted job of it.

It seems to me that you are saying that because full checking is good,
therefore inconsistent and incomplete checking is also good.
> 
> 
> Ideally, we'd have static tools for that, but unfortunately these are
> still not widespread.

The DEC-10 type checker was public domain, 30 years ago.
I guess people were really serious about NOT wanting it.

>> Can we please consider "getting rid of [a|b]" a *non*-problem?
> 
> That is absolutely not a non-problem.

I guess this is one of those YMMV issues.  For me, this has not
been a common mistake since about 1982, while on the other hand
there have been times when I have wanted a compact data structure
and have used [_|_] as a *PAIR* (not *LIST*) construction
internally.

> This is not a hypothetical issue, but a frequent source of frustration.

I am astonished that it should be "frequent".  Perhaps a good naming
convention really helps.

> Sometimes you are lucky and you pass the non-list to a predicate that
> throws an exception.

Yes, but all you're doing now is increasing the number of such
predicates by one, *sometimes*.

If I were to grant that [a|b] were a serious problem,
then I'd be looking for a serious solution.

Since it's *not* just the built-in nils and pairs that are a problem,
but *every* user-designed data type has exactly the problem,
I'd be expecting a serious solution to address user-designed data
types as well.  Whether that's a static type system like the
DEC-10 Prolog type checker, or a static/dynamic hybrid (theoretically
dynamic with partial execution optimising much of it away) like Lee
Naish's, or typed variables, or what, I don't know.  Making
memberchk/2 different from member/2 and append/3 isn't going to do it.


> The main point of strings is that they are *not* lists

OK.  If you think strings are a good data type, shouldn't they have
more operations?  And should the manual still be saying
	new code should consider using atoms
?  Would it be a good idea to replace string_to_list/2 (which name
suggests conversion that goes ONLY left to right) with
	string_codes(?String, ?Codes)
	string_chars(?String, ?Chars)
like atom_codes/2 and atom_chars/2?  Shouldn't there be a
number_string/2 to go with number_{codes,chars}/2?
Would it be a good idea to
document that/whether strings work in UTF-8, and whether "characters"
in the documentation of string_length/2 and sub_string/5 means "bytes"
or "Unicode code-points"?  Would it be a good idea to offer the
    span_left(String, Set, Before[, Length[, After]])
    span_right(String, Set[[, Before], Length], After)
predicates that Xerox Quintus Prolog did?  -- quite helpful for
tokenising.

Strings in SWI Prolog look like, and are _documented_ like, something
that was begun and then more or less abandoned except for backwards
compatibility.  I had taken the "new code should use atoms" advice at
face value.

Xerox Quintus Prolog, sitting on top of Interlisp-D, *had* to do
something sensible with strings.  Other Prologs have also sat on top
of a Lisp, and JekeJeke Prolog, amongst others, sits on top of Java.
These systems too had *better* do something sensible with strings.
Arguably, Web-friendly systems working with JSON need a text
representation that doesn't look like a JSON array (and even with
the 'chars' representation, you can't tell an empty chars-list
from any other empty sequence), so strings may be thrust on us.
Strings can handle Unicode-compatible case conversion in a way that
mapping along a list would find difficult -- because Unicode-
compatible case conversion needs the *whole* string to work with,
not being single-code-point-at-a-time.

You have made some good arguments for having a string data type and
there are plenty of other arguments that could be made.  It's not
ISO, but then, despite the clear need, neither are bignums or ratios
ISO.

Dash it, I think I've just argued myself into changing my mind.
OK, I'm _still_ never going to use "foo" for anything but a list of
codes, but I might be quite pleased to use `foo` for a string.

[The post-load string check treats predicates as dangerous for strings
by default.]
>>> 
> Yes.

This counts as further strong discouragement of strings.
> 
>> What I _want_ is to be able to declare in a source file what
>> syntax settings that file is to be processed with *without* any
>> effect on run time.  Is that possible?
> 
> The double_quotes flag has no impact on the runtime.  It only
> defines the resulting data structures from parsing "text" and it
> does so on per-module basis.  So, if you have a module that
> processes code lists and uses a lot of list processing predicates
> with explicit "text" as arguments, you just declare that module
> to parse this into code lists.

OK, this is a documentation issue.  What I wanted is for the flag
to be per-FILE, but it is documented as being per-MODULE, and with
operator declarations hanging around at run time, it was natural
to suppose that prolog-flag -- which _looks_ like a run-time flag
was doing the same.

We are told that character_escapes is "local to the module in
which it is changed."
(I'd like a declaration that is per-FILE.)
We are told that double_quotes "is ---like character_escapes---
maintained for each module."

We are *not* told there what this actually means, and it seems
that I misunderstood.  Also,
we are *not* told that the apparently similar backquoted_string
flag is maintained for each module, so maybe it isn't?  Shoud
it not be just like the other two?

> 
> You can add Contents/MacOS of the app to your $PATH and run the swipl
> commandline version after unsetting $DISPLAY.

This was the key issue:  it never occurred to me that in an environment
where X11 is not running, $DISPLAY would be set at all.  I now have
  #!/bin/sh
  unset DISPLAY
  exec /opt/local/bin/swipl "$@"
in my own command folder.

> That will stop it trying to contact X11.
>  There might be something wrong with your Mac.

I doubt it.  It's the same behaviour on the 10.6.8 laptop,
my 10.7.5 desktop, and several lab machines running 10.8.something.
It's also the same enormously long startup time whether it's
started from SWI Prolog, R, or VisualWorks/Non-Commercial Smalltalk,
and it was the same when the desktop machine was a physically
different machine.

>  I've got a really old iMac.  Sometimes X11 takes long to start the first
> time after an upgrade, but otherwise it is just a few seconds.

I have _never_ seen X11 start in "just a few seconds" in any version of
Mac OS X on any hardware.  I just did "open -a X11" again in a Terminal
and it was 75 seconds before the icon stopped bouncing (longer to do
anything useful).  Maybe it has something to do with our sysadmins
having decided that everyone would have their files on a shared file system.
(My colleague in the next office asked them not to do that to him and they
didn't.  I asked them never to do that to me, and they did.  Sigh.
Maybe it's my aftershave.)

> 
> I always use the manual on the website.

When the GUI help system did come up, it was using a font in
which "Declared" looked like "Dedared".