Yayy triple post... who moderates this place, anyways? He should be shot!


I've posted two articles that should hopefully provide a gentle but thorough introduction to the language and its features:

• The Newcomer's Guide to Epoch


• The Epoch Programming Guide

In addition, the installation guide is much improved... as in, it actually exists now, and actually walks you through the install process rather than assuming you have the time and patience to figure it out without any hints [grin]

These should hopefully make it much easier to poke around and explore the language as a whole.



Right... three posts in a row is plenty, I think. Feel free to keep posting feedback as the urge strikes you; for my part, I'll stay quiet until R9 is ready for general consumption [smile]

Sexzay, I'll have to check this out.

I looked at this before, but it kept coming to the top ^^.

So I checked the site again, and must say I like the philosophy and the syntax didn't scare me away. I like the () -> () syntax for functions, this was also proposed in a C++-improved-syntax language which name I forgot.

I can confirm this runs on my Win7 32-bit build (guess the number). The CUDA example, however, crashed exegen (Exegen stopped working), is this because I don't support CUDA (my GPU is a very recent Nvidia one)?

Maybe you had your reasons, but it might be easier for people if the directory names were a bit standard, it's not important really...would just be less typing if it was Epoch/samples/parallel/stress.epoch then Epoch/Sample Epoch Programs/Parallel Examples/stress.epoch. But that's my POV.

Also, exegen sounds very generic, why is it not called epoch.exe?

For the rest, nicely done, good job! This looks likes it's going to be handy ;)

PS: any support for doubles and 64-bit integers? And can I display more behind the comma / dot for floats? No for loops?

[Edited by - Decrius on February 17, 2010 3:16:17 PM]

Do you have the latest CUDA SDK installed? Compiling CUDA-dependent programs without it currently doesn't work. (I'm planning on a more robust handling of that situation in R9.)

Directory names are kind of a subjective thing; I personally prefer more descriptive names over compact names, but that may turn out to bite me when porting over to Unixes. I'll think about renaming them for the future, although it's a low priority thing at best.

Doubles and int64 types are planned for the future, but I need to clean up some of the code before wedging in additional types, because at the moment it's a royal pain to do.

Output formatting is considered a really low priority for now, because the existing debug read/write mechanism isn't really intended to do much more than let you dump trace information to the console. (It will be replaced with dumping trace information to an attached debugger in the future.)

Last but not least - for loops. There are two basic things that a for loop is traditionally used for: iteration across a container or sequence of some kind, and counting. I have plans for a powerful foreach that will take care of the first case, and I'd rather have a specific syntax for the second case. Something like this:

count(i, [100..1]){  debugwritestring(cast(string, i) ; " bottles of beer on the wall.")}

That depends on the syntax I end up using for numeric ranges, though, and may just change entirely if I feel the need. For now, though, the do and do-while loops are sufficient, until I get around to doing for loops properly.

Yeah, I asked about getting rid of for loops in favor of foreach loops and range operations earlier here. The overwhelming consensus was that foreach/range was perfectly fine. It was a bit of a surprise actually. When I implemented that for Tangent it was never a problem, for what it's worth.