Coding Guidelines for Prolog
Roberto Bagnara
Here is a preprint that may be of interest:
http://arxiv.org/abs/0911.2899
Constructive comments are welcome, either to
the group or directly to myself (I will of course
share them with my coauthors so that we can take
them into account for the next revisions of the paper).
All the best,
Roberto
--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bag...@cs.unipr.it
A.L.
<bag...@cs.unipr.it> wrote:
>
>Here is a preprint that may be of interest:
>
> http://arxiv.org/abs/0911.2899
>
>Constructive comments are welcome, either to
>the group or directly to myself (I will of course
>share them with my coauthors so that we can take
>them into account for the next revisions of the paper).
>All the best,
>
> Roberto
Good!
More about testing:
Use tools for unit testing, implement detailed unit testing, document
tests and run tests in batches when substantial changes to the code
are made. Run tests frequently.
Some Prologs provide tools for unit testing - SWI has (excellent!)
package plunit documented in
http://www.swi-prolog.org/pldoc/package/plunit.html
Rationale for implementing unit tests is provided there, as well as
detailed guidance for using testing framework
Other Prolog environments don't provide such package, but this is not
the excuse for NOT doing unit testing. Recently on SICStus forum
somebody presented simple but convenient unit testing package for
SICStus (1 page of code); I implemented similar system myself within
few hours
A.L.
A.L.
<bag...@cs.unipr.it> wrote:
>
>Here is a preprint that may be of interest:
>
> http://arxiv.org/abs/0911.2899
>
>Constructive comments are welcome, either to
>the group or directly to myself (I will of course
>share them with my coauthors so that we can take
>them into account for the next revisions of the paper).
>All the best,
>
> Roberto
6.1 Invest appropriate (not excessive) effort in the program;
distinguish a prototype from finished product
Many Prolog Programs are exploratory....
Actually, some Prolog programs are developed in commercial
environment; in such cases any attempt to distinguish between
production version and development version is not excessive
Keep production version and various development versions in the same
source file(s). Switch between production version and development
version by using Prolog goal_expansion feature.
Some Prologs offer conditional compilation that can be used for this
purpose
A.L.
Jan Wielemaker
Thanks for the compliments.
Actually (I'm now authorized to make this public), the SWI-Prolog unit
test framework has been paid for by Secerno. It was supposed to run on
SWI and SICStus (3.x). I've received some patches for SICStus 4. These
are applied. I have no access to SICStus 4, so I can't verify this.
Since then, the library has been extended significantly by myself and
Ulrich Neumerkel and it is quite possible that the SICStus compatibility
is broken.
Nevertheless. anyone is welcome to port it and -in particular-, send me
patches that make it more portable. It should be portable to systems
with a Quintus-like module system and term-expansion.
Cheers --- Jan
A.L.
<bag...@cs.unipr.it> wrote:
>
>Here is a preprint that may be of interest:
>
> http://arxiv.org/abs/0911.2899
>
>Constructive comments are welcome, either to
>the group or directly to myself (I will of course
>share them with my coauthors so that we can take
>them into account for the next revisions of the paper).
>All the best,
>
> Roberto
Develop "ad-hoc" runtime type checking system. Many problems during
development (especially if program is large and there are many
developers involved) are caused by passing incorrect argument. Yes,
documentation should document what means "proper argument", but
sometimes can be overlooked or ignored. If wrong argument is passed,
Prolog usually says politely "no", and this happens 3 miles from the
place where mistake was made.
The practice of doing "ad-hoc" type checking comes from Smalltalk;
applying this practice cut debugging time essentially
Here is the sample
Self <- get_no_action_stop_service_start_time_at_stop(Stop,
NoActionStopServiceStartTime) :-
must_be_instance_of(Self, carrier_move_stop, Stop,
[carrier_move, get_no_action_stop_service_start_time_at_stop]),
....
"must_be_instance_of" is performing test within development version
only. In production version, testing is eliminated by using
goal_expansion feature, or can be eliminated completely by using one
of the general porpose macro processors or scripts written in AWK or
Perl
A.L.
Ulrich Neumerkel
Quite a lot of people did try plunit for SICStus 3
but then refrained using it.
The reason seems to be that ISO compliant errors which
are of the form throw(error(Error_term,Imp_def))
are reported uniformly as Instantiation Errors by the toplevel
up to (at least) 3.12.5 if Imp_def is a free variable. What else
should go there, if one wants to write portable programs?
ulrich@gupu2:~$ /opt/gupu/sicstus3.12.5/bin/sicstus --iso -f
SICStus 3.12.5 (x86-linux-glibc2.2): Sun Mar 12 09:39:20 CET 2006
Licensed to complang.tuwien.ac.ata
| ?- throw(error(type_error(list,a),_)).
! Instantiation error
Of course Imp_def is an implementation defined term (7.12.1)
and the toplevel is out of the Scope of 13211-1 (1, Note f).
Above behavior is thus not in literal contradiction to 13211-1.
But then, the extra error/2 wrapper around the actual error
term was introduced to improve portability - not to reduce it.