(Created page with "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. (Ho...") |
(lightly rework recent edits) |
||
(11 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 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]].) |
|||
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 |
|||
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 |
|||
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 maintain this property. (Although there is such a commitment regarding the post-compilation. Any other stance would obviate triplescripts.org reason to exist.) |
|||
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 |
|||
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). |
|||
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|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. |
|||
== External links == |
|||
* [https://triplescripts.org/dialect/ The triple script dialect in some greater detail on triplescripts.org] |
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.