OpenGL: (lack of) progress report

[Hendrik Boom]

I'm (still) building the up-to-date opengl binding for Racket.

It's substantially more difficut than I thought.

As some of you know, the existing OpenGL binding is generated from files
supplied by the standards orgaisation Khronos.

Being automatically gnerated, it was quite complete.

However, it is obsolete. Even the first simple exercises from the
authoritative so-called Red Book can no longer be translated into
Racket.

I undertook to update it, planning to simply rerun the same code on the
current version of the Khronos files.

Didn't work, because those files have not been updated.
Instead they have been replaced with new files satisfying the same
purpose, but in a completely different file format -- xml.

The old code no longer works on the new files.

Since I really wanted to use up-to-date OpenGL, I resolved to write a
new transpiler, from the new Khronos file format to the same old Racket
language.

I thought I would just have to replace the parser in the previus opengl
version.

I expected that debugging would be feasible by comparing the files I
generate with the files generated by the old opengl package. Most of
the content should be identical.

(this last generated bit at least, has turned out to be true!)

I was faced with several challenges:

* Really learning Racket. Up to now I've just been coding around the
edges of Racket so to speak. I like the language. And despite running
in an interpreter, that's Ok for computation-intensive graphics work
because most of the computation gets passed off to a separate processor,
the GPU.

* Figuring out the poorly documented code in the otherwise excellent
original version of the transpiler.

* learning OpenGL. I've used it before, but the arrival of shaders has
completely turned it inside-out.

* Deciphering the Khronos files. The XML isn't much of a barrier --
Racket's sxml package does the heavy lifting.

However, Khronos's use of xml doesn't have much to do with *any* current
undersanding of programming language semantics. Its xml syntax doesn't,
for example, understand that functions have function types.

Instead, the declaration of a function is split into two separate parts:
a prototype and some parameters. The prototype contains the function
name and its return type, together with a few random extras such as
asterisks.

An asterisk is there to indicate that the function doesn't return the
indicated type, but a pointer to it. But there's no syntactic
understanding that there's such a thing as a pointer type, and that the
abstract syntax for a pointer type should contain the thye of the thing
pointed to.

Similarly, there's no concept of a function type.

It's kind of a transcription of C.

---

So, given all that, I've been flailing around with my code, managing to
produce a lot of mostly correct binding.

That's, of course, not good enough.

What has happened is that I'm starting to understand the obstacles that
have to be overcome.

And that's a huge help in figuring out the original versino of the
transpiler.

My original plan of replacing the parser in the original version is
starting to seem feasible now. However, properties of the original
syntax reach far into the innards of its code generator.

I'm not giving up. I will proceed.

What I'll likely end up with is some kind of amalgam of the old code and
parts of the new code I've already written.

There will be success, unless I come down with coronavirus and die
first.

-- hendrik