Best Regards
Gary
Andrew Dadakow wrote:
>
> Gary,
> I thing that's a vague question. Aren't the domains mentioned the same?
>
> Andrew Answer ( 1 apr 97 )
Lisp is probably easier to get to grips with coming from an imperative
background, but is weaker on the symbol manipulation front. There are
also some wonderful development tools around for Lisp. The drawback
is that Common Lisp has everything including the kitchen sink (Guy
Steele's CL *reference book* is over 1000 pages long!) and learning to
use all these wonderful facilities productively would take much longer
than your four months.
A good alternative is Scheme or (even better) ML, if you want a
functional language. Both of these languages are small, concise, well
supported, efficient and (relative to Lisp at least) free of
oddnesses.
Prolog is *awesome* at symbol manipulation and it's flow of control is
depth first, so it is ideally suited to searching problems. However,
if you haven't had any experience with logic programming, Prolog can
be very confusing to the novice (even though it's a beautifully simple
little language). Apart from being untyped, it's also a real pain
when a predicate that is supposed to be deterministic ends up
backtracking all over the place - makes debugging a real pain at
times.
For my money, Mercury is a much better option. It looks pretty
similar to Prolog, but type and mode declarations are mandatory.
The compiler spots many many bugs for you and generates code of
unprecedented quality in the LP community.
2p.
Ralph
--
Ralph....@cl.cam.ac.uk http://www.cl.cam.ac.uk/users/rwab1
>[other things]
>For my money, Mercury is a much better option. It looks pretty
>similar to Prolog, but type and mode declarations are mandatory.
>The compiler spots many many bugs for you and generates code of
>unprecedented quality in the LP community.
Actually, as of the last release (0.6) the Mercury compiler supports
local type and mode inference of predicates (with some limitations). It
is still mandatory to declare types and modes for exported predicates,
and to write the declarations for the types you wish to use.
From the release notes:
* We now provide preliminary support for type and mode inference.
The `:- pred' and `:- mode' declarations are now optional for
predicates that are local to a module; the compiler will
infer the types and modes automatically.
This support is not yet complete, and so type and mode
inference are not enabled by default. They can be enabled
using the `--infer-types' and `--infer-modes' options. The
limitations of the current implementation are: (1) type inference
loops for certain very rare type-incorrect programs; (2) mode
inference doesn't support reordering; (3) there are some
modes which the current mode inference algorithm is not
capable of inferring. Note that omitting type and mode
declarations can significantly reduce the quality of the
compiler's error messages; if you have trouble understanding
an error message, then it is a good idea to add explicit type
and mode declarations.
I personally don't use the inference, as I find writing type and mode
declarations clarifies my thinking about design, and the declarations
are good documentation for later modifications.
For more information on Mercury, try the Mercury homepage:
http://www.cs.mu.oz.au/mercury
Here are more details about the problem
The problem domain:
The system I have to develop is a rule based control system.
It uses a variation of the backward chaining algorithm
and other inference algorithms as well (e.g. a variation on
forward chaining). The different inference algorithms all operate on
the same rules and facts. The system also involves other types of
searches through the rules and facts.
The rule base is very large.
Since I use more than one inference technique on the same rules
I must program by changing inference algorithms and not the
knowledge base.
Further more, I have to use the same rule base with many
different intantiations of the facts base. This can be easily
done by using classes and objects. I know CLOS is a pretty
standard OO solution under Lisp, I haven’t seen any similar
solution in Prolog, is there one ? Is there a better/different way
of achiving the same result without objects ?
The development environment:
This project is not intended for academic purposes. My intention is
to develop a prototype (in 3, 4 month) and once the concept is proven,
to continue further development.
I therefor want to start developing on a free or very cheap
development environment for a PC (preferably Windows95, but Linux would
do) and then purchase a commercial tool for further development.
I do not want to have a 'Catholic wedding' with a specific development
tool. I want to be able to easily change a tool if I run into problems.
This means that I don't want to use any vendor specific
extensions or extremely unique and non standard features, languages
or tools.
Further I know that if I develop the system bottom upwards, Prolog
will get me up to speed quicker by using it's inherent pattern
matching and backward inference. I wonder though if I will not
encounter difficulties once I want to expand to multiple
instantiations of fact bases (OO as mentioned above).
{ One more note to news readers. The last thing I want to do is
start a flame (which I might already have done). I am looking for
a real solution to a specific problem, not a "who's God is stronger"
flame.}
Yours truly
Gary
With such limited time, I don't think I'd recommend using any language
with which you are unfamiliar.
--
Karen A. Morrissey mailto:kxm...@uswest.com (USW business)
US West Communications mailto:kmorr...@aol.com (other bus. &
personal)
1801 California (on assignment from Analysts International)
Suite 310
Denver, CO 80202 42 = the 8-bit checksum of the universe.
303-965-8473
Both are commercially available and proved popular in introducing
symolic programming languages to industry in the shape of Expert Systems
tools.
clive spenser
marketing director
lpa ltd
studio 4, rvpb, http://www.lpa.co.uk
trinity road, london fax: +44 (0) 181 874 0449
sw18 3sx, england tel: +44 (0) 181 871 2016