From jan@swi.psy.uva.nl Mon May 28 10:29:31 2001
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id f4S8TV315791;
	Mon, 28 May 2001 10:29:31 +0200 (MET DST)
Received: (from jan@localhost)
	by gollem.swi.psy.uva.nl (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f4S8TVH11741;
	Mon, 28 May 2001 10:29:31 +0200
Date: Mon, 28 May 2001 10:29:31 +0200
Message-Id: <200105280829.f4S8TVH11741@gollem.swi.psy.uva.nl>
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Subject: Re: [SWIPL] libraries written in Prolog
To: Paul Singleton <p.singleton@keele.ac.uk>,
   SWI Prolog <prolog@swi.psy.uva.nl>
In-Reply-To: Paul Singleton's message of Fri, 25 May 2001 22:11:20 +0100
Phone: +31 - 20 - 525 6121
Cc: Jan Wielemaker <jan@swi.psy.uva.nl>

> Jan Wielemaker wrote:
> 
> > P.s.    In a wider context I'm a bit worried on these issues.  Using
> >         file_search_path/2 is a great way to organise the file-structure,
> 
> For development maybe, but for deployment I think a PATH in the inherited
> environment would be better.  Isn't there a chicken/egg situation with
> regard to getting file_search_path/2 clauses into the files you're trying
> to find?!

For deployment you normally use a saved-state.  Source-files don't matter
anymore then.  If you deploy as source, the file_search_path works great,
as it allows the package to define the required resources in an abstract
manner that can be satisfied by a local configuration file.

> >         but the module name-space and public predicate namespaces are
> >         flat.
> 
> I guess it's too late to do anything about this? but we could adopt a
> convention for constructing module names like Java packages?

The module system will be modified to deal with the ISO standard someday.
Don't recall this problem is addressed though.

> >         If we just keep adding modules to the library, eventually it
> >         will become unmanagable.
> 
> I just about cope with 23k procs in 700 libraries, and I don't yet use
> modules :-)
> 
> > I'm seeking for solutions that
> >         preferably fit with some kind of standard.
> 
> I suggest we learn whatever we can from the practical success or otherwise
> of the corresponding design decisions that were made for Java.
> 
> Really, I don't believe in modules.  All we need is a system for naming
> predicates, e.g.

Modules define the interface to a body of code.  They are at least useful
to make clear what is the interface provided by the body by hiding all
local predicates.  For a start, the module system allows me to have two
alternative implementations defining the same interface and swap easily
between the two.  I can even use one implementation in one part of my
program and another in another part.  

>   nl_uva_psy_swi_table_util_sort_table(...)
> 
> and a smart editor which, within a context of:
> 
>   this module is called 'nl_uva_psy_swi_table_util'
> 
>   and it uses predicates from
>         'nl_uva_psy_swi_table'
>         ...
> 
> allows us to use relative names, then absolutifies them.

This smells like a name-based module system.  We've had this discussion
in the Prolog world and sofar I'm convinced the current module-system is
better.

> Actually, we'd need a whole suite of tools which conspired to hide
> the long-winded absolute nature of all the names.
> 
> NB I reckon scalability (without the 'e' this time) of data types and
> constructors is a much worse problem, but I'm still getting my thoughts
> together on this (I want implementation inheritance, polymorphism,
> substitutability etc.)

Thats an entirely different issue, but indeed also a serious one.

	--- Jan

