Google Code Exporter
Google Code Exporter
``` Make stuff like this possible: functiontype counter : -> integer count count_from : integer start -> counter ret = lambda(count = ++start) entrypoint : { counter alpha = count_from(0)...
``` Introduce a keyword (probably "var") which indicates that a variable's type should be inferred from its initializer. var this_will_be_an_integer = 42 var this_will_be_a_real = 3.14159 var this_will_be_a_string = "test"...
``` What it says on the tin. Possible syntax could look like: multiply : integer a, integer b -> integer c = 0 { c = a * b }...
``` some form of module/namespacing support... package io //Everything in here is under the "io" package and must be referenced to as "io." read_line : //"io.read_line()" { //... } ```...
``` Consider adding different forms of type constraints; this is distinct from algebraic data types in that it is intended to affect *values* moreso than *types*. For instance, numeric ranges...
``` Design and implement language support for generators/"yield"-style functionality. Full coroutines are also a possibility. ``` Original issue reported on code.google.com by `[email protected]` on 15 Feb 2012 at 8:00
``` Threading support needs to be reimplemented, basically from scratch, using the entity model for code markup. Possible features: - Spin off a new thread with some kind of syntax/markup...
``` Decide on a means of raising and handling errors at runtime. Exceptions are on the table as a possibility but I'm not settled on that yet. This should probably...
``` Once a runtime error handling mechanism is in place, make sure library cast() overloads raise errors when casts fail. ``` Original issue reported on code.google.com by `[email protected]` on 15...
``` Currently if pattern matching fails at runtime, the VM halts immediately. A program-catchable error should be thrown instead. (This requires Epoch to have some kind of runtime error handling...