Tip
QuickNotes are short, quick, informal notes. Often to order my thoughts and analyse the options before I write the
“real” design (or other docs).
They are unofficially published. You can read them but do not expect that they are well written. Or till actually, as
maintaining them is not a goal.
QuickNote: typedParameters in Event?
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
data-structures.
Intro
When implementing (and testing) the RPy backend, I discovered the use of TypedParameters was not consistent. In some Jinja templates that information was written into (generated) RPython files, in others not. Also, as was sometimes required by the “reference” files, and in other case not.
Because those (generated) files can’t be run (before all/most of the files can be written), that mistake was only discovered recently [1].
So, I have to make a “Design Decision”: put those TypedParameters always in the generated code, or newer?
TypedParameters?
As a reminder:
The parameters or (formal arguments) are the “placeholders” in the function definition; they always have a name (that is used as a variable in the body), and optionally a type – this depends on the language. In Castle, parameters have types
When calling those functions, we speak about arguments; then they have a value.We use the term TypedParameters to denote a sequence (a list/array) of TypedParameter (S); where each TypedParameter is a tuple of a name and a type.
Why (Not)
When a Castle program defines (e.g.) an event, the parameters are given. The Castle-compiler should check the
remainder of the program for consistency [2] and so, TypedParameters are used at many places [3].
That is however another matter.
Here the question is; should that information be “stored” inside the (generated) code, so that the program itself can inspect it [4]? – that is runtime …
Doubtless, we can write code without this feature; ‘:ref:`Castle-TheSieve’ does not need it.
But, unequivocally, when it is available – like in Python, it is a powerful feature. The question however is: what does
it do in Castle?
That is a hard question.
Other languages
When studying other languages, we see several approaches. Older, traditional languages (like C and the early versions of C++) do not have it. Modern languages, like Python, do use it heavily (although some claim: “do misuse it”).
C (ansi C)
Not an option
C++
C++, as an “OO version of C”, traditionally did not support any form of runtime information.
Recent versions of C++ have a limited version of it; even in two approaches: - (type) traits: https://en.wikipedia.org/wiki/Trait_(computer_programming) - RTTI: https://en.wikipedia.org/wiki/Run-time_type_information`
C#
C-sharp supports something called introspection or reflection. There is a lot of online discussion whether it is a
fully-flagged feature, or just changing names. I’m not going to judge here.
Apparently, the feature is useful – if it is not, nobody would care to discuss it.
Java
Java has something called The Reflection API (although it says one should use “improvements” – without any links.)
Python
Everything in Python is an object, that holds “life type information” (including doc-strings, type and even code). One can runtime inspect types (and names), and even generate new types. Can be very convenient.
Ruby
Roughly the same as in Python, see above.
Rust
After a bit of googling, it appears that Rust does not have any (powerful) feature to inspect types at runtime –
although it has something called “traits”. Still, the sources on the internet are not clear about it – some say it
has, some say certainly it has not.
Given no text-books write about when or how to use it, I assume it’s not available.
Design Decision
Given, many languages like it, we made some decisions; both for the long run, and for the short one.
At the moment, we see no reason to have the TypedParameter info available in the runtime. The current (Castle) examples do not use it, nor is that info used in the “handCompiled” code (incl QuickNote: The Sieve in RPython). On the other-hand, it is very powerful (e.g. in Python), and “bolted-on” to a traditional language such as C++ with (type) traits. Therefore, we like to keep it as an option, for future addition. This implies we have to design the interface in the language. |
The first (bootstrap) compilers don’t need to support introspection. And so, the (initial) RPy backend does not have to store TypedParameters (for events) in the runtime.
|
Eventually, the Castle language should support introspection. (but now now, see No TypedParameter is 1st co... (DD_No_Introspection_in_1st)). This implies we have to make a great language design on the interface (for the Castle programmer) on how to use it. We like that is act as a “1ste class citizen”, not as a “bolt-on addition” |
notes
Comments
comments powered by Disqus