Weird list

I just tried a custom block and it is supposed to report a list containing

  • if the command failed.
  • the error (only appears if the handler was run).
  • data that the command or handler reported.

This is the definition:


Apparently, works fine:

until .

And that's not all:

,
, and it continues.

What I could see is that sometimes when I use a reporter or predicate with that list, such as untitled script pic (8), it reports the same list! My mind's going to explode rn.


Think it's a JS bug, but I'm not sure. Hope this gets fixed bc I'm making a category for the Better saga.

I'm having a little trouble reading your mind (an important skill for teachers), but your use of JOIN is incoherent, so I think you're confused about how the CALL surrounding it works.

Okay, here's my guess: You meant to say


but COMMAND doesn't take any inputs, so even that wouldn't mean anything.

No matter what you try to wrap around it, COMMAND is a command; it doesn't report a value, and so you can't use that nonexistent value in a larger expression.

So, your basic idea of


is good, but you can't run COMMAND inside the REPORT. You have to run the command, and if you actually reach the REPORT, then the command worked:

Alas, even this isn't quite good enough. Read the definition in the library:


You're not doing that ERR_RESET. I don't know what that does, exactly, not having read the relevant code in the Snap! source files, but it wouldn't be there if it weren't important! So you have to do this:

Okay, you take it from there!

Nope, error upvar is set to "error" when the command is run. I want to set it to "" so that's why I use
. So, for example, I want to convert
to , to finally call it as .

And what if the command reports something? I'm going to lose that value.

I tried doing err_reset but doesn't work either.


As can you see, the real problem is the list. I need another solution.


Thank you for the advice though :slight_smile:

By definition the command doesn't return anything! That's what makes it a command.

There is a separate block
untitled script pic
(note its round shape) for calling reporters and catching errors.

The real problem is that you're putting a command block in a CALL. That's known to give strange results. If it's a command block, you have to RUN it. If you want to CALL it, it has to be a reporter (or a script with a REPORT block).

P.S. Would Snap! be a better language if it only had reporters, like Scheme? Maybe it would, maybe it wouldn't. But it is what it is.

So, what is this block??: . You can put it in commands.

I've tried this block. Doesn't solve the problem.

Really?

This happens sometimes when you have the report block in the definition of a “safely try” block. It’s quite strange, but basically the report block overrides all its parent scripts so that it can report the value. I’ve encountered this back in the days when JS wasn’t disabled.
Try using the reporter version of the gray PRIMITIVE block instead.

I said it doesn't work either.

Using REPORT in a command block is an error. Apparently we don't give an error message for it, but we should.

Perhaps you're using it wrong, e.g., not calling err_reset? The reporter SAFELY TRY in the library doesn't use it, to my surprise; it has a command SAFELY TRY inside.

I guess I don't really understand why you want to rewrite this library...

I mean if I use that reporter doesn't solve the problem (the list is still weird).

It's like the safely try block but it returns a list containing information:

Who would know without trying it?

Disagree. I like using commands to make definitions.

In Scheme, expressions can act like reporters:

(if (< x y)
    (expt 2 x)
    (expt x 2))

or commands:

(if (< x y)
    (print "x is less than y")
    (print "x is greater than or equal to y"))

You can use
[scratchblocks]
(call ({­::control}::grey ring)::control)
[/scratchblocks] reporter.

???

What do you mean?

I can't use images bc Snap! website is down.

Try using

Do you mean that this works?:
untitled script pic - 2021-12-29T220132.436

Yes :heavy_check_mark:

That's because the

[scratchblocks]
...
report (... :: grey) :: control cap
[/scratchblocks]

is a reporter disguised as a stack of commands

Ok, so do you have a solution?