LogtalkDotOrg/logtalk3

General discussion on Logtalk

Paul Brown

@PaulBrownMagic

You can extend parametric objects, but they're identified by their functor so you can't have 2 objects with the same functor but different args.

This message was deleted

Paulo Moura

@pmoura

That said, defining parametric object proxies (i.e. plain Prolog facts or rules whose functor unifiers with the parametric object identifiers) provide a solution there.

grossd

@grossd

just noticed that assert/2 doesn't seem to be recognized -- the one that returns the asserted clause reference ...

is this so or am I missing something

! Domain error: value asserta(:,-) is not in domain meta_predicate_template

Paulo Moura

@pmoura

Hi. The database predicates that take (or return) a clause reference are not (currently) supported.

Paulo Moura

@pmoura

Note that those predicates are not standard. They are found in SWI-Prolog and YAP.

Are they critical for your work with Logtalk?

grossd

@grossd

that's how I implemented a light weight transaction -- I am tracking asserted facts by recording the clause id, which can be retracted upon rollback

without it, I would need to track the whole asserted facts in a structure -- I guess I could do that too, its just less efficient

grossd

@grossd

I now use object parameters to thread a list of facts asserted -- which can be used during rollback to retract facts. Not sure if this is a good way to use parameters -- I could instead move the parameters to "new" methods.

is there a reason why one is better than the other

grossd

@grossd

is it possible to retrieve the name of the caller object in a method within the called object?

Paulo Moura

@pmoura

Correctly handling inheritance makes implementing the database predicates non-trivial and cumbersome. Asserting or retracting a clause may or may not override the modified predicate for a descendant entity.

The object parameters are logical variables shared for all object predicates. Thus, using parameters is a good choice when you want logical variable semantics and when most object predicastes require access to all or some of the parameters.

See the documentation of the sender/1 built-in method: https://logtalk.org/manuals/refman/methods/sender_1.html

grossd

@grossd

Thanks.

I guess "when most object predicastes require access to all or some of the parameters" is the key phrase -- to decide whether to use object paramters or method parameters.

grossd

@grossd

"Correctly handling inheritance …" I wasn't precise enough -- I am asserting facts not clauses.

I mean -- predicates …

objects hold all predicates / methods, whereas the fact base gets populated and reasoned about

Paulo Moura

@pmoura

Facts are clauses. Thus, asserting and retracting facts must also take inheritance into account.

Where does your fact base live?

grossd

@grossd

currently in the prolog fact base -- asserted via assertz

if I need to, I might start using the rdf11 module

Paulo Moura

@pmoura

Then using asserta/2, ... is not a problem.

grossd

@grossd

i am waiting to identify a strong requirement for going to rdf

since it seems more heavy weight than the simple prolog base, but, then has further services

Paulo Moura

@pmoura

E.g. you can simply wrap the calls to the database predicates that a clause reference argument using the compiler bypass control construct, {}/1. That would avoid the domain error you mentioned earlier.

grossd

@grossd

that might come in handly

you mean if i do want to use the assert/2

to wrap it

Paulo Moura

@pmoura

Yes. But don't use assert/1-2. Always use either asserta/1-2 or assertz/1-2.

To be clear, wrap the calls only when modifying the plain Prolog (aka user) database. And this is only necessary for the predicates that take a clasue reference argument.

grossd

@grossd

ok. for now i decided to use assertz/1 and pass a list of asserted facts via object parameterization -- i think this is fine since typically transactions only cover a small number of "atomic" facts

so whether its a reference or a binding to the a fact shouldn't make a difference

Paulo Moura

@pmoura

What do you do with that list of facts inside an object?

grossd

@grossd

there would be a rollback method -- which would receive that list via the object parameter as well -- and then retract all facts in the list

thereby undoing the transaction

Paulo Moura

@pmoura

I assume is not possible to simply rely on backtracking for the roolback?

But anyway, given your description, passing instead a list of references would be best as it would consume less stack memory.

grossd

@grossd

In theory i could have a whole graph linked to a logical variable -- and then backtracking would do it -- however, for large graphs i believe that i would run into slow downs due to GC

and, i haven't yet thought about persistence

but i imagine loading a graph into a dynamic structure would take longer than loading it into the prolog KB

and eventually, if i do move to RDF then assert would need to be the way to go -- although, then i could use transactions implemented in the RDF library

Paulo Moura

@pmoura

I have to go now. From what you describe, using assertz/2 and friends and passing a list of clause references via object parameters sounds like a good solution.

grossd

@grossd

ok -- thanks

it also looks nice when i run it :-)

Where communities thrive

People

Repo info

Activity