Technologicat / pydialect

Build languages on Python.
BSD 2-Clause "Simplified" License
12 stars 0 forks source link

Add dialect chaining #2

Open Technologicat opened 5 years ago

Technologicat commented 5 years ago

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 commented 3 years ago

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

Technologicat commented 3 years ago

This project is now obsolete.