Getting rid of UUIDs in the Haskell LIb

[Roman Treutlein]

Hello,

I was just trying to get the Haskell Lib to use Handle/AtomPtr instead of UUIDs. Unfortunately, I was unsuccessful thus far. The issue being that I can't use Handle/AtomPtr directly as they are Objects which aren't directly supported by the C-Interface.

I could use a Pointer to the Atom but that is unsafe on multiple levels.

Looking at the Scheme code it also seems to use UUIDs but I am not quite sure to what extend.

Anyway, I just wanted to know if somebody had some thoughts about this.

regards

/Roman

[Ben Goertzel]

LInas will have thoughts but he's flying home to Austin from NYC
tonight so he may only share them US tomorrow...

> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/d80fa1af-b3cf-47b4-908a-8c42061519db%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Ben Goertzel, PhD
http://goertzel.org

Super-benevolent super-intelligence is the thought the Global Brain is
currently struggling to form...

[Linas Vepstas]

I'm not sure what to suggest, because I don't know what the issue is. You cannot get the name of an atom, without first obtaining a pointer to it, so, whatever your API is, it does have to have pointers in it, somehow.

If you want to always use ints, you could keep a private table that translates from ints to atoms and back.

My long-term goal is to create such a "private table" in the database backends, and remove UUID's in general.  The rest API would need to do something similar, too.  The advantages are that  it should make the management of atoms easier. But this remains fairly low-priority, for now.

--linas

[Matt Chapman]

On Fri, Jul 22, 2016 at 2:55 PM, Linas Vepstas <linasv...@gmail.com> wrote:

My long-term goal is to create such a "private table" in the database backends, and remove UUID's in general.

Aren't UUID's (or something equivalent) necessary for a distributed atomspace? I suspect you don't want to have to worry about synchronizing this int table across machines...

All the Best,

Matt

--

Standard Disclaimer:
Please interpret brevity as me valuing your time, and not as any negative intention.

[Ben Goertzel]

But it's not clear that an Atom created on one local machine, then
processed a bit, then discarded, ever needs to get assigned a UUID.
They could get assigned only when saving to a backing store or sending
across a network, right?

-- ben

> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CAPE4pjBYmMTnSg_GjbdGVf2E94ytenar%3DFEDa5b66gDKzTLfUA%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Linas Vepstas]

On Fri, Jul 22, 2016 at 5:45 PM, Ben Goertzel <b...@goertzel.org> wrote:

But it's not clear that an Atom created on one local machine, then
processed a bit, then discarded, ever needs to get assigned a UUID.
They could get assigned only when saving to a backing store or sending
across a network, right?

Yes, exactly. On a local machine, UUID's are never needed; removing them is a performance optimization.  For storage or network communications -- its up to the layer that implements the storage or communications: if it wants to use UUID's as some kind of short-cut, it can, or it can use something else.

--linas

 

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBf_E%3Dp%3DJUCO%2B-RDa26vzbqX3vrm4J1am%2BB6zyN6WeD_4Q%40mail.gmail.com.