nlupugla

Type Theory

Type theory is the mathematical and computational study of type systems, like the ones you use in popular programming languages. It can get very abstract, but I believe it offers some useful concepts to take home even for practical language design. In particular, I am interested in contributing to the Godot game engine's scripting language GDScript https://github.com/godotengine/godot/tree/master/modules/gdscript, so I will try to relate the abstract concepts to concrete examples in GDScript where possible.

The following are some notes I've compiled through some self-study that mostly includes skimming Types and Programming Languages by Benjamin C. Pierce https://github.com/MPRI/M2-4-2/blob/master/Types%20and%20Programming%20Languages.pdf, browsing various Wikipedia articles,

nlupugla

/* This gist details a way of representing type data in C++ that I have found useful for implementing structs.
 * Rather than represent type data as local variables on an instance of some kind of TypeInfo struct, 
 * I represent each type via static methods on a corresponding metatype. Representing the data as metatypes
 * allows the compiler to understand what our types mean and enables some cool template metaprogramming tricks.
 * defined at compile time, which allows for many cool template metaprogramming tricks. */

/* Here is an example of a struct whose members have been defined via metatypes.  */

struct NamedInt {
	StringName name = StringName();

nlupugla

I looked through Godot's API to find methods where a Dictionary is currently used and a Struct might be more approprate. I found about 130 methods accross the codebase. My approach wasn't terribly systematic: I used ctrl-f to search extension_api.json for "type": "Dictionary" and "type": "typedarray::Dictionary". I removed some methods from the list where a Dictionary really did seem appropraite. That said, there are probably still several "false positives" in this list. I don't intend to modify all of these on my own. Rather, I'll start by structifying a handful of the most commonly used methods and leave it to others to structify the rest as the need/demand arrises.

• ClassDB::class_get_signal_list()
• ClassDB::class_get_property_list()
• ClassDB::class_get_method_list()
• CodeEdit::_filter_code_completion_candidates()
• CodeEdit::get_code_completion_options()
• DisplayServer::tts_get_voices()
• EditorExportPlugin::_get_export_options()
• EditorImportPlugin::_get_import_options()

nlupugla

//// Under the current proposal, the workflow for exposing a struct would look like the following (using PropertyInfo as an example).

/// In Object.h, where PropertyInfo is defined

// Forward declare Struct template
template <typename T>
class Struct;

/// In Object.cpp

nlupugla

#define GDSTRUCT(m_struct)                                                                              \
private:                                                                                                \
	friend class ::ClassDB;                                                                             \
                                                                                                        \
public:                                                                                                 \
	typedef m_struct self_type;                                                                         \
	static constexpr bool _class_is_enabled = !bool(GD_IS_DEFINED(ClassDB_Disable_##m_struct));         \
	virtual String get_class() const override {                                                         \
		return String(#m_struct);                                                                       \
	}