Be more lenient in accepting known arguments to `require`

[kostmo]

Describe the bug

I am not able to compile the following:

build {
    let quantity = 500 in
    require quantity "rock";
}

The error message is:

expecting device name in double quotes or integer literal

The workaround to ensure that "child" robots receive a programmatic quantity from inventory seems to be for the "parent" to give items repeatedly while the child polls using count.

[byorgey]

This is not a bug, and has been discussed in some detail in #738 . The basic explanation is that the arguments to require need to be statically known since requirements checking happens prior to running a program. That is, we have to be able to figure out what a newly built robot will need before we run its program.

Potentially, I could imagine doing something like this:

let quantity = 500 in
build { require quantity "rock"; ... }

That is, as long as quantity is already known at the time we execute the build we might be able to make it work. But I expect it would be complicated.

The workaround to ensure that "child" robots receive a programmatic quantity from inventory seems to be for the "parent" to give items repeatedly while the child polls using count.

Yes, that is annoying. Once we have #115 this will probably become easier since you can e.g. stuff a bunch of rocks in a box and then just give the box.

[kostmo]

At least for the application I had in mind, the quantity can be known outside of the build context, i.e.

let quantity = 500 in
build { require quantity "rock"; ... }

However, it's merely an issue of convenience now, as I've successfully employed the polling workaround.

[xsebek]

@byorgey do we have a way to get something like Ctx Term to see what the current variable name points to?

AFAIK we only have Env = Ctx Value that will be used at runtime.

I guess requirements would have to create the map itself. 🤔

[byorgey]

do we have a way to get something like Ctx Term to see what the current variable name points to?

No, that would be something extra we'd have to keep track of while doing typechecking & requirements analysis.

[byorgey]

I'm going to close this soon, since there's no general solution and anything we did to make it slightly better would be an ugly hack. However, I wanted to summarize the current state of things and maybe spark some discussion of other ways to improve the situation.

• The only thing that is allowed is something like require 500 "rock", where the number and the entity name are literals. This is because require is analyzed at compile time and we cannot wait until runtime to find out what the number and entity are.
  • It is potentially confusing that require looks like a regular command, but it is actually special syntax for declaring a requirement, not a command that does something.
  • Perhaps we should consider changing the syntax of require to make this more clear, e.g. change it to #require.
• It is conceivable that we could allow something like let n = 500 in require n "rock", but only with some hacky effort, and is this really better than just writing require 500 "rock"? I suppose if you wanted to write a lot of require statements with the same number, it would make the program more readable.
• The thing we definitely can't do is anything like n <- foo; build {require n "rock"; ...} where the number is determined at runtime.
  • The current workaround is to program the robot to wait until it has enough rocks, and then give the rocks to it after it has been built.
  • We could also imagine adding some primitive sort of way to do large inventory transfers when building. e.g. maybe a command get : Int -> Text -> Cmd Unit which tries to grab a certain number of a given entity from your parent robot. So you could write n <- foo; build {get n "rock"; ...}. The difference is that whereas require is analyzed at compile time, and the build will not succeed at all if the requirements cannot be met, get is executed at runtime and can throw an exception if there is not enough of the requested entity.