🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.prolog
Article #4157

Re: incrementing values

#4157
From: John Cleary
Date: Wed, 07 Feb 1990 04:32
82 lines
3836 bytes
In article <4884@itivax.iti.org>, dhw@itivax.iti.org (David H. West) writes:
> In article <17483@megaron.cs.arizona.edu> debray@cs.arizona.edu (Saumya K. Debray) writes:
>> | 	increment(Variable) :-
>> | 		retract(value(Variable, OldValue)),
>> | 		NewValue is OldValue + 1,
>> | 		assert(value(Variable, NewValue)).
>  
> >Somehow "X1 is X+1" seems so much simpler!

Lets get this straight.  Almost always you dont need to do something like this.
A great many problems can be solved by adding one to a variable and then 
passing it along as an argument.  Indeed among students code like this is
often a sign that they have not understood what logic programming is about.

However, there are times when it is essential, (for example counting how many
times clauses are invoked).  
It is also apparrent that there is no simple intuitive, well defined, and 
portable semantics for constructs like this.  This is a big problem for
Logic programming ingeneral, HOW DO YOU DIRECTLY MODEL MUTATION AND UPDATE
IN LOGIC PROGRAMMING?

I personally feel that the only way to do this is to explicitly represent
time within Logic Programming.  Indded the words mutate and update can only
be defined by reference to time, so it seems clear that to deal with
these issues logically time must be there directly in the language so the
logic "knows what to talk about".

I wouldnt talk like this unless I thought there was a solution to the
problem (it is very depressing to talk about insoluble problems).
There are a group of us here at Calgary developing a language called
Starlog (its not an acronym :-)).  This assumes that each predicate
has its first parameter a time varibale which is a real number (>= 0).
The language is executed bottom up and is scheduled forward in time
(predicates with low time values are executed first), real numbers are
represented INTERNALLY by real intervals and can be constrained by arithmetic
expressions.  Negation is available and is given a semantics by assuming that
the program is temorally stratified (that is all operations are causal,
the truth of a predicate at a particular time can only affect the truth of
things in its future).

The following simple program shows a representation of a simple database and
how it can be updated.

The predicates are:

value(Time,Key,Value)   The Key has a Value at a particular Time

input(Time,Key,Value)   The Key gets a new Value at a particular Time

value is defined in terms of the inputs:

	value(Time0,Key,Value) <- 
		Time0>=Time, 
		input(Time,Key,Value),
		not(exists T, Time0>=T, T>Time, input(T,Key,_)).

This may be paraphrased as:
	The Key has the Value at time Time0 provided it is after the Time
of an input with the Key and Value and provided there has been no other input
following Time and before Time0.  

That is a Key will take on a value from an input until the next input for 
that Key occurs.

For example, if the following inputs occur then the resulting true
atoms for value are: (note the use of ( and [ for open and closed intervals)

input(1,a,23)

input(2.5,b,42)

input(3.5,a,99)

value([1,3.5),a,23)
value([3.5,infinity),a,99)
value([2.5,infinity),b,42)

This solves the database update problem and can be implemented reasonably
efficiently.

John Cleary
cleary@cpsc.ucalgary.ca
Technical Details
Message-ID: <2484@cs-spool.calgary.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!van-bc!ubc-cs!alberta!calgary!cpsc!cleary
References: <17467@megaron.cs.arizona.edu> <31462@shemp.CS.UCLA.EDU> <4884@itivax.iti.org>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!van-bc!ubc-cs!alberta!calgary!cpsc!cleary
From: cleary@cpsc.ucalgary.ca (John Cleary)
Newsgroups: comp.lang.prolog
Subject: Re: incrementing values
Summary: a fundamental problem
Message-ID: <2484@cs-spool.calgary.UUCP>
Date: 7 Feb 90 04:32:25 GMT
References: <17467@megaron.cs.arizona.edu> <31462@shemp.CS.UCLA.EDU> <4884@itivax.iti.org>
Sender: news@calgary.UUCP
Lines: 82