Slicing directly from non-mesh data? This is a bit of a weird question, and I imagine the answer might simply be "no." But here goes anyway:

I'm writing some code that generates shapes for 3D printing via "implicit surfaces," i.e. a mathematical function f(x,y,z) that is positive inside the shape and negative outside it. This works pretty well for designing the kind of shapes I want to print, but the problem is, turning the implicit surface into a good mesh is hard - there are some libraries that can do it, but they're kind of finnicky and you have to play with parameters a lot to get it to work well.

But I was thinking: the only reason I need a mesh in the first place is to send it to a slicer, which will ultimately throw away the mesh and turn it into gcode instead. My plan was to do

implicit function --&gt; STL file --&gt; gcode

but I'm wondering if there are any slicers that will let me skip the intermediate step and let me just do

implicit function --&gt; gcode

instead. That is, my code would supply a 3D grid of voxels, containing the value of the function at each 3D point, and the slicer would create the gcode from that instead of from an STL file.

It seems that Shapeways have a nice and simple format called SVX that is exactly this, but as far as I can tell, this is only supported by Shapeways and not by any FDM slicing software.

Another option would be for my code to supply a sequence of 2D polygons, one for each layer of the printed model, so the sequence would be

implicit function --&gt; big list of slices --&gt; gcode

This would be both easier and more accurate than first converting it into a mesh, and I assume the slicer must generate this kind of representation anyway, before it calculates the path for the print head to take.

I suppose the question is, is there an existing CAD format that supports either of these options, that is also supported by existing slicer software? If so then I can just write my code to output in that format and it should just work.
No, not natively
To the current point, all slicers in frequent use do use some kind of 3D model with explicit surfaces to cut up into slices and then solve the path functions to create the G-code. The model can be in STL or OBJ or some other format, depending on the slicer, but at this point (November 2019), no slicing program I know about supports direct math as input.
Probably make it yourself?
However, you have a way to design the models by solving a mathematical formula. You could probably use the program that solves the formulae to also act as a slicer of some sorts.
One software that might form a base could be Cura, which allows writing plugins, so there might be a way to have Cura automatically solve the surface formula and then plug that into the slicing without storing the intermediate data as an STL.
Slic3r might also work as a base since the whole source code is open. It would be a similar endeavor as modifying Cura.