From p.singleton@keele.ac.uk Sun May 27 14:48:49 2001
Received: from scooby.lineone.net (scooby-s1.lineone.net [194.75.152.224])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id f4RCmm304956;
	Sun, 27 May 2001 14:48:49 +0200 (MET DST)
Received: from keele.ac.uk (host213-120-138-144.dialup.lineone.co.uk [213.120.138.144] (may be forged))
	by scooby.lineone.net (8.10.2/8.9.3) with ESMTP id f4RCmPL28707;
	Sun, 27 May 2001 13:48:29 +0100 (BST)
Message-ID: <3B0ECA78.DB2F11C1@keele.ac.uk>
Date: Fri, 25 May 2001 22:11:20 +0100
From: Paul Singleton <p.singleton@keele.ac.uk>
Organization: SmartArts Computing Consultancy
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SWI Prolog <prolog@swi.psy.uva.nl>
CC: Jan Wielemaker <jan@swi.psy.uva.nl>
Subject: Re: [SWIPL] libraries written in Prolog
References: <200105250937.f4P9bJG23350@gollem.swi.psy.uva.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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?!

>         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?

>         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.

  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.

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.)

Paul Singleton

