RFC: Epoch Programming Language, Release 8

I've been silently following this, and I'd like to pop in and throw a bucket of support at you. Interesting and inspiring project; I'll definitely have a look at this new release in a jiffy.

I see that you're using a custom compiler backend. Wouldn't it be better to use an existing one (LLVM springs to mind)?

Quote:

Original post by Heptagonal I've been silently following this, and I'd like to pop in and throw a bucket of support at you. Interesting and inspiring project; I'll definitely have a look at this new release in a jiffy.

Thanks! It's hard to know sometimes if anyone is paying attention.

Quote:

Original post by Konfusius I see that you're using a custom compiler backend. Wouldn't it be better to use an existing one (LLVM springs to mind)?

I need an FAQ for this [smile] The general reasoning behind my approach is spelled out here.

I've been thinking about this project since I read your first thread about the idea. I'm looking forward to trying it, but are there any plans for Mac OS X support in the near future (I do most of my coding on a Mac and have for some years now)?
Also, did you ever post anything on Lambda the Ultimate about this project? They might give some good feedback.

I've been laying about with the latest Epoch release a little I've found some problems, so here's that feedback you were asking for.

The sample programs don't function properly. The guessing game, which I'm quite positive I've managed to get working in release 7, throws an error at runtime about an illegal cast. The scribble project doesn't even build, giving me two inexplicable compile errors, and I had to move the project to the "Tools" folder because Exegen couldn't find the source files in a remote directory.

When programs do run they appear to do nothing. A trivial example such as the one below, while building without errors, produces no output when run from the command line.

Am I missing something here?

Quote:

Original post by Roboguy I've been thinking about this project since I read your first thread about the idea. I'm looking forward to trying it, but are there any plans for Mac OS X support in the near future (I do most of my coding on a Mac and have for some years now)? Also, did you ever post anything on Lambda the Ultimate about this project? They might give some good feedback.

I don't have access to a development Mac, so sadly for now we're a Windows-only operation. I do accept donated hardware/software/cash, though... [wink]

I haven't been through the LtU gauntlet yet, no. I'm holding off on that until I finish the design and implementation of some of the more useful features of the language; right now it's still pretty primitive and wouldn't really arouse much interest over at LtU. Once the object model is in place though I will definitely be throwing it that direction for review.

Quote:

Original post by Heptagonal I've been laying about with the latest Epoch release a little I've found some problems, so here's that feedback you were asking for. The sample programs don't function properly. The guessing game, which I'm quite positive I've managed to get working in release 7, throws an error at runtime about an illegal cast. The scribble project doesn't even build, giving me two inexplicable compile errors, and I had to move the project to the "Tools" folder because Exegen couldn't find the source files in a remote directory. When programs do run they appear to do nothing. A trivial example such as the one below, while building without errors, produces no output when run from the command line. *** Source Snippet Removed *** Am I missing something here?

Can you run me through the command line ops you're doing? I'm having problems recreating the issues (although you are correct that Scribble is, yet again, broken; I could have sworn I had it building before I packaged the release, but oh well).

I really do need a quick "how to use this mess" guide included in the release kit... [grin]

Here's the log from the command line window:

C:\Users\Martin\Desktop\Epoch Release 8\Tools>exegen /makeexe guessinggame.epoch guessinggame.exeEXEGEN - Epoch development toolkit[Plenty of stuff saying that the program has been built successfully]C:\Users\Martin\Desktop\Epoch Release 8\Tools>guessinggameC:\Users\Martin\Desktop\Epoch Release 8\Tools>

This error is given when running the guessing game:

Epoch Subsystem---------------------------Failed to cast value; possible causes are overflow or malformed data

Ah, thanks - that's quite helpful! I tracked the problem down to a mistake in the implementation of the console attachment routines.

For the curious, essentially what happens is the stdin handle does not bind correctly, so any attempt to read from the console input results in an error. It just so happens that in this case the error propagates through the exception handlers and ends up reporting (more or less erroneously) that an invalid data cast was attempted.


Also, one thing I failed to note properly - when building console-reliant programs with /makeexe, you'll need to specify the /console switch as well, in order to have the program attach to the console during startup. Otherwise you will get a running, valid EXE that doesn't actually show any output. I will modify this so that either a /console or /noconsole switch is required with /makeexe so that it can't be accidentally overlooked.


My plan at the moment is to take care of some of these usability issues, then re-release R8 with the improvements in place.

OK... fixes and improvements are all in place and have been deployed. For the whopping four of you that have downloaded the release, please download it again from here to get the fixes.

I'll also put in some time to improve the "getting started" wiki article, so that hopefully things will be much smoother for newcomers to the project [smile]

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.