Getting references to already-built robots

[byorgey]

This is a problem that has been talked about in various places. This is intended to be a sort of omnibus issue bringing together all the previous discussions and also offering a concrete proposal.

The problem

There are lots of robots in the world, and sometimes you need to refer to them (in order to tell them to halt, to communicate with them, to give them something, to program another robot to give them something, to view them...). The status quo is "if you ever want to refer to a robot in the future, or even think you might, you must bind it to a variable at the REPL; otherwise you're out of luck". This is, of course, ridiculously limiting and annoying, for many reasons:

• You might forget to bind a robot to a name (I have done this many times)
• You might not realize that you will want to refer to a particular robot in the future
• You might want to call a function which builds multiple robots, or build a robot that builds other robots. In both these cases, it is not even possible to bind the resulting robots to variables in the REPL.
• Even if you create robots one by one, and remember to bind them to variables, it is annoying to have to remember the right variable names for all the robots. It would be much nicer to be able to just create them and then select the one you want to refer to later without having to remember the exact variable name you happened to assign it in the past.

We need a more general solution for referring to robots after the fact.

Related discussions/partial solutions

• Ability to access past REPL results #304
  • This would help in the case that you execute build, and you wanted/intended to bind the result to a variable, but forgot. However, it doesn't really solve the problem (though it's a nice idea on its own merits and we should definitely implement it).
• Ability to scroll the REPL panel #60
  • REPL results are now bound to variables like itN, but without being able to scroll the REPL panel you can only see the past few results.
• Commands to meet other robots #306
• "Robot registry" allowing access to built/known robots by index #462
  • This would help you refer to robots that you create at the REPL, whether or not you bind them to a variable. However, it doesn't really solve the problem either. For example, what if you call a function that builds multiple robots? What if you build a robot that builds other robots? In these cases you would never see the robot value printed at the REPL, so you would not know how to refer to them. I actually now think we should not implement a robot registry as described in "Robot registry" allowing access to built/known robots by index #462 , but something more general instead (see below).
• Robot to name or id and back #343
  • My proposal in this issue would (I think) also solve this. In the discussion I was worried about functions that would let you manufacture robot references out of thin air, but I think there is a way we can have these functions without being able to manufacture robot references you shouldn't; see below.
  • Add robotNumbered command for debugging #405
  • Find robots #339

What robots do you "know about"?

I think in the past I had some kind of idea that you would be limited in the amount of information you would be able to get about other robots unless you had taken specific steps to remember them or be able to communicate with them. However, I'm coming to realize how utterly frustrating that can be, and in any case it doesn't seem to be the direction the game has been moving in. Of course, you can literally see all the robots in a top-down view; and now that we have the robots list view (F2), it is apparently possible for the base to receive signals from nearby robots with various basic status information. I love the robot list view and do not want it to go away, so we just have to figure out a consistent story to tell about it.

My current idea is to say that every robot chassis has a basic antenna built in (see #17), which it can use to communicate status information up to some radius (robot list view is 32). You should "know about", and thus be able to get status information updates from, and be able to get a reference to, any robots you built (transitively). Of course this does not include system robots or (in a multiplayer scenario) another player's robots.

What if you build two robots, call them A and B. Should robot A "know about" robot B, and vice versa? Well, sure, why not --- presumably they could send a request for information to the base. It's supposed to be a swarm of robots that all work together, right? 😄

System robots, of course, should "know about" all robots. Eventually, when we start adding other robots for you to interact with (representing e.g. animals, aliens, etc.) we might need more categories than just system/non-system robot, but we can deal with that when we come to it.

A general method for getting robot references

Since the robot list view implies that we can apparently find out lots of details about other robots through some basic communication, why not be able to use any of those details to select robots we want to reference?

Specifically, I propose adding a command something like robotWhich : (robot -> bool) -> robot.

• It returns any robot you know about that satisfies the predicate, or throws an exception if there are none.
  • I used to be worried about things like robotNamed, robotNumbered, etc. since it seemed like they would give you a god-like ability to get a reference to any robot. (See the discussion on Robot to name or id and back #343.) But of course they don't have to work that way. I think the idea of having them be partial functions, throwing an exception in the case of a "permissions error", solves this problem in a simple way.
• We will probably want to add more predicates/getters on robots to go along with this.
  • e.g. robotID : robot -> int, hasID : int -> robot -> bool, robotName : robot -> string, hasName : string -> robot -> bool, etc.
    • The reason we might want to explicitly provide hasXX versions is so that you don't need to use a comparator to implement them yourself in terms of the getters.
• Things like robotNamed : string -> cmd robot and robotNumbered : int -> cmd robot no longer need to be restricted to god capability, and in fact we could get rid of them altogether as primitives since they can just be implemented in terms of robotWhich.
• We could still have a robot index device, or something of the sort (see "Robot registry" allowing access to built/known robots by index #462) provide the robotWhich command, but this should be a default device / we should have a bunch of these devices to start (Starting base with a large but finite supply of basic robot parts #35).
• Any time a REPL command results in a value of type robot, we can print it as e.g. robotWhich (hasID 45) : robot. Or if that's too verbose we can provide robot : int -> robot = \i. robotWhich (hasID i) as a primitive and print robot 45 : robot.

We might also consider adding something like robotsWhich : (robot -> bool) -> (robot -> b -> b) -> b -> b which lets you fold over all robots you know about that satisfy a predicate.

Related issues

Entities have a similar problem; see #455 for a discussion and links to related issues. Hopefully we may be able to use similar techniques there as well.

[xsebek]

Thanks for writing all this @byorgey 👍

I will have to think about this a bit, but the issue that strikes me with robot numbers is that they allow instantaneous communication.
I would prefer not to leak world state by telling every robot capable of building the current number of robots.

As a side note, I like how the proposed functions are pure, so why the cmd in robotsWitch?

[byorgey]

Ah, very good point re: allowing instantaneous communication via robot numbers. Maybe we could use the child and friend things from #462 after all, but combine it with robotWhich somehow? Or maybe we could just randomize robot numbers so they don't convey any information? I was going to say that makes them more annoying to type... but actually after harvesting things for a while I very easily get into 4- and 5-digit robot numbers anyway. =)

As a side note, I like how the proposed functions are pure, so why the cmd in robotsWitch?

Just an oversight. I think I had cmd in some places before but then decided that everything could be pure, but forgot to remove it from robotsWhich. I took it out.

[byorgey]

So concretely, here's what I propose:

• Start randomizing robot IDs.
  • Print them out in hexadecimal to make things a bit nicer.
  • In practice, generate random 16-bit IDs until there are enough that we need to start generating larger ones. (Yes, that does give out a tiny bit of info about the number of robots but I don't think it's a huge deal. It would be too annoying to have all robot IDs be 32 or 64 bits long, but 16 bits might conceivably not be enough.)
  • We can keep an IntSet with the used robot IDs, and just generate random IDs until finding one not already in the IntSet. As long as the IntSet doesn't get too full this should be fast. (For example, we probably want to stop generating only 16-bit IDs once about half of the 16-bit IDs are used.)
• Add robotID : robot -> int and robotName : robot -> text (and possibly others).
• Optionally, also add hasID : int -> robot -> bool and hasName : text -> robot -> bool? I am still not sure about these. Currently, I am leaning towards not adding them. Making a comparator is not that hard.
• Add robotWhich : (robot -> bool) -> robot and robotsWhich : (robot -> bool) -> (robot -> b -> b) -> b -> b.
  • For now, system robots (or robots in creative mode) are allowed to know about any robot; otherwise a robot is allowed to know about any non-system robots. (Once we add other meet-able things we will have to be more careful about this.)
  • robotWhich throws an exception if no robots meet the criterion. robotsWhich never throws an exception.

Edited to add: Well, once again I forgot about comments like #462 (comment) . I still think my above concrete suggestion is simple and will improve things, but I agree perhaps it is too god-like to know about all the robots ever built by anything that built you and so on. Maybe we should continue thinking about this. Or another approach might be to implement the above simple system but then refine it later with a more restricted "knowledge graph".

[xsebek]

@byorgey that sounds like an easy enough objective improvement. 👍

One slight wrinkle is that we do not currently have any pure functions to serve as predicates on robots, only As.
But that can easily be changed. EDIT: ...like the robotID and robotName that you mention but I was not careful enough to read. 😅

Also, it would be great to have the robot IDs in the F2 panel so that I can view them more easily. 👀

[byorgey]

Also, it would be great to have the robot IDs in the F2 panel so that I can view them more easily.

Agreed!

[byorgey]

One potential issue is efficiency --- something specific like robotNamed could potentially use a map from names to robots to look up a robot with a given name very quickly, whereas robotWhich takes an arbitrary predicate, and hence seemingly must iterate over all robots. I suppose it is possible to imagine some kind of under-the-hood optimization/specialization, where things like robotWhich (hasID n) would actually compile down to a lookup in the robot map rather than generically iterating over all robots looking for one which satisfies the predicate.