🚀 go-pugleaf

In article <439@aiva.ed.ac.uk>, jeff@aiva.ed.ac.uk (Jeff Dalton) writes:
> In article <958@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
> >I think that whatever module system you choose, this test should
> >succeed for any atom anytime:
> >
> >test(Atom) :-
> >	name(Atom, String),
> >	name(Atom, String).
> I am having difficulty imagining a situation in which this test could
> fail.

Silly me.  How about this:

test(Atom) :-
	name(Atom, String),
	name(Atom2, String),
	Atom=Atom2.

This test will fail in a atom-based module system where the module name
is not part of the name proper.  This is the case with CommonLisp:

(defun test (sym)
	(eq sym (intern (symbol-name sym))))

(test 'pkg:symbol)

will fail (return nil) if pkg isn't the current package.

Of course, this is easily worked around, but the code must know about
modules.  I would like whatever module system anyone supplies to be
as compatible as possible with existing Prolog code.

> > ...[code that takes terms and creates new terms with the same args,
> >     but where the functor has some extra chars on the front or back]
> >This is important for term_expansion/2.  An atom-based module system makes
> >it difficult to do both of these things.
> 
> I am not sure whether "both" is supposed to refer to prefix and suffix
> or to (prefix / suffix) and test.

Yea, that was ambiguous.  I meant some module systems might let me do
only one, but not both, of these.  As you say, an atom-based scheme
which puts extra characters into an atom's name will have trouble with
one or both of these.

I'm afraid I have a knee-jerk reaction to atom-based module schemes,
because I've used CommonLisp.  I spent a weekend once (I mean a whole
weekend, starting Saturday morning, and not stopping until Monday
night) trying to solve symbol-visibility problems in a large system.
Ultimately, I gave up.  I just couldn't get the visibility the way I
wanted it.  And this was not the first or last time I had to do battle
with the package system.

I know that there are problems with predicate-based module systems,
too.  I don't find them quite as objectionable, though.  Maybe what I
like about the predicate-based systems is that it just makes more sense
to me to put predicates, rather than atoms, into separate modules.
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds