From: cschuyle
Subject: Wanted: Info on Pro*Kappa language (grammar, manual, examples)
Date:
Message-ID: <ardtlc$c4t$1@news01.intel.com>
Hi all,
In around 1991-1993 I used a development environment called Pro*Kappa, from
Intellicorp (www.intellicorp.com). Evidently the product was renamed
PowerModel sometime after 1995. After a search of the Web, I find hardly a
trace of Kappa, Pro*Kappa, or PowerModel. Possibly Intellicorp developers
use its modern descendant(s) to provide Intellicorp's services, but if so,
the implementation details are private, or at least protected ... *grin*.
Does anyone have a URL, book reference, or actual documents (including
source code) which you could share, which presents a specification,
tutorial, or samples of the old Pro*Kappa programming language? It was an
interesting hybrid of procedural, object-oriented, unification, and
nondeterministic language elements.
I'm interested is this because I'm compiling a list of currently-available
rule-based languages, and I recall the hybrid procedural/chaining nature of
the Pro*Kappa language was interesting and would be valuable as a comparison
and illustration of ways to use rule-based languages.
If you would, please reply directly to me at ····@dragnon.com (and copy here
of course)
Thanks in advance!
--Carl
From: clive spenser
Subject: Re: Wanted: Info on Pro*Kappa language (grammar, manual, examples)
Date:
Message-ID: <3DE39329.7132DC78@lpa.co.uk>
can't help you with ProKappa, but pls do remember to include Flex in
your list.
flex, too, is a hybrid e/s tollkit/shell, and is situated within a logic
programming environment
clive
cschuyle wrote:
>
> Hi all,
>
> In around 1991-1993 I used a development environment called Pro*Kappa, from
> Intellicorp (www.intellicorp.com). Evidently the product was renamed
> PowerModel sometime after 1995. After a search of the Web, I find hardly a
> trace of Kappa, Pro*Kappa, or PowerModel. Possibly Intellicorp developers
> use its modern descendant(s) to provide Intellicorp's services, but if so,
> the implementation details are private, or at least protected ... *grin*.
>
> Does anyone have a URL, book reference, or actual documents (including
> source code) which you could share, which presents a specification,
> tutorial, or samples of the old Pro*Kappa programming language? It was an
> interesting hybrid of procedural, object-oriented, unification, and
> nondeterministic language elements.
>
> I'm interested is this because I'm compiling a list of currently-available
> rule-based languages, and I recall the hybrid procedural/chaining nature of
> the Pro*Kappa language was interesting and would be valuable as a comparison
> and illustration of ways to use rule-based languages.
>
> If you would, please reply directly to me at ····@dragnon.com (and copy here
> of course)
>
> Thanks in advance!
> --Carl
--
Clive Spenser, LPA
Ever wondered what people do with Prolog?
Check out: http://www.lpa.co.uk/new_lin.htm
Hi
I have checked a couple of the old expert system tools, that died.
My conclusion is that there was a good reason why they did not survive.
You can always use a procedural language.
If you define the problem I can define outline of a solution.
Rom
> cschuyle wrote:
> >
> > Hi all,
> >
> > In around 1991-1993 I used a development environment called Pro*Kappa,
from
> > Intellicorp (www.intellicorp.com). Evidently the product was renamed
> > PowerModel sometime after 1995. After a search of the Web, I find
hardly a
> > trace of Kappa, Pro*Kappa, or PowerModel. Possibly Intellicorp
developers
> > use its modern descendant(s) to provide Intellicorp's services, but if
so,
> > the implementation details are private, or at least protected ...
*grin*.
> >
> > Does anyone have a URL, book reference, or actual documents (including
> > source code) which you could share, which presents a specification,
> > tutorial, or samples of the old Pro*Kappa programming language? It was
an
> > interesting hybrid of procedural, object-oriented, unification, and
> > nondeterministic language elements.
> >
> > I'm interested is this because I'm compiling a list of
currently-available
> > rule-based languages, and I recall the hybrid procedural/chaining nature
of
> > the Pro*Kappa language was interesting and would be valuable as a
comparison
> > and illustration of ways to use rule-based languages.
> >
> > If you would, please reply directly to me at ····@dragnon.com (and copy
here
> > of course)
> >
> > Thanks in advance!
> > --Carl
>
> --
> Clive Spenser, LPA
>
> Ever wondered what people do with Prolog?
> Check out: http://www.lpa.co.uk/new_lin.htm
Yup, there's always an awkward way to do anything.
"Rom" <······@frisurf.no> wrote in message
·························@news2.e.nsc.no...
> Hi
>
> I have checked a couple of the old expert system tools, that died.
> My conclusion is that there was a good reason why they did not survive.
>
> You can always use a procedural language.
> If you define the problem I can define outline of a solution.
>
> Rom
>
>
> > cschuyle wrote:
> > >
> > > Hi all,
> > >
> > > In around 1991-1993 I used a development environment called Pro*Kappa,
> from
> > > Intellicorp (www.intellicorp.com). Evidently the product was renamed
> > > PowerModel sometime after 1995. After a search of the Web, I find
> hardly a
> > > trace of Kappa, Pro*Kappa, or PowerModel. Possibly Intellicorp
> developers
> > > use its modern descendant(s) to provide Intellicorp's services, but if
> so,
> > > the implementation details are private, or at least protected ...
> *grin*.
> > >
> > > Does anyone have a URL, book reference, or actual documents (including
> > > source code) which you could share, which presents a specification,
> > > tutorial, or samples of the old Pro*Kappa programming language? It
was
> an
> > > interesting hybrid of procedural, object-oriented, unification, and
> > > nondeterministic language elements.
> > >
> > > I'm interested is this because I'm compiling a list of
> currently-available
> > > rule-based languages, and I recall the hybrid procedural/chaining
nature
> of
> > > the Pro*Kappa language was interesting and would be valuable as a
> comparison
> > > and illustration of ways to use rule-based languages.
> > >
> > > If you would, please reply directly to me at ····@dragnon.com (and
copy
> here
> > > of course)
> > >
> > > Thanks in advance!
> > > --Carl
> >
> > --
> > Clive Spenser, LPA
> >
> > Ever wondered what people do with Prolog?
> > Check out: http://www.lpa.co.uk/new_lin.htm
>
>
>
"Ian" <···@aiinc.ca>
> Yup, there's always an awkward way to do anything.
There seems to be a lack of content in this group.
Why not post an example (just take one from tha teaching book)
that is something that can easily be programmed by rules...
then I will show you that the Delphi solution will give "clean logic", why
using backward chaining will be more uncomplete, and then we start a
firendly discussion.
Rom
From: Ralph Becket
Subject: Re: Wanted: Info on Pro*Kappa language (grammar, manual, examples)
Date:
Message-ID: <3DE6CE6A.4000606@cs.mu.oz.au>
Rom wrote:
>
> There seems to be a lack of content in this group.
> Why not post an example (just take one from tha teaching book)
> that is something that can easily be programmed by rules...
>
> then I will show you that the Delphi solution will give "clean logic", why
> using backward chaining will be more uncomplete, and then we start a
> firendly discussion.
Okay, how about the join operation for simple databases:
join(FieldsA, FieldsB, RecordsA, RecordsB, JoinRecords) :-
findall(
JoinRecord,
join_record(FieldsA, FieldsB, RecordsA, RecordsB, JoinRecord),
JoinRecords
).
join_record(FieldsA, FieldsB, RecordsA, RecordsB, FieldsA - FieldsB) :-
member(FieldsA, RecordsA),
member(FieldsB, RecordsB).
Example of use: given
RecordsA = [a(foo, 1, a), a(bar, 2, b), a(baz, 3, c)],
RecordsB = [b(bar, 2, 1.0), b(bar, 1, 0.0),
b(baz, 3, 2.0), b(quux, 1, 3.0))]
then join(a(X, _, _), b(X, _, _), RecordsA, RecordsB, Join)
will succeed with
Join = [a(bar, 2, b) - b(bar, 2, 1.0),
a(bar, 2, b) - b(bar, 1, 0.0)]
and join(a(X, Y, _), b(X, Y, _), RecordsA, RecordsB, Join)
will succeed with
Join = [a(bar, 2, b) - b(bar, 2, 1.0),
a(baz, 3, c) - b(baz, 3, 2.0)]
and join(a(_, X, _), b(_, X, _), RecordsA, RecordsB, Join)
will succeed with
Join = [a(foo, 1, a) - b(bar, 1, 0.0),
a(foo, 1, a) - b(quux, 1, 3.0),
a(bar, 2, b) - b(bar, 2, 1.0),
a(baz, 3, c) - b(baz, 3, 2.0)]
You have to admit that in terms of brevity and clarity (provided you
grok Prolog), this is rather neat. I'd be surprised if many other
languages could solve this problem with such a small amount of code.
- Ralph
"Ralph Becket" <····@cs.mu.oz.au>
> Okay, how about the join operation for simple databases:
....
> You have to admit that in terms of brevity and clarity (provided you
> grok Prolog), this is rather neat. I'd be surprised if many other
> languages could solve this problem with such a small amount of code.
Right, now I got it.
This is Prolog and this is how a relational database works.
SQL can also solve such a query...I suppose.
It cannot be done as a web search.
There is nothing problematic about finding a solution here.
Prolog uses that kind of searches as main language syntax (that is why
Prolog becomes a disasterous slow language).
These operations are already implemented in C/C++ for the sake of speed.
These operations seems to define a unknown var, but this is not a real
unknown var, but a special case where ? is something that can be solved, so
in the end there is no unknowns .... everything returned to a pure boolean
world ... very strange world.
Rom
Rom wrote:
>
> These operations are already implemented in C/C++ for the sake of speed.
You can do pretty much anything in any language. That an SQL engine
has been implemented in C/C++ doesn't support your thesis.
This thread essentially started when you wrote:
> Why not post an example (just take one from tha teaching book)
> that is something that can easily be programmed by rules...
> then I will show you that the Delphi solution will give "clean logic", why
> using backward chaining will be more uncomplete, and then we start a
> firendly discussion.
You have not shown a Delphi solution and so we have no evidence of
Delphi supporting "clean logic".
You have not shown why "backward chaining will be more uncomplete[sic]
[than what?]"
You've only made some not terribly coherent pronouncements on the nature
of Prolog and the problem in question.
I contend that the Prolog solution is beautifully simple and, for an
in-memory database, should run at close to the speed of a solution in
any other language. I also contend that solutions in other languages
are going to be longer and less transparent.
So you should really produce a functionally equivalent Delphi program
and use that to support your case.
- Ralph
"Ralph Becket" <····@cs.mu.oz.au> skrev i melding
> You have not shown a Delphi solution and so we have no evidence of
> Delphi supporting "clean logic".
Right. Since you haven't stated any problem to solve...I can state one. How
to program something like the problem below with Prolog (I mean a program
that can give advice about which shell you should chose given the demands
that are stated)?
I suppose it can be done in Prolog since the example is from a learning book
about expert system by R. J. Mockler. I can write a Delphi solution here in
little time that is faultless, and it can be integrated with other program,
or easily adapted to Perl... and be put on the web. No problems.
Rom
(problem)
ESIE would only be recommended for situations in which the
developer did not have much computer experience, the size of the
system to be developed was very small, there was no required
software interface, user interface requirements were limited, and
there was the need for backward chaining only.
VP-Expert would be recommended for situations in which
developers'' computer experience ranged from high to low, the
size of the system to be developed ranged from small to large,
software interface with Lotus 1-2-3 or Dbase was required, user
interface requirements were not of paramount importance, and
there was the need for either backward or forward chaining.
M.1 would be recommended for situations in which developers''
computer experience ranged from high to average, the size of the
system to be developed ranged from small to large, software
interface with Lotus 1-2-3 or Dbase was not required, user
interface requirements were important, and there was the need for
mainly backward chaining.
GURU would be recommended for situations in which
developers'' computer experience was high, the size of the system
to be developed was large, software interface with Lotus 1-2-3 or
Dbase was needed, user interface requirements were of paramount
importance, and there was the need for either backward or forward
chaining.
(problem end)
Rom wrote:
> "Ralph Becket" <····@cs.mu.oz.au> skrev i melding
>
>
>>You have not shown a Delphi solution and so we have no evidence of
>>Delphi supporting "clean logic".
>
>
> Right. Since you haven't stated any problem to solve...I can state one. How
> to program something like the problem below with Prolog (I mean a program
> that can give advice about which shell you should chose given the demands
> that are stated)?
Er, but I did. In my post on the 29th starting
| The simplified join operation: given two sets of records, As and Bs,
| find the set, Join, of all pairs of records, A - B, such that
| A in As, B in Bs and A and B have the same value in the fields specified
| by a given pattern.
and followed it up with several examples. You even have an implementation
to guide understanding. If you don't understand the implementation, how
can you hope to compare Delphi (or whatever) with Prolog?
> I suppose it can be done in Prolog since the example is from a learning book
> about expert system by R. J. Mockler. I can write a Delphi solution here in
> little time that is faultless, and it can be integrated with other program,
> or easily adapted to Perl... and be put on the web. No problems.
% recommend(System, DeveloperExperience, ProjectSize, SoftwareInterface,
% UIRequirements, Chaining)
%
recommend(esie, low, very_small, none, limited, backwards).
recommend(vp_expert, _, ProjSize, lotus_123, UIReqs, _) :-
ProjSize \= very_small,
UIReqs \= paramount.
recommend(m_1, DevExp, ProjSize, SI, important, backwards) :-
DevExp \= low,
ProjSize \= very_small,
SI \= lotus_123,
SI \= dbase.
recommend(guru, high, large, SI, paramount, _) :-
( SI = lotus_123
; SI = dbase
).
- Ralph
"Ralph Becket" <····@cs.mu.oz.au> wrote
> % recommend(System, DeveloperExperience, ProjectSize,
SoftwareInterface,
> % UIRequirements, Chaining)
> %
> recommend(esie, low, very_small, none, limited, backwards).
>
> recommend(vp_expert, _, ProjSize, lotus_123, UIReqs, _) :-
> ProjSize \= very_small,
> UIReqs \= paramount.
>
> recommend(m_1, DevExp, ProjSize, SI, important, backwards)
:-
> DevExp \= low,
> ProjSize \= very_small,
> SI \= lotus_123,
> SI \= dbase.
>
> recommend(guru, high, large, SI, paramount, _) :-
> ( SI = lotus_123
> ; SI = dbase
> ).
I will try try to use similar names.
Variables and values:
DeveloperExperience
Low,
High
ProjectSize
Very_small,
High
SoftwareInterface
None,
Lotus_123,
dbase
UIRequirements
Limited,
Important,
Paramount
Chaining
Backwards,
Forwards
Then if the facts are:
DeveloperExperience = Low
ProjectSize = Very_small
SoftwareInterface = (empty)
UIRequirements = (empty)
Chaining = Backwards
Then the program should return....
It can be Esie
It can be VP-expert
It can be M-1
It cannot be Guru because Guru requires high DeveloperExperience .. and
more.
Have I got it right?
Regards
Rom
Rom wrote:
> "Ralph Becket" <····@cs.mu.oz.au> wrote
>> % UIRequirements, Chaining)
>> %
>>recommend(esie, low, very_small, none, limited, backwards).
>>
>>recommend(vp_expert, _, ProjSize, lotus_123, UIReqs, _) :-
>> ProjSize \= very_small,
>> UIReqs \= paramount.
>>
>>recommend(m_1, DevExp, ProjSize, SI, important, backwards) :-
>> DevExp \= low,
>> ProjSize \= very_small,
>> SI \= lotus_123,
>> SI \= dbase.
>>
>>recommend(guru, high, large, SI, paramount, _) :-
>> ( SI = lotus_123
>> ; SI = dbase
>> ).
>
> Then if the facts are:
>
> DeveloperExperience = Low
This limits us to esie or vp_expert.
> ProjectSize = Very_small
This further constrains us to esie.
> SoftwareInterface = (empty)
This is consistent with esie (assuming (empty) is the same as `none').
> UIRequirements = (empty)
This is consistent with esie (assuming (empty) is the same as `limited').
> Chaining = Backwards
This is consistent with esie.
> Then the program should return....
> It can be Esie
Yes.
> It can be VP-expert
> It can be M-1
No.
> Have I got it right?
You posted the problem specification!
- Ralph
"Ralph Becket" <····@cs.mu.oz.au> wrote:
> > Then if the facts are:
> > DeveloperExperience = Low
>
> This limits us to esie or vp_expert.
Okey, the meaning of "DevExp \= low" was NOT "low".
> > ProjectSize = Very_small
>
> This further constrains us to esie.
I forgot to state "small" as some possible value for Projectsize.
> > SoftwareInterface = (empty)
>
> This is consistent with esie (assuming (empty) is the same as `none').
I was thinking that either user did not know here or he did not answer that
question, so the answer is something we don't know yet....?
Below is a Delphi solution. It returns "ESIE is maybe usable" for the
stated facts.
What should the answer be for these facts?
// facts
High_DeveloperExperience := eNil;
very_small_ProjectSize := eFalse;
small_ProjectSize := eTrue;
Large_ProjectSize := eFalse;
Lotus_123_SoftwareInterface := eNil;
dbase_SoftwareInterface := eNil;
UIRequirements_is_important := eFalse;
UIRequirements_is_paramount := eFalse;
Backwards_Chaining := eNil;
Forwards_Chaining := eNil;
The Delphi program returns:
VP-Expert is suitable
M-1 is maybe usable
Is that a correct answer? If the Prolog solution returns something else,
what is the best answer?
Regards
Rom
Delphi solution
(add a Buttom and a RichEdit to a form first)
type TEBoolean = ( eFalse, eNil, eTrue);
var
High_DeveloperExperience,
Very_small_ProjectSize,
Small_ProjectSize,
Large_ProjectSize,
Lotus_123_SoftwareInterface,
dbase_SoftwareInterface,
UIRequirements_is_important,
UIRequirements_is_paramount,
Backwards_Chaining,
Forwards_Chaining: TeBoolean;
implementation
function pAND( a1, a2: TeBoolean): TeBoolean;
begin
Result := eTrue;
if Ord( a1) < Ord( Result) then Result := a1;
if Ord( a2) < Ord( Result) then Result := a2;
end;
function pNOT( a1: TeBoolean): TeBoolean;
begin
case a1 of
eTrue: Result := eFalse;
eFalse: Result := eTrue;
else
Result := eNil;
end;
end;
procedure TForm1.EvaluateShells;
var
res: TeBoolean;
begin
// ESIE
res := pAND( pNOT( High_DeveloperExperience),
(pAND( pNOT( Small_ProjectSize),
(pAND( pNOT( Large_ProjectSize),
(pAND( pNOT( Lotus_123_SoftwareInterface),
(pAND( pNOT( dbase_SoftwareInterface),
(pAND( pNOT( UIRequirements_is_important),
(pAND( pNOT( UIRequirements_is_paramount),
( pNOT( Forwards_Chaining)) )))))))))))));
case res of
eTrue: RichEdit1.Lines.Add( 'ESIE is suitable');
eNil: RichEdit1.Lines.Add( 'ESIE is maybe usable');
end;
// VP-Expert
res := (pAND( pNOT( Very_small_ProjectSize),
( pNOT( UIRequirements_is_paramount)) ));
case res of
eTrue: RichEdit1.Lines.Add( 'VP-Expert is suitable');
eNil: RichEdit1.Lines.Add( 'VP-Expert is maybe usable');
end;
// M-1
res := pAND( High_DeveloperExperience,
(pAND( pNOT( Very_small_ProjectSize),
(pAND( pNOT( Lotus_123_SoftwareInterface),
(pAND( pNOT( dbase_SoftwareInterface),
(pAND( pNOT( UIRequirements_is_paramount),
( pNOT( Forwards_Chaining)) )))))))));
case res of
eTrue: RichEdit1.Lines.Add( 'M-1 is suitable');
eNil: RichEdit1.Lines.Add( 'M-1 is maybe usable');
end;
// GURU
res := pAND( High_DeveloperExperience,
(pAND( pNOT( Very_small_ProjectSize),
pNOT( Small_ProjectSize)) ));
case res of
eTrue: RichEdit1.Lines.Add( 'GURU is suitable');
eNil: RichEdit1.Lines.Add( 'GURU is maybe usable');
end;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
// facts
High_DeveloperExperience := eFalse;
very_small_ProjectSize := eTrue;
small_ProjectSize := eFalse;
Large_ProjectSize := eFalse;
Lotus_123_SoftwareInterface := eNil;
dbase_SoftwareInterface := eNil;
UIRequirements_is_important := eNil;
UIRequirements_is_paramount := eNil;
Backwards_Chaining := eTrue;
Forwards_Chaining := eFalse;
// returns "ESIE is maybe usable"
evaluateShells;
end;
Rom wrote:
> "Ralph Becket" <····@cs.mu.oz.au> wrote:
>>>ProjectSize = Very_small
>>
>>This further constrains us to esie.
>
> I forgot to state "small" as some possible value for Projectsize.
I merely assumed that very_small was the least member of the set of
project sizes.
Either way, the only solution for developers with low experience
tackling very small projects is ESIE.
>>>SoftwareInterface = (empty)
>>
>>This is consistent with esie (assuming (empty) is the same as `none').
>
> I was thinking that either user did not know here or he did not answer that
> question, so the answer is something we don't know yet....?
In Prolog one writes `don't care' variables as just `_'.
> Below is a Delphi solution. It returns "ESIE is maybe usable" for the
> stated facts.
>
> What should the answer be for these facts?
> // facts
> High_DeveloperExperience := eNil;
> very_small_ProjectSize := eFalse;
> small_ProjectSize := eTrue;
> Large_ProjectSize := eFalse;
> Lotus_123_SoftwareInterface := eNil;
> dbase_SoftwareInterface := eNil;
> UIRequirements_is_important := eFalse;
> UIRequirements_is_paramount := eFalse;
> Backwards_Chaining := eNil;
> Forwards_Chaining := eNil;
This is a terrible way to represent the parameters. Every natural
parameter has been replaced with a *set* of parameters - in a three
valued logic, no less - at most one of which can be eTrue (the rest
being eFalse) or all of which must be eNil.
Surely one would expect Large_ProjectSize = eTrue to imply
small_ProjectSize = eFalse?
> Delphi solution
You can't seriously claim this as a model of clarity when compared
to the Prolog solution? It's pages long and it's not at all obvious
whether it's correct or not.
> function pAND( a1, a2: TeBoolean): TeBoolean;
> begin
> Result := eTrue;
> if Ord( a1) < Ord( Result) then Result := a1;
> if Ord( a2) < Ord( Result) then Result := a2;
> end;
You have to take ordinal values in order to compare things?
Ye gods...
- Ralph
"Ralph Becket" <····@cs.mu.oz.au>
> You can't seriously claim this as a model of clarity when compared
> to the Prolog solution? It's pages long and it's not at all obvious
> whether it's correct or not.
The Delphi program is as good as my understanding of the problem is.
Obviously the Prolog solution and the Delphi solution give different answers
for some cases.
I don't know what have to be done to make the Prolog program as accurate as
the Delphi program, so that they give identical answers. You are the right
one to answer that.
I am wondering if equal solutions here we show that the Prolog solution
becomes shorter? (otherwise it is not fair to compare length)
Rom
Rom wrote:
> Obviously the Prolog solution and the Delphi solution give different answers
> for some cases.
But they shouldn't! The spec. is unambiguous and has a unique solution
for the parameters you set.
> I don't know what have to be done to make the Prolog program as accurate as
> the Delphi program, so that they give identical answers. You are the right
> one to answer that.
What makes you think the Prolog program is in error? Close scrutiny does
reveal one bug: VP-Expert is also a candidate if the software interface
requirement specifies dBase. A two-line fix.
> I am wondering if equal solutions here we show that the Prolog solution
> becomes shorter? (otherwise it is not fair to compare length)
There are a number of different axes you could compare these programs on:
- correctness;
- maintainability;
- efficiency;
- clarity;
- brevity.
(IMHO this reads from most important to least important.)
I don't want to turn this into a language war, but it's hard to see how
your Delphi program wins on any of these measures. Given that *you*
picked the problem in the first place to demonstrate the inferiority of
logic programming with respect to imperative programming, perhaps you
should reconsider your position.
- Ralph
"Ralph Becket" <····@cs.mu.oz.au>
> Given that *you* picked the problem in the first place to demonstrate
> the inferiority of logic programming with respect to imperative
> programming, .....
Fair enought.... if you can post an small problem that is more suitable for
Prolog?
>..... perhaps you should reconsider your position.
I am considering.... I will answer tomorrow.
Regards
Rom
Rom wrote:
>
> Fair enought.... if you can post an small problem that is more suitable for
> Prolog?
Is this a troll? So far each of us has picked a problem which has been
solved in Prolog in an elegant and concise fashion. How do you come to
the conclusion that we need "more suitable" problems to argue your case?
- Ralph
From: "Ralph Becket" <····@cs.mu.oz.au>
| > Fair enought.... if you can post an small problem that is more suitable
for
| > Prolog?
|
| Is this a troll? So far each of us has picked a problem which has been
| solved in Prolog in an elegant and concise fashion. How do you come to
| the conclusion that we need "more suitable" problems to argue your case?
The "problem" you posted was about a general algoritm, that can be found in
many libraries. I did not see much point in retrieving the C/C++
implementation here and translate it to Delphi (there is only minor
differences between C++ and Delphi). I don't see much point in asking anyone
to program a TRichEdit component in Prolog either (the Delphi source for it
can be found in the VCL library).
I do not see anything unusual in the case I posted that will make it an
unfair programming task for Prolog.
Rom
"Ralph Becket" <····@cs.mu.oz.au <···········@cs.mu.oz.au>>
| There are a number of different axes you could compare these programs on:
| - correctness;
| - maintainability;
| - efficiency;
| - clarity;
| - brevity.
| (IMHO this reads from most important to least important.)
Accepted.
| > Obviously the Prolog solution and the Delphi solution give different
answers
| > for some cases.
|
| But they shouldn't! The spec. is unambiguous and has a unique solution
| for the parameters you set.
You have the Prolog program.... can you say what it returns for this case:
High_DeveloperExperience := eNil;
very_small_ProjectSize := eNil;
small_ProjectSize := eNil;
Large_ProjectSize := eNil;
Lotus_123_SoftwareInterface := eNil;
dbase_SoftwareInterface := eNil;
UIRequirements_is_important := eNil;
UIRequirements_is_paramount := eNil;
Backwards_Chaining := eTrue;
Forwards_Chaining := eFalse;
The Delphi program returns:
ESIE is maybe usable
VP-Expert is maybe usable
M-1 is maybe usable
GURU is maybe usable
Rom
Ralph Becket wrote:
> Rom wrote:
>
> >
> > There seems to be a lack of content in this group.
> > Why not post an example (just take one from tha teaching book)
> > that is something that can easily be programmed by rules...
> >
> > then I will show you that the Delphi solution will give "clean logic",
> > why
> > using backward chaining will be more uncomplete, and then we start a
> > firendly discussion.
>
>
> Okay, how about the join operation for simple databases:
>
> join(FieldsA, FieldsB, RecordsA, RecordsB, JoinRecords) :-
> findall(
> JoinRecord,
> join_record(FieldsA, FieldsB, RecordsA, RecordsB, JoinRecord),
> JoinRecords
> ).
>
> join_record(FieldsA, FieldsB, RecordsA, RecordsB, FieldsA - FieldsB) :-
> member(FieldsA, RecordsA),
> member(FieldsB, RecordsB).
>
> Example of use: given
>
> RecordsA = [a(foo, 1, a), a(bar, 2, b), a(baz, 3, c)],
> RecordsB = [b(bar, 2, 1.0), b(bar, 1, 0.0),
> b(baz, 3, 2.0), b(quux, 1, 3.0))]
>
> then join(a(X, _, _), b(X, _, _), RecordsA, RecordsB, Join)
> will succeed with
>
> Join = [a(bar, 2, b) - b(bar, 2, 1.0),
> a(bar, 2, b) - b(bar, 1, 0.0)]
>
> and join(a(X, Y, _), b(X, Y, _), RecordsA, RecordsB, Join)
> will succeed with
>
> Join = [a(bar, 2, b) - b(bar, 2, 1.0),
> a(baz, 3, c) - b(baz, 3, 2.0)]
>
> and join(a(_, X, _), b(_, X, _), RecordsA, RecordsB, Join)
> will succeed with
>
> Join = [a(foo, 1, a) - b(bar, 1, 0.0),
> a(foo, 1, a) - b(quux, 1, 3.0),
> a(bar, 2, b) - b(bar, 2, 1.0),
> a(baz, 3, c) - b(baz, 3, 2.0)]
>
> You have to admit that in terms of brevity and clarity (provided you
> grok Prolog), this is rather neat. I'd be surprised if many other
> languages could solve this problem with such a small amount of code.
>
> - Ralph
>
Suppose I am given
a(foo, 1, a).
a(bar, 2, b).
a(baz, 3, c).
b(bar, 2, 1.0).
b(bar, 1, 0.0).
b(baz, 3, 2.0).
b(quux, 1, 3.0).
In this case, a 'join' operation on the first argument of a/1 and the
first argument of b/1 can be translated directly into something like
join_a1_b1(X, result(joint(X), a2(A2), a3(A3), b2(B2), b3(B3))) :-
a(X, A2, A3),
b(X, B2, B3).
This looks to me like something that could be handled quite nicely by
a macro processor such as GNU's m4.
Has anyone investigated a macro processor approach to the problem of
translating relational algebra straight into pure Prolog?
--
wdbh
From: Ralph Becket
Subject: Re: Wanted: Info on Pro*Kappa language (grammar, manual, examples)
Date:
Message-ID: <3DEA9AAA.2000804@cs.mu.oz.au>
anon wrote:>
> In this case, a 'join' operation on the first argument of a/1 and the
> first argument of b/1 can be translated directly into something like
>
> join_a1_b1(X, result(joint(X), a2(A2), a3(A3), b2(B2), b3(B3))) :-
> a(X, A2, A3),
> b(X, B2, B3).
>
Yes, but then you have to write a special join predicate for every
possible pair of record types and argument specs that you're interested
in. My solution is general.
> This looks to me like something that could be handled quite nicely by a
> macro processor such as GNU's m4.
But why would you bother?
> Has anyone investigated a macro processor approach to the problem of
> translating relational algebra straight into pure Prolog?
Prolog already is pretty close to pure relational (tuple-at-a-time)
algebra. If you use Mercury and stick to ground terms, mode reordering
will get around problems caused by standard Prolog's fixed evaluation
strategy. If you use HAL (built on Mercury) you can even lift the
restriction to ground terms.
- Ralph
Ralph Becket wrote:
> anon wrote:>
>
> > In this case, a 'join' operation on the first argument of a/1 and the
> > first argument of b/1 can be translated directly into something like
> >
> > join_a1_b1(X, result(joint(X), a2(A2), a3(A3), b2(B2), b3(B3))) :-
> > a(X, A2, A3),
> > b(X, B2, B3).
> >
>
> Yes, but then you have to write a special join predicate for every
> possible pair of record types and argument specs that you're interested
> in. My solution is general.
>
> > This looks to me like something that could be handled quite nicely by
> > a macro processor such as GNU's m4.
>
>
> But why would you bother?
No bother, really.
>
> > Has anyone investigated a macro processor approach to the problem of
> > translating relational algebra straight into pure Prolog?
>
> Prolog already is pretty close to pure relational (tuple-at-a-time)
> algebra.
That is my point, but given that much of the explosive growth in
modern logic and metamathematics since at least 1936 has stemmed
directly from a recognition of the importance of making a careful and
systematic distinction between use amd mention, some of us fail to see
how anyone could possibly have imagined there would be anything to gain
by obliterating that distinction in the name of "amalgamating the meta
language and the object language" and would therefore like to see it
restored: using a macro processor to implement such ideas as as 'join'
and 'findall' would be one way of doing that in a way that would be hard
to confuse with predicate language proper.
Thank you.
/Has/ anyone investigated a macro processor approach to the problem of
translating relational algebra straight into pure Prolog?
From: Ralph Becket
Subject: Re: Wanted: Info on Pro*Kappa language (grammar, manual, examples)
Date:
Message-ID: <3DE6E17A.2010101@cs.mu.oz.au>
Rom wrote:
> Could you not formulate the problem again (If it is posted already..I missed it)?
> (Maybe you have stolen my point of view)
The simplified join operation: given two sets of records, As and Bs,
find the set, Join, of all pairs of records, A - B, such that
A in As, B in Bs and A and B have the same value in the fields specified
by a given pattern.
So, from my examples:
join(a(X, _, _), b(X, _, _), As, Bs, Join)
means that each A and B in the resulting Join must have the same value
in their first fields;
join(a(X, Y, _), b(X, Y, _), As, Bs, Join)
means that each A and B in the resulting Join must have the same
corresponding values in their first two fields;
join(a(_, X, _), b(_, X, _), As, Bs, Join)
means that each A and B in the resulting Join must have the same value
in their second fields;
join(a(Y, X, _), b(_, X, Y), As, Bs, Join)
means that each A and B in the resulting Join must satisfy the property
that field one of A is the same as field three of B and they each have
field two in common;
and so on. It's a key operation for relational databases.
- Ralph