After discussions with @dexter2206 at the onsite in June 2025, it was suggested that maybe we should begin to separate the parts of Bartiq that are the compilation engine, and the parts of Bartiq that a user will want to use/abuse.
With a CompiledRoutine object, a user will want to do multiple things with it (evaluate, traverse the DAG, determine which resources have unknown functions in them, etc). We can (and have begun to) add helper functions to the Routine and CompiledRoutine objects to help in this aspect. Maybe the simplest example of this is the new resource_values attribute, which we implemented because we found that users would use it more.
As another example, consider the find_descendants feature introduced during Unitary Hack (link). This functionality was introduced to address a specific problem, namely that it is difficult to find where a subroutine is even if you know its name. As it stands, this functionality could be improved because, e.g., you don't always know the exact name of a subroutine, just a rough guess. This function also only returns (a list of) a list of children: [child_a, child_b, child_c] which means to retrieve the subroutine you want, you need to call:
possible_pathways: list[list[str]] = routine.find_descendants(name=subroutine_i_want)
possible_routines = []
for child_path in possible_pathways:
routine_i_want = routine
for child in child_path:
routine_i_want = routine_i_want.children[child]
possible_routines.append(routine_i_want)
So: if there are multiple children with the same name, find_descendants returns all pathways to those children. To get the actual child routine, you need to traverse the DAG manually with .children, either in a for loop like above or chained together: .children[...].children[...].children[...].
We could then feasibly introduce functionality to streamline this for the user.
I would also lump in this issue to be a similar vein.
So we have two tracks: the under-the-hood behaviour of Bartiq as a compilation engine, and how users actually want to interact with Routines/CompiledRoutines.
One proposal is to implement something like a RoutineHandler that allows BaseRoutine objects to be interacted with in a more interactive way, but I'm curious to hear peoples thoughts on this.
After discussions with @dexter2206 at the onsite in June 2025, it was suggested that maybe we should begin to separate the parts of Bartiq that are the compilation engine, and the parts of Bartiq that a user will want to use/abuse.
With a
CompiledRoutineobject, a user will want to do multiple things with it (evaluate, traverse the DAG, determine which resources have unknown functions in them, etc). We can (and have begun to) add helper functions to theRoutineandCompiledRoutineobjects to help in this aspect. Maybe the simplest example of this is the newresource_valuesattribute, which we implemented because we found that users would use it more.As another example, consider the
find_descendantsfeature introduced during Unitary Hack (link). This functionality was introduced to address a specific problem, namely that it is difficult to find where a subroutine is even if you know its name. As it stands, this functionality could be improved because, e.g., you don't always know the exact name of a subroutine, just a rough guess. This function also only returns (a list of) a list of children:[child_a, child_b, child_c]which means to retrieve the subroutine you want, you need to call:So: if there are multiple children with the same name,
find_descendantsreturns all pathways to those children. To get the actual child routine, you need to traverse the DAG manually with.children, either in aforloop like above or chained together:.children[...].children[...].children[...].We could then feasibly introduce functionality to streamline this for the user.
I would also lump in this issue to be a similar vein.
So we have two tracks: the under-the-hood behaviour of Bartiq as a compilation engine, and how users actually want to interact with
Routines/CompiledRoutines.One proposal is to implement something like a
RoutineHandlerthat allowsBaseRoutineobjects to be interacted with in a more interactive way, but I'm curious to hear peoples thoughts on this.