Prolog - Psuedo_Newbie: Data Storage?

Author

Psuedo_Newbie: Data Storage?

Freejack

2005-07-28, 5:02 pm

Prolog and Oz are giving me a good workover in the area of Logic
programming. I'm really starting to like both languages. However, one
thing is kinda chaffing my ass. Prolog doesn't seem (from my perspective)
to have any coherent way of storing data in memory. i.e. Data that should
be retained until the programmer explicitly tells it to go away.

I'm familiar with the "assert" line of predicates. I've also used a list
with a perpetually free tail variable. Both methods seem like hacks.
What is the correct Prolog way of doing this?

It seems like there should be a way to create a predicate, which takes
some data and another predicate as arguments; the second predicate would
determine whether the data store continues or terminates. This seems like
a more sane solution than leaving free variables floating around that
could hose the system.

Ah, but I'm still digging into Prolog. I'll post up some code IF I can get
it to work.

Any suggestions would be helpful.

Freejack

Nick Wedd

2005-08-04, 9:04 am

In message <pan.2005.07.28.17.37.43.172396@nowhere.net>, Freejack
<freejack@nowhere.net> writes
>Prolog and Oz are giving me a good workover in the area of Logic
>programming. I'm really starting to like both languages. However, one
>thing is kinda chaffing my ass. Prolog doesn't seem (from my perspective)
>to have any coherent way of storing data in memory. i.e. Data that should
>be retained until the programmer explicitly tells it to go away.
>
>I'm familiar with the "assert" line of predicates. I've also used a list
>with a perpetually free tail variable. Both methods seem like hacks.
>What is the correct Prolog way of doing this?

Either is a perfectly good way of storing data.

To me, it is the method used by C and many other languages that feels
like a hack. You write something like
rnum = 8;
and think your data is now stored; but some other piece of code has the
power to re-assign rnum to some other value, destroying your data. This
is (in my experience) the cause of many bugs, and it can't happen in
Prolog. That is one of the things that makes Prolog such an effective
prototyping language.

>It seems like there should be a way to create a predicate, which takes
>some data and another predicate as arguments; the second predicate would
>determine whether the data store continues or terminates. This seems like
>a more sane solution than leaving free variables floating around that
>could hose the system.
>
>Ah, but I'm still digging into Prolog. I'll post up some code IF I can get
>it to work.
>
>Any suggestions would be helpful.
>
>Freejack

Nick
--
Nick Wedd nick@maproom.co.uk

Matthew Huntbach

2005-08-04, 9:04 am

On Thu, 4 Aug 2005, Nick Wedd wrote:
> <freejack@nowhere.net> writes

[color=darkred]
> Either is a perfectly good way of storing data.
>
> To me, it is the method used by C and many other languages that feels
> like a hack. You write something like
> rnum = 8;
> and think your data is now stored; but some other piece of code has the
> power to re-assign rnum to some other value, destroying your data. This
> is (in my experience) the cause of many bugs, and it can't happen in
> Prolog. That is one of the things that makes Prolog such an effective
> prototyping language.

Of course it can happen. You write something like
assert(rnum(8))
and some other piece of code destroys your data by executing
retract(rnum(X)),assert(rnum(Y))

Chances are that if you are looking for a "coherent way of storing data in
memory" it means you are still thinking in imperative terms and have not
got used to thinking in declarative terms.

Matthew Huntbach

Freejack

2005-08-24, 9:56 pm

On Thu, 04 Aug 2005 13:33:51 +0100, Matthew Huntbach wrote:

> Of course it can happen. You write something like
> assert(rnum(8))
> and some other piece of code destroys your data by executing
> retract(rnum(X)),assert(rnum(Y))
>
> Chances are that if you are looking for a "coherent way of storing data in
> memory" it means you are still thinking in imperative terms and have not
> got used to thinking in declarative terms.
>
> Matthew Huntbach

So what is the coherent Declarative way of managing data?

I've considered hacking up a Prolog system to support variables(which are
immutable) and vectors(which are mutable). i.e. The idea being that upon
entering a computation the vector becomes immutable, read or write
only. Intermediate results are sent to another vector(write only) which
could be a stack, a queue, an array(aka APL style), an output port. i.e. a
vector could be mapped to any sort of underlying storage mechanism.
i.e. The Dataflow is immutable(unidirectional).

Variables could match to Vectors. This also allows the possibility of
mapping data processing tasks onto a "lower-level" processing engine. A J
or K interpreter, a Lisp system, or even an Assembler level function.
Vectors could become stand-alone predicates in this regard.

Ah well, my review of Curry should help clear things up a bit.

Laters.

Freejack

peter.ludemann@gmail.com

2005-08-25, 3:57 am

Freejack wrote:
[snip]
>
> So what is the coherent Declarative way of managing data?
>
> I've considered hacking up a Prolog system to support variables(which are
> immutable) and vectors(which are mutable). i.e. The idea being that upon
> entering a computation the vector becomes immutable, read or write
> only. ...

Before doing this, you might research what has been done in other
Prologs. For example, IBM Prolog had global terms plus arrays and
key-value pairs -- all of which were handled declaratively, in the
sense that changes to them were undone on backtracking. More details
here:
http://publibz.boulder.ibm.com/cgi-...helves/ELBSHX05
.... you probably want the programming guide and the language reference.

As I recall, Mantis Cheng's paper on tables as a user interface
discussed mutable/declarative arrays (a symposium at U of Waterloo
around 1988; but my memory is a bit fuzzy -- this is all I could find:
http://www.csc.uvic.ca/~mcheng/summary.html).

Part of my thesis was on declarative and efficient arrays, but it's not
available electronically.

And if you read Richard O'Keefe's book, you'll see other ways of
representing data that can be done with regular Prolog and are
asymptotically O(1).

Sponsored Links