Had a good discussion over the last couple of days regarding Unicode handling in Epoch. As of now my plan for supporting Unicode is to add yet another pass to the lexer/parser system (woohoo for multipass compilation... C++, eat your blackened little heart out).
Essentially, the first pass will read the source code, strip out all Unicode strings, and replace them with ANSI placeholders. This will make it possible to run boost::spirit on the remaining text. The original Unicode text will be preserved in a lookup table, allowing the parser to dump the original Unicode symbols to the user if an error occurs, for example. Aside from that, the main area of support is Unicode-aware string objects, which should be fairly straightforward to implement given the way I've written the StringVariable class.
All that will wait until the future, though, because I'd rather see core language features get done first. It's also a perfect candidate for opening up the project to other programmers with actual Unicode experience, so they can ensure the Unicode handling is robust. In my dream world where everything goes perfectly, another programmer or three will show up and contribute some patches to the open-source project, which enable Unicode support.
Unicode is one of those features that seems like it'd be hard (or impossible) to bolt onto a language post-hoc, but with this plan, I think it should actually be pretty painless.
Flow Control
The break and return functions are now implemented. These builtins do pretty much exactly what you'd expect.
One quirk between Epoch and most languages is that return() accepts no parameters. It assumes that the return values are properly set using the standard return-variable method prior to exiting the function. I might add some syntactic sugar to change this in the future, but for now it seems to be fine. Of course, I also haven't written any nontrivial Epoch software yet, so it may turn out to be very much not fine. We shall see [smile]
Structures
As I write this I'm about to go start hacking on structures. Thus far I have a two stage plan: first, refactor the Tuple code to use a base class, CompositeType. Then, extend CompositeType to support both tuples and structures. Once structs are done, we're looking at a nice shiny Release 4.
Release 4
R4 is easily going to be the biggest jump forward in Epoch's progress yet. The power of the language has increased so dramatically it's kind of hard to really grasp. This thing is growing faster than I ever expected, and it's great to watch the project balloon into something that I'd actually love to code in.
I continue to make small tweaks every now and then to various things like the syntax error response mechanisms. For instance, a lot of errors are currently fatal that should be recoverable by the parser; this allows the parser to report multiple syntax errors instead of just stopping at the first one it sees. So far the syntax error handling is pretty precise and usually very informative, so I'm happy about that. One thing I've always hated about C/C++ is the habit of compiler writers to leave very cryptic syntax errors.
Of course, Epoch is also deliberately designed to be easy to parse, which is very much unlike C++ - so, to be fair, I've got a much simpler job [grin]
I still hope to get R4 out in the next couple of days. Hold on to your pants!
Status Report - 0054 hours
The basics of structures are now in place. The two big pieces remaining are the padding logic (which should be easy) and logic to pass pointers to structures to external APIs, mainly the Win32 API. That one isn't going to be so simple I suspect; but it shouldn't prove too difficult.
I think I'm going to cash in for the night, so these additions will probably come later on over the weekend. As soon as those two things are done, I'll start tying up loose ends and prepping for R4.
