🚀 go-pugleaf

In article <2747@mulga.oz> lee@mulga.UUCP (Lee Naish) writes:
>The main uses of a module system are
>	1) avoiding accidental name clashes, and
>	2) protecting procedures from being called by anyone.

I am pleased to see such a small list and am even willing to take out
the second item, requiring instead only that such calls cannot too
easily be made by accident.  Of course, it would be nice if module
systems had other desirable properties as well.

>Prolog module systems have to handle a bit more than module systems of
>conventional languages because of the ways in which data/code can be
>converted into other representations and converted back:

One of the disappointing aspects of the BSI work on modules was that
many of the arguments presented against atom-based schemes seemed based
almost entirely on misunderstanding, a tendency to think of modules in
terms derived from languages like Fortran and Ada, and prejudice against
Lisp, which had somehow been associated with the atom-based suggestions.
The idea seemed to be that anyone whose thinking had not been influenced
[I've tried to find a reasonably neutral word] by Lisp would immediately
see that only predicate-based schemes made sense.  It was sometimes
difficult to get them to acknowledge that Prolog might have reasons of
it's own, namely the presence of things like =..  and call/1, and
difficult to obtain a clear explanation of how their proposals would
solve such problems.

Please do not read the last paragraph as an attack on the points
made by Richard O'Keefe: it isn't.  I am thinking instead of things
presented during BSI module meetings.  Indeed, one of the things I was
hoping Richard might do is to provide a clear explanation of the sort I
have been missing.

-- Jeff

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton