Posts in QuickNote
The RPy compiler backend needs to ‘fill-in’ some data structures, like
CC_B_Protocol – there is one for every
protocol. It contains the name of the protocol, its kind (like Event, as we assume here), and a list of
events. That event list contains the (event) name, it’s sequence-number (see: Modelling the Event Index), and a backlink
to the protocol.
The question is: Should the
Event (dataclass) contain the typedParameters?
This question affects both the runtime (for this backend) –the RPython implementation of
CC.buildin.CC_B_P_EventID– and the (jinja templating) to generate the code to fill those
Before implementing an RPython backend, a short study of RPython is made, including implementing The Sieve demo (start/DRAFT) in RPython. It’s like a hand-compiled RPython variant, following the approach as described in the Jinja rendering study), for the CC2CPy backend.
Writing RPython isn’t too complicated for someone with a C-background. But making the code pass the RPython compiler
can be tricky, however. Both, as just added statements can interfere with existing code – when that isn’t “static
enough”, new code can trigger compile errors in old, tested code! And, because the RPython compiler isn’t that great
in giving helpful info.
It feels like old-style debugging: try-and-error, remove-and-enable-lines, one-at-a-time until one understands and it becomes easy to fix…
This blog is both to share some RPython experience and to study the patterns that are needed to generate RPython code to implement the Castle-Compiler.