@leif It looks like adding libatk is straightforward. I’m unclear on how racket/gui libraries would need to adapt to use it, but I can add libatk to “gui-<platform>” package if that’s all you need.
I’m beginning to think it might be possible to implement custom core forms as a derived concept (i.e. something that could go into the syntax/ collection). As I’ve mentioned before, I don’t think propagating the stop list from local-expand would be enough on its own, since you really need to implement some way for subforms to yield to the “custom expander” currently being used. Still, I wonder if it would make sense to, instead of modifying the macroexpander significantly, adding a syntax-local-stop-list function similar to syntax-local-context, then adding a syntax/custom-kernel module that provides a wrapped version of local-expand that respects an internal, phase 1 current-expand parameter. It would require macros to opt into cooperating with parent macros that use custom core forms, but it would eliminate the need to adjust the expander.
The biggest potential pitfall I see is with the syntax taints system, which I don’t completely understand the implications of, since I don’t understand it well enough to know if there would be situations in which the current code inspector would not be strong enough to disarm macro-produced syntax in places where it would be necessary. Still, it seems worth trying. @mflatt and @michael.ballantyne, do you have any thoughts?
@lexi.lambda I may be missing something of what you have in mind, but I’d expect the opt-in mechanism to implicitly (or maybe explicitly) give you the capability to manage relevant taint armings
The truth is that I don’t really understand how that system works. :) I understand in theory how syntax taints work and what they do, and I understand how they work in a controlled environment, but I don’t really get how the code inspector hierarchy works. Namely, if I can just call syntax-disarm to disarm any piece of syntax I want, how can syntax-protect provide any actual security? Therefore, I imagine there are cases when I cannot call syntax-disarm to avoid a taint, but I don’t know what they are.
Oh, cool! I’d never seen syntax taints.
Perl does taint checks on character inputs as a kind of information flow control, so your program can crash if unchecked data leaks into unchecking code. Syntax taints look similar but for program fragments instead of character buffers.
I guess it looks more complicated in Racket because you have more control, and Perl can taint a lot of stuff for you.
But when/where does syntax taint checking happen?
It happens in the macroexpander.
So leaky scopes can be detected before the program runs?
Yes, the program won’t even compile if you expand to tainted syntax.
that’s pretty cool
@joshua.erney has joined the channel