Re: pining for the good old days of yore

Jan Wielemaker <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
On 03/31/2014 01:04 AM, Anne Ogborn wrote:
> I'm helpign a new prolog programmer on IRC, who'se asking how to persist data they're adding
> with assert at the top level. (and yes, I understand this is the road to perdition, and am
> gently encouraging them away from it).
> 
> I have to admire his/her ingenuity. They're appending data, with the old Edinborough append/1,
> to their prolog source file.

That may be not too bad :-)

> They're reasonably asking if this has to be this hard. 
> 
> While the answer of course is 'yes, you're trying to use the system backwards.', there's a part of me that wishes at this moment that save_state still worked.
> 
> I wish it worked every so often.

I'm not so sure.  Typically, you'd like your program to evolve a bit
more independently
from your data and you want only some of your data to be persistent.
Classical
saved states also provide no safety against failure of Prolog or the
computer it
runs on.  Even if you wanted it, it is more or less not doable on modern
systems ...
That indeed, is a pity :-(

> Persistence is something that should be handled by little gnomes behind the scenes, as so much else is in the Prolog world.
> 
> I find myself in this same situation sometimes - wondering why I can't just hint the system how to persist the data, and have it do it. Isn't there a pretty, happy making solution for this?

See http://www.swi-prolog.org/FAQ/PrologLAMP.txt, "Replacing MySQL".
There was some
companying discussion on this list, notably pointing at some scalable
nosql databases
as alternative.

> And yes, I'm opening a can of worms here.

Don't think so :-)

	Cheers --- Jan

> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.