Dialect

The triple script dialect is a memory-safe language with a C-like syntax designed to facilitate non-destructive compilation and the goals of the triplescripts.org group. Its closest cousin in spirit is Go and borrows inspiration from Smalltalk. The dialect supports first-class functions, typically late-bound with the option of being tightly bound, and functions/methods are generally defined with either an Awk-ish declarative syntax, or in a terse form as a constructor for class definitions with associated methods.

The main imperative of triplescripts.org is to make the hypothetical world posed in the Build Manifesto a reality, and the triple script dialect has been designed for this reason. However, the triple script dialect is expected to be generally useful for many kinds of programs (even programs that are not strictly triple scripts themselves). On the other hand, it's not an explicit goal for this group to take such things into account in the decision-making process about the future of the triple script dialect.

There is no formal grammar at this time. The triplescripts.org reference compiler trplkt is currently pre-1.0. As we work towards standardization, it's extremely likely that the triple script dialect implemented in future compiler versions will break programs written for earlier versions while the compiler has not reached 1.0. Neither trplkt itself nor any other triplescripts.org project is guaranteed to be be free of errors that would prevent them from being broken. However, we are committed to stability after 1.0, with the option to break backwards compatibility in 2.0 (if we ever reach that point; the work of this group is expected to be low-churn once 1.0 is reached).

The triple script dialect is carefully designed such that every valid triple script (i.e. post-compilation form) is syntactically valid for any compliant ECMA-262 parser. (However, be aware that this is not JavaScript.) For the time being, the pre-compilation form for triple script modules also happens to be similarly syntactically valid, but there is no long-term commitment to maintaining this property. (Although there is such a commitment regarding the post-compilation form. Any other stance would subvert the triplescripts.org group's baseline strategy for general accessibility, which is described in The why and how of triple scripts.)

The constraints of the triple script problem space and the consequent design of the triple script dialect forbids all static initialization, including the use of singleton instances. Capabilities should be forged with the initialization of the system modules in the shunting block and passed parametrically to dependent objects.