Anonymous user
User:Colby Russell/Composability: Difference between revisions
punctuation
(Created page with "There are two areas where there are composability concerns: * when a general purpose libpack that we link against is itself a valid triple script (we need to transform its s...") |
(punctuation) |
||
| (4 intermediate revisions by 2 users not shown) | |||
Line 1:
There are two areas
* when a general purpose libpack that we link against is itself a valid triple script (we need to transform its shunting block; maybe this should be as simple as truncating the IIFE with a semicolon—replacing the invocation parens XXX 2023 March: Replacing the parens can be a problem for roundtripping, so consider instead a scheme whereby we (a) insert the semicolon as described, and (b) insert the token <code>`inert`</code> immediately after the IIFE open paren—we need only delete those two tokens, which is "safer" than remove-and-resynthesize XXX when looking for these tokens, should the token stream be whitespace-sensitive? A: Probably; reject any inputs that don't match exactly the sort of output that the compiler produces.)
* distinct from the case of linking against an existing program for use as a lib, we want to be able to more-or-less contrive of a format that allows us to chain multiple programs together in a "pipe"
A use case for the latter: suppose program A only natively supports attaching
Line 30 ⟶ 25:
attempts to do its own chainloading internally. This is less than ideal that
the "reified pipelines" approach described above.)
----
'''2021 November 01''': Consider a third composability problem that is solved in Newspeak but not with triple script modules: we want to allow visualization of a program (say a compiler) with interactive diagrams and/or inspectors, and we opt to do this by subclassing the original components in order to constrain necessary changes to a separate "layer" that doesn't interfere in the vein of cross-cutting concerns with the original implementation. Subclassing *is* well-suited for this problem, except in one area: tight binding by name for dependency on another module.
Consider a parser and tokenizer for example, implemented by the classes `FooParser` and `FooTokenizer`. It may be the case that `FooParser` is implemented such that it is never responsible for instantiating the associated tokenizer, instead having it passed in at the constructor or later with the use of some other method, but it is also possible that `FooParser` will indeed attempt to manage its own tokenizer by importing `FooTokenizer` and instantiating it directly by name. While a subclass can easily hook implementation details of the original module (its superclass) at the method level by overriding that method and delegating to it, the language affords no easy opportunity for the surgical replacement in e.g. `VisualFooParser` of the instantiation (or use of static methods) of `FooTokenizer` from the original `FooParser`. In fact, the only way to do so would be to isolate any interaction that binds by name to a local (instance) method--don't instantiate `FooTokenizer` directly in the middle of some `FooParser` body, but instead call, say, `this._createTokenizer` which in turn does the necessary work. This is likely to be very annoying since it will result in dozens if not hundreds or thousands of stub methods that merely wrap the invocation of some other module constructor or static method...
Ideally, this would be solved at the language level a la Newspeak, but I fear the environmental constraints makes this a non-starter.
| |||