For the last few years, I've been hacking (on and off) on a programming language project called Epoch. Epoch began right here on GDNet as an experiment in designing a forward-thinking language for rich abstraction and powerful computational modeling. Despite the fact that I have had far less time to dedicate to this project than I would like, progress has been steady (albeit slow!) and Release 12 of the language is now available.

• Release Notes
  
• Complete source code (VS2010 format)
  
• Windows runtime binaries
  

Epoch still has a ways to go before it is truly production-ready, but even now, the language is reasonably capable and can be used for simple Win32 applications with no problems. (This is underscored by the Era prototype IDE for the language, which is written in Epoch, and included in the distribution.)

For the curious, here's a simple Epoch program:

fib : 0 -> 1
fib : 1 -> 1
fib : integer n -> integer f = fib(n - 1) + fib(n - 2)

deep_thought : -> integer answer = 0
{
integer a = fib(5)
integer b = fib(8)
answer = a + b
}

entrypoint :
{
integer the_answer = deep_thought()
print(the_answer)
}


I'm very interested in community feedback on all aspects of the language.

• How does the syntax strike you?
  
• Does the language seem interesting? As a theoretical project? As it currently exists?
  
• Would you find the concepts behind Epoch to be useful for your work?
  
• What kinds of things would you like to see in a language like this?
  
• What would motivate you to try it out?
  

Despite its age, Epoch is still a relatively young and malleable project. I hope to be able to turn it into a truly great language, and I appreciate the community's part in helping make that happen.

"How does the syntax strike you?"

It looks like some kind of functional language? (I didn't use any that kind of language before).
I'm confused by its typing. Is it strong typing, or weak typing, or hybrid?
fib:0 -> 1, no type? For other part, with strong type integer?

"What would motivate you to try it out?"

1, Giant commercial companies are using it.
and 2, Community support
and 3, Some successful productions are written in it.

Epoch is a procedural language at heart, but it does draw a lot of inspiration from functional languages. I plan to support pure functional programming as an optional subset of the language, with compile-time enforcement of immutability (or contained mutability) and other features familiar to functional programmers.

The type system is strong and static; all types are known at compile time, and types never change unless explicitly casted. However, type annotation is optional in many contexts, because Epoch provides a type inference engine to deduce the types of most expressions in the language.

How does the pattern matching (if that's what's being done) work in the fib example above?

Calls to fib() with an argument of 0 match the first pattern, and return 1; similarly with calls with an argument of 1. This can be determined in some cases statically at compile time, in which case the calls are directly made to the appropriate overload; other cases must be detected at runtime, which will first check for the correct overload to resolve to, and then try the default case overload if none of the special cases match. This provides a basic recursive pattern match with a valid base case for termination.

Does it compile as equality checks or is there some fancy symbol compare going on under the hood?

Pattern matching on primitive types is equality-based, yes. I haven't settled on a mechanism for type-decomposition in pattern matching largely because I haven't settled on a lot of details of the type system yet :-)

Note: I haven't had time to examine the code, or deeply examine the website, so apologies if any of these questions are too obvious. Nor am I particularly trying to be nit-picky, I'm sure you're aware of some of these.

How does the syntax strike you?
[/quote]
I like the idea, but there does seem to be heavy historical precedent that programmers like a certain syntax. The following thoughts struck me:

Is assume it is currently not possible to omit the "variable name" of the return value. It would be nicer to be able to write:

fib : integer n -> integer = fib(n - 1) + fib(n - 2)


Is there some syntactic (or other) restriction that prevented you from writing deep_thought like so?

deep_thought : -> integer answer = fib(5) + fib(8)

Perhaps you wrote it long hand just to show more examples of complex functions.

It also appears that you are forced to declare (and initialise) the "result" variable, which forces it to be in scope for the entire function, which might cause bugs where it is unintentionally used in the function body (for example, having the "return" variable named something like "i"). Have you considered a visual basic style "assign to the function name to set the return value"?

Is it possible to early return from a function? Maybe you have a list of example programs or the syntax somewhere on the site, but I didn't find it.

The syntax for a parameterless function is a little poor, the colon followed by arrow do not look great together.

Anonymous returns are possible; they look like this:

add : integer a, integer b -> a + b

The reason that an anonymous return cannot be used in the fib example is because the type inference engine cannot determine that all possible values given to fib() will recurse down to the base case, and therefore cannot infer that the return type of the general case overload is integer, even though the two base case overloads are integer return type.

deep_thought was written longhand just to show how it could be done; there is no reason why it couldn't be:

deep_thought : -> fib(5) + fib(8)


Variable name shadowing is prohibited in Epoch so there is (IMO) no real risk of accidentally using the return value variable as something else in the function body. I personally don't like the FunctionName=returnvalue syntax, but that's just me; I'm not opposed to changing it if a substantial majority of people find it clearer.


Early returns can be accomplished using the built-in return() statement.

I always feel bad for not commenting more, though I don't have much to say...

How does the syntax strike you?

It's fine. I dislike using simply lines as delimiters, and I kinda dislike the current return value form but understand it. It's syntax... *shrug*

Does the language seem interesting? As a theoretical project? As it currently exists?
[/quote]

It was a lot more interesting when the focus was auto-parallelization and targetting GPUs and the such. That served as a strong differentiator (for me) as to 'what does Epoch provide that I can't nicely get with ____'.

Would you find the concepts behind Epoch to be useful for your work?
[/quote]

Not really, but I also don't have a lot of experience with GPU processing and I would be hesitant to have a developing language be my first entry there.

What kinds of things would you like to see in a language like this?
[/quote]

I like seeing progress, even if it makes me sad at the lack of my own. I like seeing differentiation. Lots of languages can do the basic things in a cute manner. What hard things can it do for me?

What would motivate you to try it out?
[/quote]

Tons more free time and motivation. And if I had a problem that it was well suited for enough for me to learn it and risk the cutting edge concerns.