You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Beside small modifications to the code, if we do this, the section in the README advising against combining dialects needs an update.
Combining arbitrary dialects automatically cannot work, but there may be orthogonal dialects, in which case it is convenient to be able to chain them without manually writing out the transformers for the combined dialect.
This obviously requires adequate warning in the documentation, because it will be the user's responsibility to make sure that the dialects being chained are in fact orthogonal. In a sense, this is no worse than e.g. implementing a custom monad in Haskell. Haskell expects, but cannot enforce, that the user-supplied implementation in fact obeys the monad laws. It's a purely social contract.
Examples of orthogonality:
Different stages
The source transformation stage comes before the AST transformation stage. Thus the result from any purely source-transforming dialect (that results in valid Python source text) can always be piped into any purely AST-transforming dialect.
Different roles
For example, a language extension and an AST optimizer. Piping the result of compiling away a language extension (resulting in a pure Python AST) into an AST optimizer makes sense.
There could be even two different optimizers, one for the extended language (to run before the extended language is compiled away), the other aimed at pure Python (to run after).
Features whose implementations don't interact
Regardless of which stage (or both) they work in.
But note that when just given two arbitrary language features, it can be highly nontrivial to decide whether they interact or not. For example, in unpythonic, the tco macro is aware of the let macros so that it knows to avoid TCO'ing their internal implementation details.
The text was updated successfully, but these errors were encountered:
To hell with it, let's support dialect chaining!
Beside small modifications to the code, if we do this, the section in the README advising against combining dialects needs an update.
Combining arbitrary dialects automatically cannot work, but there may be orthogonal dialects, in which case it is convenient to be able to chain them without manually writing out the transformers for the combined dialect.
This obviously requires adequate warning in the documentation, because it will be the user's responsibility to make sure that the dialects being chained are in fact orthogonal. In a sense, this is no worse than e.g. implementing a custom monad in Haskell. Haskell expects, but cannot enforce, that the user-supplied implementation in fact obeys the monad laws. It's a purely social contract.
Examples of orthogonality:
Different stages
The source transformation stage comes before the AST transformation stage. Thus the result from any purely source-transforming dialect (that results in valid Python source text) can always be piped into any purely AST-transforming dialect.
Different roles
For example, a language extension and an AST optimizer. Piping the result of compiling away a language extension (resulting in a pure Python AST) into an AST optimizer makes sense.
There could be even two different optimizers, one for the extended language (to run before the extended language is compiled away), the other aimed at pure Python (to run after).
Features whose implementations don't interact
Regardless of which stage (or both) they work in.
But note that when just given two arbitrary language features, it can be highly nontrivial to decide whether they interact or not. For example, in
unpythonic
, thetco
macro is aware of thelet
macros so that it knows to avoid TCO'ing their internal implementation details.The text was updated successfully, but these errors were encountered: