Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dialect chaining #2

Open
Technologicat opened this issue Aug 1, 2019 · 2 comments
Open

Add dialect chaining #2

Technologicat opened this issue Aug 1, 2019 · 2 comments
Assignees
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@Technologicat
Copy link
Owner

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, the tco macro is aware of the let macros so that it knows to avoid TCO'ing their internal implementation details.

@Technologicat Technologicat added the enhancement New feature or request label Aug 1, 2019
@Technologicat Technologicat self-assigned this Aug 1, 2019
@Technologicat
Copy link
Owner Author

This issue is resolved in the third-generation macro expander mcpyrate, which includes a more advanced version of pydialect.

@Technologicat Technologicat added the wontfix This will not be worked on label May 2, 2021
@Technologicat
Copy link
Owner Author

This project is now obsolete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant