My preferred solution, FYI, would be some kind of crazy thread-specific namespacing. Then, by having large numbers of light-weight threads, name collisions wouldn't be an issue anymore. (Yes, you could say this is similar to a module system, if you want to be pedantic :-)
It may not be pure OpenGL, but my OpenGL book says that glXUseXFont will load an X font, which builds a bunch of display lists, each one of which containing a character rendered with that font.
I'm curious though. Why OpenGL? SDL plus SDL_ttf could have handled things just as well, plus Y would have pointed down, not up.
Simple DirectMedia Layer. Cross-platform multimedia library that has audio, input and 2D graphics. SDL_ttf is a standard extension to it that provides TrueType font support. If Arc can load C libraries, it can should be able to load SDL.
It's risky to say "you should do X" or "you shouldn't use Y" when talking about using programming languages, because they don't look at the problem being solved. Using variables may be a very natural way to approach problem A, while they'd be very clunky for problem B.
I am asking because it is a common mistake when moving from an imperative language to a functional language. I know I made the mistake of trying to use many variables when I first started writing functional code. I was asking so that I could help out.
I never said "you shound do ..." or "you shouldn't use ...".
I have no problem with people using whatever style or approach that they want. If you want to write arc with gotos and a bunch of variables, go for it. I just wanted to help this arc coder out.
The system uses some sort of equation based on the submission time and points of each topic to determine the topic ordering. Changing that equation to use the last response time of each topic would do it.
The arc implementation doubles as the specification. Piggy-backing on mzscheme's gensyms seems like an attractive prospect at first, until you realise that we now have a part of arc which isn't defined in arc. The only way that could work is if gensym becomes considered as a language axiom, and I'm not sure if it's really a candidate for that.
In practice, I wouldn't believe to be that much of a problem. Who would want to mimic the abominable symbols generated by arc with the current methods anyway, intentionally or otherwise?
You have a good point there. Fortunately it can be fixed trivially, by returning the definition of 'ar-gensym to its original form and using 'string->uninterned-symbol instead of 'string->symbol. (I suspect this is what mzscheme 'gensym does anyways.)