basiC (just for fun)
Blitz3D Forums/Blitz3D Programming/basiC (just for fun)
| ||
| Something I knocked together in a couple of hours, to see whether it was possible... EDIT: Download examples and .exe here: https://sites.google.com/site/nangdongseng/downloads/basiC.rar?attredirects=0&d=1 The Included file "BBLex_basiC.bb" is an automatically-generated lexer from the following lexer template: The end result, when you plug it all together, is a really tiny "translator" that converts a cut-down BASIC-like syntax into standard C, to compile with GCC or a compiler of your choice! Syntax is largely based on Blitz3D, with a few alterations: - type field access is with . rather than \ - variable and function type names are separated with : rather than . (you can still use %, #, $ as well) - All local variables MUST be declared before use (this is because C is superstrict by nature). Functions, types, and global variables can be declared anywhere within a source file (although this won't magically carry across Includes, so you need to Include the file with the definitions above any uses of the identifiers). In both cases, specifying a type is optional; if you don't, Int will be assumed. You can also specify functions as void. - available types are the same as Blitz3D - int, float, string (well, char*), and pointers to type objects. You can't declare pointers to basic types, or create literal structs. There are also function pointers (see below). - there is no "body code" - you must have a function named "main", as per normal C code (and it should ideally have the argc, argv parameters, or be void, unlike in the example below). - there are no "commands" (functions that return no value, and act as a statement eg. MoveEntity). All functions, even of type void, MUST have parentheses around the arguments. Sorry. This also goes for New() and Delete(). - ":" is a line separator (only available in function body). The main difference this causes from Blitz3D is that : serves the same role as an end-of-line; unlike in Blitz3D where you can stack multiple statements on the same line after an If/Then, to do that here you'd need to drop the Then and add an EndIf at the end. - Select/Case isn't as flexible; Case values must be numeric constants (as is true for C's switch/case). - You can optionally declare local variables as "static" instead of "local" - this means their value will persist between function calls. (You can also declare Globals inside functions and Locals in the outer scope... I would just ignore this "feature"). - No Dim() command, so you're limited to square-bracket arrays (how flexible these are depends on your C compiler). Arrays are not necessarily initialised to zero (although single variables and type objects are zeroed like in Blitz3D). - No banks, although recreating them would be pretty easy for the interested reader. - Types are "plain" objects and aren't added to any kind of global list; also, the B3D type list commands aren't included, so don't let them fall out of scope! Delete() sets the given variable to Null, but unlike in B3D, not other variables referencing the same object, so beware. - You can use "continue" as well as "exit" and "break". "Stop" is a Blitz debugger feature so obviously isn't included. - ALL OPERATORS ARE C OPERATORS! Important: this means = for assignment, == for comparison! BASIC operators <>, Mod, Shr, Shl, And, Or, Xor, Not are all included as well, however. Note that And and Or are bitwise (same as in Blitz3D). ^ is the C Xor operator; % (as Mod) is not available because we need it for the int type sigil. You can also use C's compound assignment operators (+= etc.). Some C operators may fail if given the wrong type (eg. trying to give Mod a float) - you can use casts the same way you would in plain C. - No string functions! The "$" or ":string" datatype is just a char *. Since string manipulation is BASIC's original big draw, this is a major omission, but oh well, too bad. String libraries are plentiful enough. - Include is available, but as mentioned above, names declared in included files won't be recognised *above* the line the file is included on. Joining it are Import, which does the same thing but only includes a file once, and IncludeC, which lets you include C code directly. - Function pointers are available, with the syntax: Local fptr1:int<int,float> , or: Local fptr4:int<int,float><int> (that's a function pointer that returns a function pointer like the first). I really don't expect anyone to use this for anything (I know I won't), but it was great fun to experiment! Sadly the code is waaaay too messy to be of much educational use... Here's an example program (successfully tested with GCC): Last edited 2010 |
| ||
| This looks interesting. |
| ||
| Cool. |
| ||
| what does this do? Local fptr4:int<int,float><int> |
| ||
Local fptr4:int<int,float><int> Assuming this code works as intended (well, it does for this because this was in the successful test) - Declares the variable "fptr4" as a pointer to a function, which accepts one int as its parameter and returns a pointer to a function, which in turn accepts an int and a float and returns an int. It is translated to this C declaration: int(*(* fptr4)(int))(int, float); ...which I believe is enough justification by itself for anyone to want a different function pointer syntax. The angle-brackets are used for function pointer parameter types because C doesn't have generics (actually C1X will have generics, of a sort, but not using angle brackets), so I thought it would help alleviate the confusion when declaring actual functions that accept or return function pointers. Pointers are called the same way as declared functions - with parentheses. In hindsight actually I think the biggest problem was trying to force function pointers to look like BlitzMax - if it weren't that compatibility with Blitz was important on these forums, I would actually have gone for something like Pascal or Go with the return type/value after the parameters - clearer and easier to parse. Or even something like SPECS for C++ ( http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C%2B%2B_Syntax ), which is lovely to look at but takes forever to type out. Last edited 2010 |
   |