Status Update
My big challenge at the moment is to finish the part of the toolchain that builds a final wrapped .EXE program from Epoch source code. I have the rest of the toolchain in place, and used some dirty hackery to generate my test .EXEs; however, this time I'm aiming to do it right and generate an actual custom-tailored .EXE for each Epoch program.

The .EXE trick works by loading the Epoch bytecode into a data section of the .EXE, and then passing that block of memory off to the Virtual Machine to execute it - a fairly standard practice.

Where things get messy is including resources in the .EXE file. Resources take up space, which screws with offsets and all that good stuff. So in order to support resources in Epoch .EXEs, I have to essentially write a resource compiler that can update the relevant .EXE fields to point to the Epoch code, without disturbing the resource data.

I've been banging my head against the Win32 compiled resource format, particularly with icons. So far I haven't gotten much in the way of results, but the night is young...


Epoch Language Q&A
I've been meaning to do this for a while, so here we go. I keep getting comments on the Epoch posts and missing the questions/feedback people leave. (I will gently blame the journal software for this.) So what I'd like to do is take a dedicated post to just answering questions and feedback.

If you have any thoughts at all on the Epoch project - including, but not limited to, "shut up and talk about something different already" - just drop a comment on this post. I will monitor it for activity and update it with answers as time permits.

Quote: Original post by Falling Sky
How about support for embedded system programming?

In theory there's nothing that should stop you from using Epoch in an embedded environment; however, true support requires writing a cross compiler for the target platform, or at the very least a compiler that outputs C. I wouldn't rule out seeing an Epoch->C compiler arise at some point, but it's not on my priority list. I'd welcome anyone who is willing to write one, however [grin]

Quote: Original post by visage
How do you plan on a) allowing the user to give the compiler hints (syntactically) without things getting too cluttered and b) keeping the system extensible?

There's two parts to this. One half of the design is for a general task block, which splits off a parallel line of code which executes the contents of the block. Synchronization between tasks can be accomplished via a built-in lockless message queue. Tasks are only designed to be parallel to the main code body (and each other) - the language does not specify how this is implemented.

This brings us to the second half of the architecture: parallelism plugins. We can put a tag on each task block to have it handed to a given plugin. The default is to use the base platform's existing threading support; however, any other type of parallelism can be implemented in this way.

For example, we might run across a block such as task (gpu) { ... }. This will look in the compiler plugins for a parallization server called gpu. This server will be fed the raw Epoch code, and is responsible for emitting the actual shader instructions. Additionally, there is a runtime plugin which registers with the VM, and takes care of actually running the shader and returning the result data to the Epoch program. (Of course this will have analogous support in other compilation models; native code, .NET CLR, or whatever else we end up with.)

Quote: Original post by Mike.Popoloski
Your latest post talks about creating an IDE. I think it might be simpler to take advantage of the Visual Studio shell and create a language on top of that. Have you considered that option?

To be perfectly honest, I've tried the Visual Studio extensibility features (via the official SDK) and found them to be pretty much, well, shit. Visual Studio is incredible over-engineered. Yes, you can do virtually anything, down to writing your own syntax highlighter and debugger features. However, actually getting that done is ridiculously complicated.

Seriously, if you've never played with the VS SDK, you should try it out - it's a great object lesson in how not to design extensibility systems.

There's a couple other reasons I'm doing my own IDE. First of all, it means I can specially create everything to deal with working with Epoch. A tailor-made IDE can be a very useful thing; see Smalltalk. What I'd really like to do is build the IDE around a REPL (read/evaluate/print loop) which facilitates rapid prototyping, etc.

Secondly, having a standalone IDE means I don't have to worry about whether or not people have Visual Studio. As far as I am aware it isn't possible to extend the Express Editions of VS with new languages. This instantly cuts my user base down to people who have a full version of VS. Since my goal is maximum exposure, locking myself into an expensive (and fairly rare) product would be suicidal.

Finally, I'd like to see Epoch become like BASIC used to be back in the '80s, where just about anyone can sit down and fool around with the language. The .DLL that contains the Virtual Machine doesn't just execute Epoch bytecode; it contains a compiler that produces .easm files. To start writing your own Epoch programs you don't even need to download additional tools - any program written in Epoch automatically gives you the ability to write your own code.

I'm doing this entire project in the spirit that I would like to see Epoch become accessible, powerful, friendly to newcomers, and most of all, as open as possible.

There's also the fact that a language IDE written in its own language is pretty darn cool [wink] Plus, as I mentioned in the aforementioned post, it will show me lots of areas where the language isn't ready for prime-time yet, and give me a chance (and reason) to shore those areas up.

Quote: Original post by evolutional
Question for the Q&A: Will Epoch be targetted specifically for writing standalone apps or will it be embeddable within an application for user scripting? Additionally, what about the ability to create Epoch Dlls that can be imported as modules in Epoch programs (or even referenced by external apps?).

The Epoch virtual machine can be used either as a fully standalone system, or in tandem with another running language. Embedding Epoch is a bit messy at the moment, but totally possible. If it proves to be a high-demand feature, I'll clean it up a bit and add some features to make it even more robust and useful.

As far as multiple-file Epoch programs (including multiple source files and source files + libraries) I haven't done much planning yet, but eventually it should be trivial (for the user) to write Epoch libraries that can be used by Epoch directly or by other languages via the C marshalling layer.