aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-04-15Abstract stack prependingAdrian Kummerlaender
2017-04-15Perform custom word definition at the same level as conditional primitivesAdrian Kummerlaender
2017-04-15Add README.md, exampleAdrian Kummerlaender
2017-04-14Convert structure to _dub_ build systemAdrian Kummerlaender
2017-04-14Simplify token handling in the context of word definitionsAdrian Kummerlaender
2017-04-14Clean up core processing loopAdrian Kummerlaender
2017-04-13Implement deferred word, conditional resolutionAdrian Kummerlaender
Due to the non-trivial way tokens were previously processed the compiler could not safely perform tail-call elimination. Thus the _slang_ evaluation depth was restricted by the maximum call stack size. This issue is mitigated by introducing deferred word resolution - i.e. pushing expanded tokens onto a buffer stack and processing them in an explicit loop. This change ties into the implementation of the language's conditional primitive. The previous implementation did implicitly not support direct nesting of conditional expressions such as: truthA if mainBranch truthB if secondaryMainBranch then else then alternativeBranch else This issue is now made explicit by disallowing direct nesting of conditionals as depicted above. Appropriate exceptions are generated when required and the conditional primitive is reimplemented in a more robust fashion under the assumption that this rule holds. Note that nesting is still fully supported iff. the nested conditional is contained in a deferredly evaluated word. As a positive side effect this will make it slightly harder to generate unreadable code by forcing developers to write simpler words. The main change of the conditional primitive lies in deferring branch token processing until the conditional expression is concluded by `else`. This is achieved by capturing non-dropped tokens in an internal buffer akin to how the word definition operator `ยง` is implemented. The branch buffer is discharged after `else` is evaluated. Discharging is triggered via the newly introduced `result` method of the primitive evaluation module. This avenue for injecting tokens into the processing stream may be used by further primitives in the future.
2017-04-13Rename conditional primitive implementation to fit overall naming schemeAdrian Kummerlaender
2017-04-12Introduce native boolean typeAdrian Kummerlaender
2017-04-12Expand conditional primitive to choose between `then` and `else` branchAdrian Kummerlaender
i.e. `1 if true then false else` evaluates to `true`, `0 if true then false else` evaluates to `false`.
2017-04-12Implement integer comparsion primitivesAdrian Kummerlaender
2017-04-12Modularize primitives implementation, add stack manipulatorsAdrian Kummerlaender
2017-04-12Implementent conditional primitiveAdrian Kummerlaender
2017-04-12Modularize implementationAdrian Kummerlaender
2017-04-12Catch undefined division, modulo operationsAdrian Kummerlaender
2017-04-12Implement basic empty stack handling, div, modAdrian Kummerlaender
2017-04-12Implement support for variables, mixed types in data stackAdrian Kummerlaender
2017-04-11Play around with contractual programmingAdrian Kummerlaender
2017-04-11Simplify word definition, evaluationAdrian Kummerlaender
2017-04-10Rewrite in D, support for word definitionsAdrian Kummerlaender
2017-03-31Implement primitives as lambda expressions in an unordered setAdrian Kummerlaender
2017-03-30Implement swap, duplicate and delete wordsAdrian Kummerlaender
2017-03-30Minimal stack calculator REPL implementationAdrian Kummerlaender