🚀 go-pugleaf

In article <395@aiva.ed.ac.uk>, jeff@aiva.ed.ac.uk (Jeff Dalton) writes:
> By saying call/1 is basically an EVAL, I meant that it brings in the
> problems that EVAL does while APPLY does not.

One extremely important problem that EVAL brings in which APPLY does not,
and which call/1 does not bring in either, is the need for QUOTE.

> By the way, Richard, are you still opposed to the so-called atom-based
> module schemes?  I suppose it should be a separate topic...

My objections to atom-based schemes are:
    Lisp associates an amazingly pile of rubbish with atoms (function cell,
    property list, package cell, pname, maybe even other stuff) with atoms.
    Prolog doesn't.  [Hand-wave about operator properties, which are
    notionally stored only in the current_op/3 table.]  Lisp has grounds
    for protecting atoms, Prolog hasn't.  In Prolog there is a one-to-one
    correspondence between atoms and character strings; all atoms are
    deemed to exist at all times  [Hand-wave about current_atom/1] and
    the names cannot be changed.  The elementary units with which Prolog
    associates information are _predicates_, so that's what the module
    system should be based on.  [A typed system could handle constructor
    functions as well as predicates.]

    Atom-based systems reveal too much:  if I have a predicate f_to_s_graph/2
    with auxiliary predicates f_to_s_graph/[3,4] -- this is a real example
    from the latest internal version of library(graphs); it converts a
    forest to a graph -- and want to export f_to_s_graph/2, I do *NOT* want
    the auxiliary predicates to be exported as well.

    Atom-based systems make basic data operations such as term comparison
    inordinately complicated.  [* see below]

    The only atom-based module systems with which I have any familiarity
    are those in Common Lisp and M-Prolog.  I find both appallingly
    complicated.

Someone could well produce a coherent logic programming language with an
atom-based module system.  (I don't know LM-Prolog well enough to tell
whether it satisfies this description.)  It couldn't be a compatible
extension of "Edinburgh" Prolog, that's all.  None the worse for that.

[* see here]
Of course, a Prolog system which is embedded in or otherwise closely
coupled with a Common Lisp implementation has to cope with the fact that
Common Lisp *has* an atom-based package system, like it or not.  Since
this is a reasonable approach to implementing a Prolog system (I am
saying this in the hope of tricking potential competitors into trying it...)
I think that a Prolog standard should address this issue.  (And yes, this
_is_ a swipe at the BSI/ISO substandard.)

Prolog need not be able to perform all the Common Lisp symbol/package
operations, but the Prolog operations should be defined so as to do
something sensible when given any atoms that the Lisp part manages to
throw at it.  I actually have a specification for this.  The main gap at
the moment is defining the term comparison order of distinct atoms with
the same name; it looks as though this has to be implementation-
dependent, and may have to be allowed to change between queries.