I don't remember what the goal was (stopped working on it eight months
ago), but some possibilities include:
- better handling of nil (have trouble with assigning into struts)
- automatic forward declarations ala C# and jai (I was watching vids
about jai at the time)
- something for pascal
- simply that the default symbol type should not be var (in which case,
goal accomplished)
Currently, they can represent either vectors or quaternions, and the
quaternions can be in either [s, v] form or [w, x, y, z] form.
Many things will not actual work yet as the vector expression needs to be
converted into the appropriate form for assigning the elements to the
components of the "vector" type.
This is a nice feature found in fteqcc (also a bit of a challenge from
Spike). Getting bison to accept the new expression required rewriting the
state expression grammar, so this is mostly for the state expression. A
test to ensure the state expression doesn't break is included.
This goes towards complementing the "if not" logic extension. I need to
check if fteqcc supports "not" with "while" (the version I have access to
at the moment does not), and also whether it would be good to support
"not" with "for", and if so, what form the syntax should take.
It is syntactic sugar for if (!(foo)), but is useful for avoiding
inconsistencies between such things as if (string) and if (!string), even
though qcc can't parse if not (string). It also makes for easier to read
code when the logic in the condition is complex.
Empty structs are now (correctly) invalid. The hack of using an empty
struct to represent a handle returned from a builtin has been unnecessary
since opaque structs were implemented: now a pointer to an opaque struct
can be used. This is mostly safe as handles are aways negative and thus
attempting to dereference such a pointer should result in a VM error. It
will be even safer once const is implemented and the pointers can be made
constant (eg, typedef struct handle * const handle;)
This is needed to allow compile-time protocol conformance checks, though
nothing along those lines has been implemented yet.
id has been changed from TYPE to OBJECT, required to allow id <proto> to be
parsed. OBJECT uses symbol, allowing id to be redefined once suitable work
has been done on the parser.
Turns out there was only one place to fix (for qc, anyway: I don't have
tests for qp yet). func-static now passes :)
Hmm, how to test for static var naming... (not implemented yet)
With the intoduction of the statement type enum came a prefix clash. As
"st" makes sense for "statement type", I decided that "storage class"
should be "sc". Although there haven't been any problems as of yet, I
decided it would be a good idea to clean up the clash now. It also helps
avoid confusion (I was a bit surprised after working with st_assign etc to
be reminded of st_extern etc).
This required throwing out the primary rules that snax did up to help me
with conflicts many years ago, but they were now getting in the way. Now
the productions from primary are merged in with unary_expr.
Since gnu bison and flex are required anyway, no harm in using their api
prefix options. Now, qfcc can compile both QC/Ruamoko and Pascal files
(Pascal is (currently?) NOT supported in progs.src mode), selecting the
language based on the extension: .r, .qc and .c select QC/Ruamoko, .pas and
.p select Pascal, while anything else is treated as an object file (as
before).
Assignment of nil to a field function is permitted, but trying to use one
as a builtin or as a normal function is treated as an error.
.void (float y) func; OK
.void (float y) bi = #0; error
.void (float y) ni = nil; OK
.void (float y) co = { }; error
The parser wants to treat .float () foo; as a function returning a float
field, but qcc treats it as a field holding a function variable.
Fortuantely, field types are always "simple" (ie, at worst, just more
field type wrappers around the non-field type), so all that's needed to
obtain qcc grammar is to reach into the field type layers and do the
function type calculation based on the non-field type found there.
Due to ambiguities in the grammar, qc-style function params and c-style
function params had to be completely separated. This means that qc-style
functions can not use pointers and must use qc-style function declarations
for parameters, and c-style functions must use c-style param declarations.
While this rule is tedious for converting the Ruamoko library, it does
actually make for a more consistent language.
The root class's ivar symbol table needs to be connected to the global
symbol table while building the current class's ivar symbol table. This
allows access to other classes and typedefs.
find_type now operates recursively (depth-first) so built up typechains
work as expected.
@overload is treated as a specifier (directly as a storage class, similaar
to typedef).
While broken, it is good enough to compile modulo.r.
This gives qfcc C's type system with QC specifics bolted on top (rather
than trying to cram C's type system into QC's). Pointers and arrays now
use C syntax and semantics (though I think there's a lot of breakage in
there at the moment). Functions themselves are still dual mode: both QC
style and C style are available.
