Different behaviors between web and desktop about anonymous commands/reporters

[CIVITAS-John]

Again, this is a forwarded issue from https://gitee.com/turtle-sim/turtle-universe-issue-tracker/issues/I58JQV by Maizi.

Here is a summary.

• Issue 1 is more like a weird grammatical feature. For example, if you define the following: to-report rs[i] run i end Then run: rs[-> let n 3 report n /(n - 1)] You will get a result of 1.5, which does not make sense - but it somehow works. And I wouldn't recommend scrapping this since we don't know how many other people are using it.

• Issue 2 behaves differently between NetLogo desktop and web. While foreach [1 3] [b -> b + 1] would fail to compile in both platforms; let a [b -> b + 1] foreach [1 3] a would succeed in web but not desktop (!).

Moreover, it seems that [n -> set n n + 1 report n] would be considered an anonymous command on both platforms. Since NLW did not conduct the runtime check, it works there but not on desktop.

[TheBizzle]

Issue 1: Note that report has different behavior within anonymous procedures. report is never valid within an anonymous reporter. However, within an anonymous command, it can be valid, as a way of forcing the parent procedure (which will hopefully be a reporter) to return early, kind of like the if branch in this C code (if you were to think of the body of the branch as a zero-argument function):

int myFunction(bool cond) {
    if (!cond) {
        return 1;
    }
    return 0;
}

It's not something that I expect people to use much. And I would rather they didn't use it at all. I wouldn't have a problem with disabling report within anonymous commands, but it's not clear to me that this functionality is causing any harm, as it is.

Issue 2: This is another duplicate of #184. There are many, many ways of duplicating #184 in NetLogo Web, by following this format:

• Store an incorrectly-typed value into a variable
• Pass that variable as an argument to a primitive
• Expect a runtime error, but fail to get one

[LaCuneta]

I added some tests for the failure scenario here, so we won't forget to get this included in the future error checking work.

I concur with Jason that I wouldn't want anyone to use the report inside of anonymous commands feature really at all. There is always another, probably less "magical" way to get that type of functionality (in my opinion).

I'm closing this for now, but if you have any other questions or comments feel free to leave them here.