index on repr

[majidaldo]

When the structures get really nested, it would be nice to have an index printed out in the structure.

[brandonwillard]

Can you provide an example/illustration?

[majidaldo]

Like pipeliney process structure: begin with something and put it through operations.

from etuples import etuple as et
def add1(x): return x+1
e = et(add1, 1)
e = et(add1, e) # say i want to index into this etuple
e = et(add1, e) 
#...
e = et(add1, e)
e

shows up as

e(
  <function __main__.add1(x)>,
  e(
    <function __main__.add1(x)>,
   # v-- what's the index into this one?
    e(<function __main__.add1(x)>, e(<function __main__.add1(x)>, 1))))

i have some great use cases for being able to easily get to a node.

[brandonwillard]

Yes, easy access to a particular node like that would be nice.

The easiest approach might involve unique labels. A debug print-out could apply a very deterministic unique labeling, so one would determine which label they wanted to select by viewing that print-out, and then a follow-up "get"-like method could be given said label and return the associated node.

In this case, the index you're requesting is the label and we would need to implement two things: general etuple graph printing, unique (and convenient) labeling for that, and a query function.

Aside from that, I've seen symbolic libraries offer query languages (e.g. JSON-like and/or REGEX-based) for more general cases of this sort of thing, but that's ultimately what unification and/or kanren does. Since we wouldn't want to reinvent those wheels, if such a query languages was necessary, it would have to serve as a more palatable front-end for unification/kanren.

[majidaldo]

Yes, easy access to a particular node like that would be nice.

The easiest approach might involve unique labels. A debug print-out could apply a very deterministic unique labeling, so one would determine which label they wanted to select by viewing that print-out, and then a follow-up "get"-like method could be given said label and return the associated node.

idk maybe make use of what dask does here.

[majidaldo]

Aside from that, I've seen symbolic libraries offer query languages (e.g. JSON-like and/or REGEX-based) for more general cases of this sort of thing, but that's ultimately what unification and/or kanren does. Since we wouldn't want to reinvent those wheels, if such a query languages was necessary, it would have to serve as a more palatable front-end for unification/kanren.

My thought here is to keep this as a separate layer; Essentially, kanren provides a graph onto which you can use whatever query language you'd like.

i've actually experimented with making kanren more palatable by using dataclasses where mappings b/w classes are arbitrary python code instead of relations. i found that describing everything as a relation makes it difficult to use. (there needs to be a path from 'normal' programming to having it be a strict relational program.)

[brandonwillard]

idk maybe make use of what dask does here.

Which part of what Dask does?

I don't remember whether or not Dask assigns unique IDs/labels when nodes are created, but that's a possibility—depending on how well this library sticks to immutability. Even so, I don't know if this would make sense for a repr, but such an ID could be part of a str representation.

[majidaldo]

idk maybe make use of what dask does here.

Which part of what Dask does?

I don't remember whether or not Dask assigns unique IDs/labels when nodes are created, but that's a possibility—depending on how well this library sticks to immutability. Even so, I don't know if this would make sense for a repr, but such an ID could be part of a str representation.

I think every execution aspect of of etuples can be subsumbed by dask https://docs.dask.org/en/latest/graphs.html. Immutability/pure-funcs as well as naming nodes (dask_key_name) are figured out.

Considering that, etuples value would be to provide a programming model different from dask.delayed (focusing on expressions).

[brandonwillard]

I think every execution aspect of of etuples can be subsumbed by dask https://docs.dask.org/en/latest/graphs.html. Immutability/pure-funcs as well as naming nodes (dask_key_name) are figured out.

Considering that, etuples value would be to provide a programming model different from dask.delayed (focusing on expressions).

A comparison with Dask's graphs isn't particularly useful. The way in which they both share the same concerns, features, etc., is far too simple (e.g. using tuples or dicts to represent a graph), and the rest is extremely dependent on unshared contexts and goals—design and otherwise.

There's also nothing that really needs to be figured out, aside from feature-based choices.