Commit 8752def6 authored by Adrian Cochrane's avatar Adrian Cochrane

Note complexity of custom parsers.

parent 0c8f14c7
Basing this standard on Functional Programming minimizes the number of bytecodes that would need to be interpreted to the bare minimum needed for Turing Completeness. Whilst giving it more opportunity for optimizations. Though they may override standard library functions to expose additional machine codes, e.g. arithematic. This approach gaurantees strong backwards compatibility by way of built-in polyfills.
Supporting third-party parsers would involve little more work than reusing that interpretor. In turn it would allow the built-in parser to be simpler and for interactives to incorporate the same images, fonts, sounds, etc a webpage would. Font support is especially needed in order to support text rendering, and with that clients aren't required to implement it.
Performing I/O exclusively via function arguments and return values strengthens the boundaries of the sandbox, and using FRP minimizes the impact it has on the interpretor. As for the ease of implementing this I/O all depends on the window manager being targetted, though it would be natural to base the standard upon Wayland as that would naturally translate to FRP.
I leave out of scope any sort of high-level API for building a UI, though low level drawing APIs would be part of the I/O. Arguably this is shifting complexity around rather than removing it all together, but it does mean interactives don't need to pay for the complexity they don't require.
Overall I'd consider this spec trivial to implement, depending on how much optimize.
\ No newline at end of file
Overall I'd consider this spec as easy to implement, depending on how much optimize.
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment