6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
..
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
%toc
@civ {
to meet the bare minimum standards necessary to qualify as [!civilized] to my mind, a language must:
* support compilation, whether to bytecode or machine code (excludes gdscript)
* parse into an AST (excludes bash, php (or used to))
* support AST-rewriting macros (excludes everything outside the lisp family except maybe rust)
* use real syntax, not whitespace-based kludges (excludes python, gdscript inter alia)
* provide a proper module system (excludes C)
* provide for hygienic namespacing (excludes C, gdscript)
* provide simple, cheap aggregate types (excludes gdscript, java, maybe python depending on how you view tuples)
so, janet and fennel are about the only game in town.
}
................................................................................
abi: okay yes in reality it absolutely fucking does, everyone uses the same gods-damned amd one, in actual materially existing reality there is no interop problem at least on x86, but because we haven't ritually enshrined this model at ISO and pacified its marauding [!aramitama] with burnt offerings of motor oil and obsolete DRAM chips, we cover our eyes and pretend we cannot see what is sitting right in front of us. i love too compute dont u
so GDExtension is designed (if i may use the word liberally) with certain notions fixed firmly in mind. chief among them is that the actual C-level calls will be thoroughly ensconced in a suffocating buffer of template hackery, which will employ dark arts and crafts to generate gobs and gobs of impenetrable C at compile time. in fact, GDExtension is so designed that it is basically impossible to use it directly without a code generation layer. unwilling as i was to use C++ (it's against my religion), i wrote my layer from scratch, in janet.
this was not as bad as it could have been. janet has something [^deficient magnificent] in its stdlib that every language should have: a PEG module. the resulting program, ["tool/class-compile.janet] is under 1k lines! just barely. this tool is fired off by the makefile for the ["src/*.gcd] files, generating a header file ["gen/*.h] and an object file ["out/*.o] that implements the class described in the file. the care and feeding of this file format is described in the [>gcd GCD section].
deficient: it is deficient in one particular way: it only operates over bytestrings. so you can use a PEG to parse raw text, or you can use it to implement a lexer, but you can't have both a PEG lexer and parser, which is really fucking dumb and makes things like dealing with whitespace far more painful than it needs to be.)
##gcd GCD language
GCD is a simple IDL which is translated into [^complex much more complicated C]. it's designed to make writing GDExtension classes as close to the native GDScript experience as possible, without the syntactic hanging offenses. you define the structure of the class using GCD, and write inline C to implement your functions. linemarkers are emitted properly so when you inevitably fuck it up, the compiler will be able to apportion the blame properly.
complex: the generated implementation code is roughly 24x longer than the input file
the C "lexing" is pretty robust, and as long as you aren't doing horrible shit with the preprocessor (on the order of ["#define fi }]) it shouldn't choke on anything you write. if you [!are] doing horrible shit with the preprocessor however, [!you deserve everything you get].
|
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
..
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
%toc
@civ {
to meet the bare minimum standards necessary to qualify as [!civilized] to my mind, a language must:
* support compilation, whether to bytecode or machine code (excludes gdscript)
* parse into an AST (excludes bash, php (or used to))
* support AST-rewriting macros (excludes everything outside the lisp family except nim and maybe rust)
* use real syntax, not whitespace-based kludges (excludes python, gdscript inter alia)
* provide a proper module system (excludes C)
* provide for hygienic namespacing (excludes C, gdscript)
* provide simple, cheap aggregate types (excludes gdscript, java, maybe python depending on how you view tuples)
so, janet and fennel are about the only game in town.
}
................................................................................
abi: okay yes in reality it absolutely fucking does, everyone uses the same gods-damned amd one, in actual materially existing reality there is no interop problem at least on x86, but because we haven't ritually enshrined this model at ISO and pacified its marauding [!aramitama] with burnt offerings of motor oil and obsolete DRAM chips, we cover our eyes and pretend we cannot see what is sitting right in front of us. i love too compute dont u
so GDExtension is designed (if i may use the word liberally) with certain notions fixed firmly in mind. chief among them is that the actual C-level calls will be thoroughly ensconced in a suffocating buffer of template hackery, which will employ dark arts and crafts to generate gobs and gobs of impenetrable C at compile time. in fact, GDExtension is so designed that it is basically impossible to use it directly without a code generation layer. unwilling as i was to use C++ (it's against my religion), i wrote my layer from scratch, in janet.
this was not as bad as it could have been. janet has something [^deficient magnificent] in its stdlib that every language should have: a PEG module. the resulting program, ["tool/class-compile.janet] is under 1k lines! just barely. this tool is fired off by the makefile for the ["src/*.gcd] files, generating a header file ["gen/*.h] and an object file ["out/*.o] that implements the class described in the file. the care and feeding of this file format is described in the [>gcd GCD section].
deficient: it is deficient in one particular way: it only operates over bytestrings. so you can use a PEG to parse raw text, or you can use it to implement a lexer, but you can't have both a PEG lexer and parser, which is really fucking dumb and makes things like dealing with whitespace far more painful than it needs to be.)
##obj object model
godot uses a strongly javalike OOP system, which translates poorly to Janet's prototype-based OO. gdjn therefore uses the following convention to translate between the two.
the engine executes the "compile-time" phase of a janet script once it is finished loading. it is the responsibility of the compile-time thunk to set up the local environment to represent a class using def statements. the abstract serves as a proxy for method calls. when a lookup is performed against a class proxy, the proxy inspects its attached environment and returns an appropriate object.
unadorned immutable bindings are treated as constants. values with the [":field type] annotation are treated as object fields. when a new instance is created, space is allocated for a field of the appropriate type, and initialized to the value of the binding. public [`var] mutable bindins are treated as static variables.
~~~[janet] example bindings
(def name "Lisuan") # constant string
(def name :field "Lisuan") # field of type string, initializes to "Lisuan"
(def name {:field :variant} "Lisuan") field of type variant
(def- secret "swordfish") # private constant
(def- secret :field "swordfish") # private string field
(var count 0) # static variable of type int
(var- count 0) # private static variable of type int
~~~
unadorned functions are treated as static functions.
private functions (those declared with [`def-]) are available only within the class implementation. they are not exported as methods.
functions with the annotation [":method] are treated as methods. when invoked, they are passed a [`self]-reference as their first argument.
function type signatures can be specified with the annotations [":takes [...]] and [`:gives [$type]].
tables with the annotation [":subclass] are treated as environment tables specifying inner classes. the macro [`subclass] should generally be used to maintain uniform syntax between outer and inner classes, e.g.
~~~[janet]
(use core)
(use-classes Object RefCounted)
(declare outerClass :is Object)
(def val 10)
(prop v vec3)
(defclass innerClass :is RefCounted
(def val 2))
# equivalent to
(import prim)
(def Object (prim/load-class :Object))
(def RefCounted (prim/load-class :RefCounted))
(def *class-name* :meta :outerClass)
(def *class-inherit* :meta Object)
(def val 10)
(def innerClass (do
(def *class-inherit* :meta RefCounted)
(let [env (table/setproto @{} (curenv))]
(eval '(do
(def val 2))
env)
env)))
~~~
since the annotations are somewhat verbose, macros are provided to automate the process.
+ janet + gdscript
| ["(def count 10)] | ["const count := 10]
| ["(def count {:field int} 10)] | ["var count: int = 10]
| ["(defn open [path] ...)] | ["static func open(path: Variant) ...]
| ["(defn open {:takes [:string] :gives :int} [path] ...)] | ["static func open(path: String) -> int: ...]
| ["(defn close :method [me] ...)] | func close() -> void: ...
##gcd GCD language
GCD is a simple IDL which is translated into [^complex much more complicated C]. it's designed to make writing GDExtension classes as close to the native GDScript experience as possible, without the syntactic hanging offenses. you define the structure of the class using GCD, and write inline C to implement your functions. linemarkers are emitted properly so when you inevitably fuck it up, the compiler will be able to apportion the blame properly.
complex: the generated implementation code is roughly 24x longer than the input file
the C "lexing" is pretty robust, and as long as you aren't doing horrible shit with the preprocessor (on the order of ["#define fi }]) it shouldn't choke on anything you write. if you [!are] doing horrible shit with the preprocessor however, [!you deserve everything you get].
|