Hmm... guess what THIS is about...

Published August 26, 2008
Advertisement
Had a few spare minutes today, so I hacked up serialization and got it finished. Turns out it was a lot quicker of a job than I expected.

I also decided not to serialize directly to a binary format. Instead, the serialization process outputs an assembly language file that targets the Fugue virtual machine. Eventually, I'll write an assembler to convert that to a binary form; after that, all I need is a deserializer to load the binary bytecode back up into the VM, and I'll be all set to start distributing executable Epoch binaries.

Release 4 was supposed to basically be the serialization and disassembler tool; serialization is done and the disassembler is no longer necessary. So instead I'm taking some time to shore up the syntax error handling and get things working nicely.

Thus far I've fixed several cases where the parser would detect a syntax error, then get stuck in an infinite loop and perpetually report the same error over and over again. I'm also working on minimizing the number of errors that are fatal - that is, the parsing phase should do as much parsing as it possibly can, and report every error it detects. This means you don't have to re-compile your programs 50 times because you keep finding new errors.


I expected my little release roadmap to end up being more or less useless, but I didn't think it would happen this fast [lol] So here's a revised roadmap:

  • Release 4 - serialization to assembly language, improved syntax error handling, some new library functions

  • Release 5 - support for tuples and structures; Scribble demo app


Past that I haven't really thought of anything; I don't want to get too far ahead of myself. Besides, I expect that during the Scribble project I'll find plenty of things that need to be done, so R5 will probably guide me a long way towards what is needed in R6 and beyond.

That said, I still have a rough idea of what all I'd like to add to the language before I consider it finished:

  • Garbage collection

  • Manual memory management and pointer support

  • First-class functions and higher order functions

  • Some kind of object/message-passing model

  • Transparent, first-class multiprocessing support

  • At least one port to another platform



Definitely a lot of work ahead... but I'm enjoying the hell out of this project so far, so I don't suspect that the workload will be too much of a problem [smile]
0 likes 2 comments

Comments

Daerax
Thats all coming along cooly. One thing I do not like is pointers. Why would you want this in a scripting language? It will also make your garbage collector that much more complex. Finally it will get in the way of any parallel type code.
August 27, 2008 10:41 AM
ApochPiQ
Epoch isn't intended to be a scripting language; the goal is for a full-featured generic language that is ready for use in both low and high level applications.

For instance, suppose we want to write a small game in Epoch, targeting the Win32 API and the standard GDI. In order to communicate with the API, we'll need a lot of C-like features, including pointers to structures, function pointers for callbacks, and so on. In a larger project that uses a more sophisticated API like DirectX or OpenGL, this becomes even more important.


Unless, of course, there's a safer approach which I haven't thought of...
August 27, 2008 01:08 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement