ddly, something where I am actually doing something with language design
again, imagine that...
summoned up from an email:
well, I really don't know if anyone cares, but oh well...
well, I got around to fiddling with it, and basically got around to adding
FFI-free calling into C from my BGBScript interpreter (note: BGBScript is a
so, mostly this was a matter of adding a few API functions (to my DYLL
library), as well as fixing a few bugs which were lurking around (apparently
there were a few bugs related to metadata loading, ...).
(all this currently depends on the metadata databases produced by my
"bgbmeta" tool, which is basically a modified version of my C compiler
frontend mostly used for mining crap from headers, and which has apparently
actually come in useful for something...).
but, this is nothing major...
but, after all this, now BGBScript can call into C code without needing to
use any sort of FFI:
as in, no writing glue functions, or even having to tell the interpreter
about function prototypes.
actually, a lot of the code was already in place, and WRT some of the
specifics, I forget actually how some of this stuff actually works... (the
terrible internals of my BGBDY and DYLL libraries...).
granted, there are a few issues remaining, but generally it seems to be
so, current limitations:
it doesn't currently deal with complex data types (such as structs or
unions, or even raw array-based data);
type handling is fairly weak, and often relies on the good graces of the API
code having used the GC and types-tagging (common practice for my code which
uses the GC), otherwise the dynamically-typed code would see the references
as raw untyped pointers (this is the general behavior for malloc'ed memory
handling C's typesystem would be possible, but would require some sort of
special handling (such as using a box to attach a dynamic type to a raw
reference or similar).
'char *' is treated specially though, so whenever a 'char *' (or, actually,
"Pc" in my signature system), it is assumed to be a string and types are
marshalled accordingly (fiddly: may make it not do this if the pointer
already has a dynamic type, as "char *" could also be a symbol / ...).
at present, variable argument functions are not likely to work correctly
either, but I could address this (allowing for stuff like BS code to use C
functions using printf-style formatting, ...).
note: for OpenGL apps, BS should probably also be able to access GL without
too many issues, ...
next goal might may include making BS not suck...
(fixing issues, maybe adding JIT, ... could help here...).
but, then again, access to the C toplevel (and partial access to the C
typesystem) does help, as then I can interactively type commands and have
some hope that they can actually do something (this being something which
technically doesn't really work with my C compiler...).
or, IOW, like Scheme and JS, BS can also be interactively typed and show the
results of expressions (this being something I couldn't manage to pull off
well with C, as it doesn't mix well with C's type semantics...).
making all this stuff works does itself depend on my assembler (and is an
example of the use of my assembler), as random crap, like applying arbitrary
arguments to arbitrary C functions