for programming languages, if you want to learn how to make your own you're going to have to learn how to write a compiler. all languages other than machine code running on bare metal are compiled. the three options for this are to write a compiler which converts your code directly into machine code (which is very difficult, and becomes exponentially more so if you want it to work on multiple architectures), a compiler which converts your code into some other language, which is then compiled (which is a bit roundabout and messy, so it isn't very popular), or a compiler which converts your code into bytecode that is executed by a virtual machine written in some other language (which is the most widespread method today).

every good compiler needs to have a few basic parts:

-a lexer this converts plain text files into strings of tokens, with associated types (string literal, type identifier, list, etc) which the language uses. there are plenty of dedicated lexers out there that you can easily include directly in a new language. flex is a particularly popular one.

-a parser this takes your now-tokenised source and searches for illegal statements (something like: int "tasty";, for example, if you're writing C). there is a lot of interesting theory behind the best methods of doing this, but again, you'd be best off just using one of the many pre-made parsers out there. bison is a popular one

-a method for organising data elements (symbol table) and recursive statements (syntax tree). this step will be as easy or as difficult as the complexity level of the program you're writing. if you're making a simple, purely functional language you can use whatever structure you want to store your symbol table. even a giant list would do, though you'd probably want to use something like a heap in order to reduce lookup times. the syntax tree does pretty much have to be a tree structure. this is because it breaks code up into a hierarchical structure so that everything afterwards knows the correct order in which to read your source code. if you had the following code, for example:it might be translated into a pre-order syntax tree like this:obviously, if you want to work with objects, variable scope, etcetera, this all gets more complicated.

-semantic checking. traverse your tree and find any inconsistencies (like a function that expects two parameters being passed three instead or a statement like "string literal" == integer, where integer is of type int).

-code generation part. if you're writing a simple, functional language, this part is really easy. just directly translate your now, organised program into its counterpart in whatever other language you're using (converting to machine code, some other language, or bytecode for a virtual machine), looking up variables in your symbol table as you encounter them while traversing the syntax tree and inserting references to them in your generated code (direct addresses for machine code or a virtual machine or names if you're translating to some other language).

-code optimisation part. scan over your generated code and apply any optimisations you can find. obviously, this part isn't necessary, but you will get slow results without it.

yay! keep us posted!

please don't necropost, particularly when you know full well that you are doing so and even shout it within said post.

dj, if it lets you send arbitrary keypresses, then all you have to do is write a small program that detects a certain button being pressed on the calc and sends the related keybinding for the emulator, right?
this sounds absolutely fantastic, by the way =DD

EDIT: you should really use a loop and a couple of lists in that example program instead of writing
over and over

probably the latter. we tend to not bring in many apple users.

brilliant =D
EDIT: hrrm, not being able to hold left and jump at the same time makes it a bit impossible to play...
DOUBLE_EDIT: the momentum, too =/

here you go!
(it's rather huge)

mononoke is so coooooolourful =D

this isn't an editor; it's just a tool for converting between file formats. someone could build an editor that uses it as a backend, though.

i added an include preprocessor directive! the format is:
##include path/to/file
and the contents of file will be inserted verbatim into the file at that point.

apart from the preprocessor and another token set option for pretty printing (in case you want to display "λ" rather than "lambda", etc), i'm fairly certain this is done!

new stuff:
* full pipeline support, so things like
are perfectly valid =D

* an option to strip excess whitespace (outside of strings) and comments (the format of which is specific to the language) from a generated program, so a file containing:
run through:
would generate:

* searching for individual tokens matching strings on the command line (so something like
would return:

* expanding leading spaces on a line to tabs for easier reading when converting from an 8xp

coolio, i'll take a look at that, then =). the rest of your xml files have already been a big help, by the way.

as for adding in support for xml files, it sounds nice, but i'm still not convinced that it's worth the trouble. at present, all it takes for someone to add in a new token is to write a single line in the form {first_byte, second_byte, "string" }, and then run make. compilation takes less than a second, and the result is a binary that can be dragged and dropped anywhere without the need of additional files, whereas adding in xml support would increase the size considerably and either require me to include some non-standard library or write a lot more code.

EDIT: both the default BASIC and Axe token sets are now complete =D

i just changed the storage format for other libraries so that they only need to list tokens that are changed from the main token set (like >Char instead of >Frac), so that should make maintenance a much simpler matter.

also, here's a little thing i thought people might find useful:

unfortunately, we cannot support implementing CAS features on a non-CAS model because to do so would be condoning cheating on tests. also, please don't create duplicate topics.

both topics locked

there isn't really any need for xml files. anyone can just poke me with a new set to add to the source (or do it themselves) and compile it in. it's not that much of an overhead, size-wise. i just finished adding in all the Axe tokens, for example, and it only increased the executable's size from 14.8kb to 19.9kb

hokay, those both seem like they'll be easy enough to manage. i'll add them on to the end of the todo list.


this is only for the 8x series, though. EDIT: hmm, #if (compile option = blah ) would be really useful for debugging purposes, though...

speaking of which, what changes have there been to the token set for the 84+SEC? are there any new 2-byte regions?

EDIT2: xeda and runer? i don't really trust myself to make sure all the grammer and axe tokens are defined correctly, so, once i write those, do you think you could take a look at them and make sure i'm not missing anything important?