Prolog IDE
Claudio Cancinos
A couple of months ago I started developing prolog support for the
eclipse platform (http://www.eclipse.org). It's called ProDT and it's
in a very early stage of development so please be patient. You can see
it at http://prodevtools.sourceforge.net
One of the goals is to create a prolog IDE as rich in functionality as
the Eclipse's java IDE, giving the developer a single environment
where he/she can control the development from code edition, test
execution, debugging, and more...
I have a pretty good idea of how java projects are developed since I
have several years of experience in it, and I used several different
IDE's in different programming languages. Taking this into account,
I'm trying to add the things that makes me happy programming into this
tool.
But, as I'm not an extremely experienced prolog programmer I have a
lot of interrogants about how a common lifecycle of a prolog project
development is done.
Btw! at the moment the development is made using SWI-prolog, but a
long term plan is to support as many prolog implementations as
possible.
Going to more specific questions just as a start point I ask:
1) How is a project is usually organized?.
In an eclipse java project I can tell that there is a project which
contains source folders(directories where java files will be placed)
so you could have a source folder where you place your domain code,
and another one containing the tests. A project also has an output
directory which is where all binaries resulting from compiling java
files are placed by the IDE.
Within a source folder, java files are organized logically in packages
which fisically are directory structures in the filesystem.
Is there some kind of convention/rule regarding project filesystem
structure in prolog?
2) It will be nice to know if there is some kind of logical view of a
project like the ones in java (package, class, interfaces,
ennumerations) or if all are references to files. I think it will be
nice if I can focus the attention of the programmer in abstractions
related to the paradigm or the implementation language, instead of let
them think in files and directories, but I don't know if those kind of
abstractions exist in a prolog porject.
3) Another question is about how a prolog project is deployed:
I mean, is there a way of define what in Pascal/C/C++/Java is a main
method?
Are Prolog projects deployed into an executable binary file? For
example like a Windows .exe file
Is there any other format?
4) How are things managed in a project using an interface with another
language like JPL?
5) How are things managed in a project using a GUI librarie like XPCE?
6) In Java there is a framework called JUnit which is kind of a
standard for unit testing.
Is there anything like this in prolog?
I saw that Swi-prolog has a plUnit but does it work with any other
prolog implementation?
Is there any standard implementantion/convention for unit testing?
7) Regarding code refactors, I thought about some basic ones (renaming
rules, reordering rules defining another rule, extracting a new rule
from the ones used to define another rule). But I'll like to know if
there are any other refactors more specific to prolog which I can't
see.
8) Generally speaking, it would be nice if you can tell me how you
develop a prolog project and what do you like and dislike about it.
Any other thought or feedback you might have it will be very
appreciated.
Thanks in advance
Claudio Cancinos
Jan Wielemaker
On 2008-10-08, Claudio Cancinos <clau...@gmail.com> wrote:
> A couple of months ago I started developing prolog support for the
> eclipse platform (http://www.eclipse.org). It's called ProDT and it's
> in a very early stage of development so please be patient. You can see
> it at http://prodevtools.sourceforge.net
As you talk about SWI-Prolog, you may be aware there are a number of
partial IDEs for different IDE platforms, most in a mostly
`unfinished' status :-( It isn't a simple job to do it `right' for
Prolog, so some dedication is definitely needed :-) One of the issues
is that the Prolog syntax knows basically no `keywords', which
complicates source code colouring and indentation using simple generic
tools. Then there are some nasty syntax properties, such as 0'x to
refer to the character code of 'x'
Another issue is the large number of different ideas in the community
on how to setup and manage a Prolog project and -if you want
portability- incompatibilities between implementations. These
incompatibilities notably affect project maangement, such as the
lack of a standard module system :-(
> One of the goals is to create a prolog IDE as rich in functionality as
> the Eclipse's java IDE, giving the developer a single environment
> where he/she can control the development from code edition, test
> execution, debugging, and more...
>
> I have a pretty good idea of how java projects are developed since I
> have several years of experience in it, and I used several different
> IDE's in different programming languages. Taking this into account,
> I'm trying to add the things that makes me happy programming into this
> tool.
I'd think more about C for a comparison. Prolog doesn't have classes
in a hierarchy and its module system (if present) isn't too different
from C's notion of static code (except the default in Prolog is that
everything is private unless exported and in C everything is public
unless made static). Also resolving predicates is much more like
resolving C functions than resolving methods in an OO system.
> But, as I'm not an extremely experienced prolog programmer I have a
> lot of interrogants about how a common lifecycle of a prolog project
> development is done.
>
> Btw! at the moment the development is made using SWI-prolog, but a
> long term plan is to support as many prolog implementations as
> possible.
>
> Going to more specific questions just as a start point I ask:
> 1) How is a project is usually organized?.
> In an eclipse java project I can tell that there is a project which
> contains source folders(directories where java files will be placed)
> so you could have a source folder where you place your domain code,
> and another one containing the tests. A project also has an output
> directory which is where all binaries resulting from compiling java
> files are placed by the IDE.
> Within a source folder, java files are organized logically in packages
> which fisically are directory structures in the filesystem.
> Is there some kind of convention/rule regarding project filesystem
> structure in prolog?
No. As the language has no other organizational primitive than modules
that define visibility, somthing like expressing the class hierarchy
as a file/directory hierarchy is not possible. There are some remarks
in the SWI-Prolog manual on this topic, but I'm well aware there mostly
reflect my opinion.
> 2) It will be nice to know if there is some kind of logical view of a
> project like the ones in java (package, class, interfaces,
> ennumerations) or if all are references to files. I think it will be
> nice if I can focus the attention of the programmer in abstractions
> related to the paradigm or the implementation language, instead of let
> them think in files and directories, but I don't know if those kind of
> abstractions exist in a prolog porject.
Again, no. There are modules (in most serious systems) and that is
it. All the rest is your imagination. Tools that are of use are
cross-referencers, static and dynamic call-graph analysis and static
program verification tools (type checking, termination, determinism,
etc). Some of these are available in SWI-Prolog. Some others can be
found elsewhere, notably in Ciao.
> 3) Another question is about how a prolog project is deployed:
> I mean, is there a way of define what in Pascal/C/C++/Java is a main
> method?
> Are Prolog projects deployed into an executable binary file? For
> example like a Windows .exe file
> Is there any other format?
That is highly Prolog system dependent and -for SWI-Prolog- it is also
OS dependent. For SWI-Prolog and executable is a native program with
the virtual machine code sitting on its back (much like
self-extracting zip files) and a couple of DLLs/shared objects. How
the main program finds the DLLs/shared objects and how you arrange
relocating the system is OS dependent. It is doable to find resources
needed by a particular program.
In most cases programs are deployed much like Perl scripts: run them
from the source. In Unix you create a #! main program. In Windows
you simply make a shortcut to the main source file. Even sizeable
programs can be handled this way For example, the project I'm working
on loads 95,000 lines of Prolog (no big ground-fact predicates; 2.7MB)
and starts in 1.4 seconds.
> 4) How are things managed in a project using an interface with another
> language like JPL?
Complicated. It requires setting up environment variables, etc., much
of which depends on the OS and Java implementation as much as the
Prolog version ...
> 5) How are things managed in a project using a GUI librarie like XPCE?
XPCE is just another foreign extension. SWI-Prolog defineds a
`resource' mechanism to add resources such as image files to the
executable.
> 6) In Java there is a framework called JUnit which is kind of a
> standard for unit testing.
> Is there anything like this in prolog?
> I saw that Swi-prolog has a plUnit but does it work with any other
> prolog implementation?
It works for SICStus. Shouldn't be too hard to port to some other
systems (YAP, Ciao).
> Is there any standard implementantion/convention for unit testing?
No (AFAIK).
> 7) Regarding code refactors, I thought about some basic ones (renaming
> rules, reordering rules defining another rule, extracting a new rule
> from the ones used to define another rule). But I'll like to know if
> there are any other refactors more specific to prolog which I can't
> see.
I think some work has been done here, but given that Prolog far less
dictates how code is organised it is harder to refactor, I'm afraid.
The most useful support in my view are fairly simple, things such as
adding an argument and reordering arguments, both to predicates and
structures. In general, you would like an infrastructure that allows
for parsing a Prolog source file while keeping its variable names and
comments, doing term transformations on it and writing it out as a
proper human readable source file. Such an infrastructure is high
on my preference list (defined in Prolog).
> 8) Generally speaking, it would be nice if you can tell me how you
> develop a prolog project and what do you like and dislike about it.
Ideally, you should participate for a while in a larger multi-person
Prolog project in which a few experienced people participate as well.
Hope this helps (a bit)
Cheers --- Jan
bart demoen
> 7) Regarding code refactors, I thought about some basic ones (renaming
> rules, reordering rules defining another rule, extracting a new rule
> from the ones used to define another rule). But I'll like to know if
> there are any other refactors more specific to prolog which I can't see.
The following might be useful to you:
http://arxiv.org/abs/cs.SE/0702083
It was published in Volume 8, Issue 2. March 2008 of the
Journal on Theory and Practice of Logic Programming
Cheers
Bart Demoen
Claudio Cancinos
Bart, I've read that publication but I had some doubts regarding which
ones will be more interesting to implement due the incompatibilities
between prolog implementations as Jan mentioned.Ie: the ones about
modules and scope.
Jan, it is a very hard work indeed. That's why instead of building
something from the ground, my bet is on Eclipse because it is a
platform with support to make an IDE on top of him.
One thing I have in mind is to start with the basic functionality,
giving support for the most general things and later on to each
implementation particularities. That was one of the points of my
previous questions, to know something about what there is in common
between implementations and what kind of particularities should I
expect.
You gave me a lot of really useful information to research. I really
appreciate it and I'll put my hands on it as soon as possible :)
I hope you all find this project interesting and useful, and please
feel free to give any suggestion or feature request you might have :)
I'll try to post in the project site some kind of backlog or desired
features list to give some kind of better idea about the project
direction.
Best regards
Claudio Cancinos
Claudio Cancinos
Bart, I've read that publication but I had some doubts regarding which
ones will be more interesting to implement due the incompatibilities
between prolog implementations as Jan mentioned.Ie: the ones about
modules and scope.
Jan, it is a very hard work indeed. That's why instead of building
something from the ground, my bet is on Eclipse because it is a
platform with support to make an IDE on top of him.
One thing I have in mind is to start with the basic functionality,
giving support for the most general things and later on to each
implementation particularities. That was one of the points of my
previous questions, to know something about what there is in common
between implementations and what kind of particularities should I
expect.
You gave me a lot of really useful information to research. I really
appreciate it and I'll put my hands on it as soon as possible :)
I hope you all find this project interesting and useful, and please
feel free to give any suggestion or feature request you might have :)
I'll try to post in the project site some kind of backlog or desired
features list to give some kind of better idea about the project
direction.
Best regards
Claudio Cancinos
On Oct 8, 12:59 pm, bart demoen <b...@cs.kuleuven.be> wrote:
Claudio Cancinos
Bart, I've read that publication but I had some doubts regarding which
ones will be more interesting to implement due the incompatibilities
between prolog implementations as Jan mentioned.Ie: the ones about
modules and scope.
Jan, it is a very hard work indeed. That's why instead of building
something from the ground, my bet is on Eclipse because it is a
platform with support to make an IDE on top of him.
One thing I have in mind is to start with the basic functionality,
giving support for the most general things and later on to each
implementation particularities. That was one of the points of my
previous questions, to know something about what there is in common
between implementations and what kind of particularities should I
expect.
You gave me a lot of really useful information to research. I really
appreciate it and I'll put my hands on it as soon as possible :)
I hope you all find this project interesting and useful, and please
feel free to give any suggestion or feature request you might have :)
I'll try to post in the project site some kind of backlog or desired
features list to give some kind of better idea about the project
direction.
Best regards
Claudio Cancinos
On Oct 8, 12:59 pm, bart demoen <b...@cs.kuleuven.be> wrote: