scanner device and scan command

[byorgey]

As discussed in #49 , we should add some sort of scanner device that robots can use to find out about items in the world, with a way for them to report their findings back to the base.

There are definitely some details to work out; here are some of my current thoughts:

• Since this is an extremely basic action which is one of the very first things you will need to do, scanner devices should be installed on robots by default (or, if we implement Starting base with a large but finite supply of basic robot parts #35 , the base should start out with a supply of them).
• It would be very annoying if the scan command returns a value which you have to specifically transmit to the base (as in `info <- scan forward; upload "base" info) because that would allow you to scan only one thing at a time before returning to the base: robots can't use complex data structures like lists at the start of the game, so threre would be no way to store multiple scanned info values. However, it would be nice if robots can just wander around scanning things before returning to the base later.
• Therefore, for the type of scan I propose scan : dir -> cmd () which scans in a particular direction and adds information about the scanned entity to the robot's inventory (with a count of zero). (It might be nice if scan also returned the name of the scanned thing, as in scan : dir -> cmd string, but then we have to worry about what it should return if there is nothing to scan.)
• There should also be a command upload : string -> cmd () which uploads some scan results info another robot. This would just transfer knowledge of all things in the robot's inventory to the target robot (without actually giveing any of them). Newly acquired knowledge would show up as entries in the inventory with a count of 0.

As discussed in #49, we might also consider drawing entities using question marks until the base knows about them.

[byorgey]

The scanner device should also convey the capability to execute the command blocked : cmd bool, which checks if there is an unwalkable entity in the forward direction. i.e. it basically lets a robot ask "if I were to execute move, would it throw an exception?" This is crucial for being able to write robot programs with a bit more freedom of movement. For example, given recursion, conditionals, and the blocked command, it's possible to write a DFS to e.g. harvest an entire forest at once, gracefully handling any boulders, mountains, etc. that are in the way. (Without blocked, you're probably going to hit a boulder and crash the robot.)

At the moment, blocked is enabled by a rangefinder which has a recipe of 1 log, but that was really only there as a placeholder so that I could try implementing a DFS. A laser rangefinder sounds like a cool device also, but I think it should be harder to construct and tell you the distance to the nearest obstacle in a given direction, e.g. something like distance : dir -> cmd int.

[polux]

Can't that be implemented by a try {move; turn back; move; turn back; return true} { return false }?

[byorgey]

Sure, it can, but (1) that takes four ticks, and (2) the try command won't be available early in the game.

[xsebek]

@byorgey Ad (2) is this still the intention? I see base and robots can use it now and no Issue or PR mentions try.

> build "robot try" {x <- try {grab} (return "nothing to grab"); say x; selfdestruct}
"robot try" : string

robot try: nothing to grab

If you think it should be restricted by some capability, then maybe another Issue should be split from this one. 🙂

(Honestly I just found out it's available from the start via Wiki cheat sheet. 😅 )

[byorgey]

@xsebek Yes, (2) is still the intention, but you're right that there is no restriction on it yet. I just created #132 to track this. (It's not the only thing that is availble but shouldn't be, check out the source of the Capability module for some more examples...)