Whoops!
Should be fixed now!
Does it work?
Since you are building a layer on top of the primitives, you can wrap values in such way that “false” as a Boolean can be discerned from “false” as an indication of a no-hit. Likewise you may want to discern the text “[2]” - note that quotation marks are NOT part of the text! - from “[2]” as a json-equivalent of a list with one element: the number “2”.
What you could do is prefix a type-indicator to each value. Positions within the following list indicate the type numbers as used e.g. by Snap! itself:
Since there’s over 10 types, you may want to code them, e.g. as a letter. In this scheme, “1” is stored as “A1”, “false” as “Bfalse” (or perhaps “B0”, with “true” as “B1”), a list with elements “1”, “2” and “apple” would be stored as “C[1,2,”apple”], and so on.
Edit
Adding to my post #43: considering a list may contain any combination of Snap! data types, while json only supports lists (including sub-lists) containing text, numbers and Booleans … the next step to a universal Snap! data storage facility would be recursive list processing.
Perhaps something like:
BTW in this example, lists are not preceded by a type indicator.
You fixed the error I reported, but there’s more errors in the code. I think you should do some proper testing by yourself first, then ask others.
If you use the json of and split by json, it automatically detects the difference between booleans and text.
The trick is, it doesn't put quotes around the booleans, only the text.
I'm also getting this error
True. But that works only when a Boolean is part of a list. Besides json doesn’t support all of Snap!’s data types.
Yeah, that's true.
I can actually do the custom block thing, but there is one thing I do need
This reports the index of each item where the booleen is true as a list
So for example let’s say I have a list of a bunch of booleens, if I did
This would report a list of the indexes of where each booleen set to true is inside the list
I kinda need someone else to write this, I could maybe but it would take a while
Yep! Thank you very much!
Update, I got the thing to kind of work ish?
It’s a start but it only works for blocks that have 1 stack block as their definition as it only reports the first block with whatever inputs are inside it
Update
IT WORKS!!!!!!!
Almost.. as you can see the “with inputs” isnt kept, well it is but it gets erased there’s no way that I can tell to properly do that as “run” doesn’t work with “join”
Here’s a version what works “with inputs”
As you can see with these. join needs the block ringifyed
Does anyone know a way around this?
I’m not sure if it helps, but perhaps my recent observations may increase your insight as to how blocks are turned into lists and vice versa, and associated quirks.
I’ll have a look at your INTO DEFINITIONS block one of these days, that may help me understand as well 
Other than that, all I can say is: metaprogramming Snap! is mostly a matter of trial and error learning by doing.
Btw where can I find a working version of INTO DEFINITIONS ?
It’s actually inside the “databasemore stuff” project
https://snap.berkeley.edu/snap/snap.html#present:Username=cookieclickerer33&ProjectName=Databasemore%20stuff
I’m still working out a way to make the run stuff work
Currently stuck on getting the variables that need to be run to work with the blocks
So I found something interesting! It turns out for the run block to accept the blocks they need to be double ringifyed!
Shouldn't there be WITH INPUTS: (INPUT) in there somewhere?
@cookieclickerer33: When definition code is in list format, input parameters are either the final items of the list (if the code consists of a single block), or the final sub-items of item 1.
I don’t think this is officially documented for users.
Yeah I think the final implementation was about a day before the release so nothing is very well documented. I'm spozta fix that too, between now and Snap!Con. :~(