Re: Ann: SWI-Prolog 6.5.1

On Tue, 13 Aug 2013 20:35:16 +0200
Jan Wielemaker <[email protected]> wrote:

> On 08/13/2013 03:07 PM, Nicos Angelopoulos wrote:
> > As far as Prism is concerned, the SWI port would be mostly for educational reasons. 
> > I don't think that performance wise it can get anywhere near BProlog and Yap without serious
> > time investment.
> 
> I'm not so sure.  These systems are mainly better at last-call calls and
> inlining
> a lot of stuff.  There are quite some programs in which they do not
> perform much
> better than SWI-Prolog.
> 
	would the fact that my performance statement was specific
	to tabling for probabilistic switches make you feel any happier ?

	there have been a number of publications, detailing the innards of LP tabling systems
	for switch like probablities. To me, it seems self evident that to implement these in addition to implementing 
       a generic tabling system requires "serious time investement".
       although, the respective groups might be interested to provide some kind of input/support as SWI is the most
       popular of the systems mentioned previously.

> > SWI and Yap did great work a couple of years back and have to some extend continue 
> > this work to provide the same libraries. I think they actually use a common repository for some of them.
> > In an ideal word you either want
> > 	a. Yap engine and Swi libs
> > 	b. a common core API that will separate the libs from the inference engine,
> > 	   thus making all libs automatically visible to both systems
> > 
> > Of course, this is from a user perspective.
> > Developers obviously have different priorities, such as viability, finance, prestige and guarding of user-bases among others.
> 
> Cooperation is surprisingly complicated, even in the case of Vitor and me
> who typically can find a technical compromise fairly quickly :-(
> 
> 	Cheers --- Jan

	in my opinion, and simply on the techinical level, it is self evident that a closer integration
	of Swi and Yap makes sense. Whether the resources are there and closer integration is worth the effort, is not something I can estimate 
       with any confidence. Again, there are also many non-technical issues developers need to consider, that I don't have to.

	1. with all libraries on a common repository there is less time wasted in porting features backwards and forwards,
	   This would have a beneficial effect on both Swi and Yap developers' time.
            Would a PhD position working on that make sense? 
            Integrate the mailing lists as a first step ?

	2. a closer integration will increase the confidence of people picking up either of the two systems for
	   research and commercial uses

	3. can work as a de-facto framework and vehicle for standarisation of non-core features. 

        4. if the work is successful in creating an N-point API/plug-n-play-framework it might well lead to new Prolog systems

        5.  it will be a good excuse to clear up pending issues that have low priority, such as independence from XPCE code 
 
	6. has the potential to involve cross-system users in ironing out the immediate and future decisions,
		as well as form a core for the promotion of Prolog as a general purpose language

I am not an expert in this area, but the most successful languages/systems seem to graduate to 
being group efforts even if they started as one-man shows.

I fully appreciate that this is the mailing list of your Prolog system, i hope you don't mind too much.

Let me take the opportunity though, to congratulate yourself and Vitor for having brought the systems really close.
Your great work means that many of us (users) can now routinely use the same code on both Prologs. 

Regards,

Nicos Angelopoulos
---
http://bioinformatics.nki.nl/~nicos/