Templates all the way down

[StartAutomating]

Language definitions have proved very useful as a logical way of grouping functionality.

This provokes an interesting point about PipeScript itself, and the compilers within it.

Here it goes:

Essentially, what is a Compiler? It's something that turns source code into object code. Put another way, source code is a template for object code, and a compiler is the templating engine.

What is an interpreter? It's something that turns source code into object code and runs it. Put another way, it's a template whose results you run.

And what is it, exactly, that PipeScript really lets you do?

• It compiles the AST, step by step, and optionally runs it. Put another way, it is a set of templates for PowerShell, that you sometimes run.
• It provides a flexible templating engine that can support other languages.

So, it's Templates all the Way Down.

Now that templates have been sorted into Languages, the next logical step is to define languages for PipeScript and PowerShell itself, and use this organizing principle to reduce the complexity / increase the discoverability of PipeScript's compilers for PowerShell.

• Core Compilers should look for and become Templates #833
• New-PipeScript should use templates #834
• PipeScript should include a PowerShell language definition #835
• PipeScript should include a language definition for itself #836
• Extending Language Functions #837