Re: [CZT-Devel] Reducing memory usage: Signatures are the biggest culprit?

[Leo F. <leo...@ne...>]

Hi Tim,

Andrius and I have been discussing possible solutions yesterday for memory improvements.
It revolves around rearranging how the checkForDuplicates method, called at key points for
ID merging in the schema calculus (and a few other places), rely on signatures being copied.

If copying is to be relaxed (i.e. the culprit for 60% memory shoot up), adjustments elsewhere
are needed to ensure the semantics intended by the IDs is preserved.

Incidentally, the del taxi id was something I added to ensure the intended postcondition for
the ID database was kept (i.e. all ZNames associated with the same id in the ID database have
the same "word" naming). Without setDeltaXi, the DeltaXI case would break the invariant, so
it's just a "marker" really to declare that isn't a name where IDs matters much in so far as the
invariant is concerned. See

net.sourceforge.czt.typecheck.z.util.AbstractTypeEnv.getDeltaXiType(ZName zName, Type type) [l163]
net.sourceforge.czt.typecheck.z.impl.Factory.checkNameIDDBInvariant(ZName zName, List<ZName> list) [l558]

Our worry for a solution that change the semantics of IDs is that we don't understand it well
enough to ensure all cases will be catered for. This will require some time….

Best,
Leo

On 16 Apr 2013, at 01:55, Tim Miller <tm...@un...<mailto:tm...@un...>>
 wrote:

Hi Anthony,

You wrote:
Can I ask a question about ids? I had understood that the id was necessary
for distinguishing truly different instances of a name - for example x
declared globally and x within a schema.

Yep, that's correct.

If that's true we can't presumably
drop ids altogether? Certainly I use them in my cross reference (as you may
remember, we had extensive discussions about this) and I've just been
looking at the "Go To Declaration" tool in the Eclipse IDE, which I think
uses the word + id as the unique identifier of a name.

So I wonder whether we do need to keep the id, but not to create a new id
for every schema inclusion? If I declare x in S and then include S in T, I
don't think we should need a new id for the x in T, for example.

It creates a new ID because it is a new variable. I did it like this
because it is consistent with the semantics of Z. If x is declared in S
and then S included in T, the variable x is indeed a new variable,
because the semantics are that the definition of T is identical to the
case that the declarations and predicate from S are "cut and paste" into
T. So, the following:

S == [x : X];
T == [S; y : Y]

is semantically equivalent to:

S == [x : X];
T == [x : X; y : Y]

If we were to not declare a new ID for the x in the first example, then
the two declarations of x the first example would have the same ID,
while in the second, they would be different. I'm not comfortable with
that inconsistency.

I'm not arguing that this is really important (I can't see that any of
our tools would care), but this is the motivation. I would prefer to
preserve the semantics as is currently, and just have a mode where the
IDs are not renamed. In fact, this second mode would be nice for tracing
variable declarations in Z state machines, as we can link included state
variables back to their definition in a state schema quite easily. To do
this now, we would have to pass the definitions in more detail.

Also, there the special id deltaxi, which presumably needs to be kept or
replaced with a different mechanism?

The id deltaxi was added by someone other than me (Leo I guess?) and I
don't know what the motivation for that was, instead of e.g. just
allocating a fresh ID.

At the moment it also seems to be true that there are many instances of a
ZName with the same id - that too could presumably be avoided?

I can't comment on that without looking further. I would assume that you
are right because I appear to have created a method in the typechecker
factory for copying names. One shortcut would be to just return the same
instance for that method, but I'm not really sure. I can certainly look
into this further once we have a consensus on how we should handle this.

Cheers,
Tim

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
CZT-Devel mailing list
CZT...@li...
https://lists.sourceforge.net/lists/listinfo/czt-devel