No edit summary |
(reorder and revise) |
||
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|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 in a terse form for class definitions. |
|||
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 |
|||
The triple script dialect is expected to be generally useful for many kinds of programs (even programs that are not strictly triple scripts themselves), but it's not an explicit goal for this group to take such things into account in the decisionmaking process about the future of the triple script dialect. The main imperative of triplescripts.org is to make the hypothetical world posed in the [[Build Manifesto]] a reality. |
|||
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.) |
|||
== External links == |
== External links == |
Revision as of 01:27, 23 September 2020
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 [https://golang.org 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 in a terse form for class definitions.
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.)
External links
The triple script dialect in some greater detail on triplescripts.org