(→External links: link Rob Pike's 5 Rules of Programming) |
(lightly rework recent edits) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
The triple script dialect is a memory-safe language with a C-like syntax |
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 |
designed to facilitate [[non-destructive compilation]] and the goals of the |
||
triplescripts.org group. Its closest cousin in spirit is [https://golang.org Go] and borrows [[Gestalt of Smalltalk|inspiration from Smalltalk]]. The |
triplescripts.org group. Its closest cousin in spirit is [https://golang.org Go] and borrows [[Gestalt of Smalltalk|inspiration from Smalltalk]]. The |
||
dialect supports first-class functions, typically late-bound with the option |
dialect supports first-class functions, typically late-bound with the option |
||
of being tightly bound, and functions/methods are generally defined with |
of being tightly bound, and functions/methods are generally defined with |
||
either an Awk-ish declarative syntax in a terse form for class definitions. |
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 |
The main imperative of triplescripts.org is to make the hypothetical world |
||
| Line 33: | Line 33: | ||
there ''is'' such a commitment regarding the post-compilation form. Any other |
there ''is'' such a commitment regarding the post-compilation form. Any other |
||
stance would subvert the triplescripts.org group's baseline strategy for |
stance would subvert the triplescripts.org group's baseline strategy for |
||
general accessibility.) |
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 definition and use of singleton instances. Capabilities should be forged at the time of initialization of the [[system]] modules in the [[shunting block]] and passed parametrically to dependent objects. |
|||
== External links == |
== External links == |
||
* [https://triplescripts.org/dialect/ The triple script dialect in some greater detail on triplescripts.org] |
* [https://triplescripts.org/dialect/ The triple script dialect in some greater detail on triplescripts.org] |
||
* [https://users.ece.utexas.edu/~adnan/pike.html Rob Pike's 5 Rules of Programming] |
|||
Latest revision as of 13:31, 13 May 2022
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 definition and use of singleton instances. Capabilities should be forged at the time of initialization of the system modules in the shunting block and passed parametrically to dependent objects.