Re: To develop a system fit for Web-heroes.

On 6/12/2013, at 5:13 AM, Jan Wielemaker wrote:
> 
> Just to support web-programming, I have added macro expansion,
> conditional compilation, threads, Unicode support, unlimited length
> atoms, the C interface including programmable Prolog streams and a
> module system to ISO. Of course, I should be fair that I've copied most
> of the specifications from others and luckily others copied some of my
> solutions.

(1) Unicode support -- wide character sets were already considered
    back in 1984 and the Prolog standard deliberately *allows* (but
    does not *require) the use of Unicode.

    Why doesn't it require Unicode?  Because some implementors were
    unwilling or unable to support it.  (It's worth noting that a
    lack of syntactic support has not stopped Erlang being
    successful in this area, and that Java's botched support for
    Unicode hasn't caused as many problems as you might expect.)

    It would be good if there were at least a *conditional*
    standard: "IF you do Unicode this is the way to do it".
    Like the optional components of the old COBOL standard;
    the report writer feature might or might not be there but
    IF it was there you knew what it should look like.  In all
    fairness, Unicode is appallingly complex, and there are
    few people who can claim expertise in both Unicode and
    Prolog.
    
(2) Unlimited length atoms -- the Prolog standard *allows* but
    does not require this.  It also _allows_ but does not
    _require_ atom garbage collection, having in fact nothing to
    say about memory management.  Again, some implementors were
    unable or unwilling to do this, but it was _considered_ and
    allowed.

    You are too modest here.  You also put unlimited length
    compound terms into SWI Prolog.  Quintus only ever allowed
    200 arguments or thereabouts.  But this too is something 
    that has always been allowed by the standard, but not
    required because implementors were unwilling or unable to
    commit to it.

(3) Module system -- the ISO standard includes a module system.
    There are some defects, but I think they could be fixed.

(4) C interface -- I agree that that's important, but again,
    having a C interface both merely continues what was common
    practice before ISO and is an allowed extension.
    
(5) Programmable Prolog streams -- I agree that that's important.
    I put a considerable amount of work, including slogging through
    the documentation of operating systems I'd hoped never to have
    anything to do with again, into the design of the Quintus version.
    This is intimately connected with (4), and again, is in no way
    contrary to the ISO standard.

(6) Macros and conditional processing are entirely doable within
    a pure ISO Prolog framework, by using what C and Fortran do:
    a preprocessor.  It's not even hard.

    While I was there Quintus didn't offer preprocessing features
    other than expand_term/2 to customers because while working on
    Xerox Quintus Prolog we had had incredibly painful experiences
    with Lisp macros.  We were unwilling to inflict that on anyone
    else, so held off until we had a design without the defects.
    We never did find one, and writing your own preprocessor was
    so amazingly easy that we had no customer pressure to provide
    one.

    I don't quite see the special relevance of macros and conditional
    processing to web programming but am keen to learn.

(7) Threads are so vital to web programming that Javascript
    doesn't have them.  Even the famous Node.js server has no
    threads.

    There is a draft threads proposal for the ISO standard.
    Since building threads into my Smalltalk system, my
    dislike for POSIX threads has matured into full-blown
    detestation, and the proposal in question is *far* too
    much like that for my peace of mind.

    Tim Lindholm -- who coauthored the Java VM book -- did a
    multithread version of Quintus Prolog that wasn't too
    unclean.  Something rather Erlang-like could be a truly
    excellent thing for Prolog, but will have a hard time
    getting past the "WAAH! It isn't like C!" crowd.

    Adding threads to SWI Prolog was a great deal of work and
    having something that can make good use of multicore
    machines is clearly a Good Thing.  It is a *considerable*
    extension of the standard, and it *can't* be done just by
    loading a bit of extra library stuff.

    But it is not *contrary* to the standard.



> Note that nothing of the above can be implemented as a library on top of
> ISO Prolog.  You must be a real optimist to believe that the ISO standard will advance enough to support the above before Prolog is forgotten.

As noted above, modules have been there for a considerable time.
Unicode *is* likely to make some progress, if someone gets behind
and pushes.  (I suppose that will have to be me, but then, I've
already _done_ that with the opening part of pllib.htm.)
Strings are already *allowed* by ISO Prolog, there just aren't
any standard operations for them.  (I'm revising pllib.htm...)
I'm not certain that we couldn't get agreement at the level of
"IF strings exist THEN these operations shall be provided".
After all, dynamic strings were added to Fortran in exactly
that way.
As noted above, there _is_ a proposal for adding threads.
(One written with apparently no sense of what can go wrong,
but it _exists_.)

C interface?  Well, now Ada and Fortran have official C interfaces.
Again, the first step is to get the principle of *conditional*
aspects accepted.  (Xerox Quintus Prolog didn't *have* any C system to
interface *with*, so it would be quite unreasonable to *require*
a C interface.)

> 
> So far, you can see all these things as quite pure extensions of the
> Prolog language, but they effectively stop any Prolog system from using
> SWI's web stuff,

Absolutely true.  But they don't stop sharing *other* stuff.