It might be helpful to readers to have a comment above this with some examples of the format of func that we expect. Based on the code below it looks like global functions might just be e.g. sin and class methods might be like p5.Vector.add?

I got this part from the original validate_params file and I believe that's the case!

We might have to do something a bit more complicated to handle cases like the lerpPalette one, which ends up looking like [p5.Color, Number][]. A quick fix could be to just add that to the schema map for now though.

I'm also noticing that we have some options objects (e.g. for p5.Geometry.computeNormals()) that currently end up just typed as Object, whereas in docs/data.json it has this extra properties info that we don't yet use:

{
  "title": "param",
  "name": "options",
  "lineNumber": 11,
  "description": {
    "type": "root",
    "children": [
      {
        "type": "paragraph",
        "children": [
          {
            "type": "text",
            "value": "An optional object with configuration."
          }
        ]
      }
    ]
  },
  "type": {
    "type": "OptionalType",
    "expression": {
      "type": "NameExpression",
      "name": "Object"
    }
  },
  "properties": [
    {
      "title": "param",
      "name": "options.roundToPrecision",
      "lineNumber": 423,
      "default": "3"
    }
  ],
  "default": "{}"
}

That could be something we try to encode in the type eventually, e.g. instead of Object, it could be { roundToPrecision: number? }. We can decide that's out of scope for now because that would probably necessitate a recursive parser to extract the type info (or just more structured info in parameterData.json rather than just a type string.)

Thank you for bringing these edge cases up Dave! I'm adding both of these scenarios in my notes and will circle back to them later!

nice!