Proposal: implement a macro system for YSH

[glyh]

Macros are powerful tools for writing concise yet powerful codes. For now YSH doesn't seem to have one, however.

Pros

• Having a macro system elminates the need of some other language constructs. For example, I would like ysh to have some constructs that mimics makefile, but with macros I can rock my own makefile
• Easy implementation of noncrucial language extension, e.g. if-not, destructuring, data transformation. I would like to highlight having something like specter is extremely useful in shell where transforming data is a normal task.
• Slime down the language itself so many constructs doesn't need to be hard coded to the lanugage spec itself. Furthermore, this will allow users to decide whether to use some constructs or not, which may be flexible. (e.g. Eggex, Hay, and anything noncrucial can be implemented as macros).

Cons

• Maintainence overhead
• Abusing macros yield cryptic codes. But that's rarely the case in real life
• Debugging with macros is a problem. We may need to take a look at racket's approach to see if there's any space for improvement.

Macros or Reflections

Reflection is strictly a subset of lisp-style macros. For lisp people, reflection(code as data) is just an outcome of 'homoiconicity'. But sheer reflection is not enough for writing some useful language constructs as this would require us to introduce dynamic scoping, which is scary(perf penalty, spaghetti code). A proper macro system along with reflection can actually get the work done.

Implementatoin Issues

If I remember correctly, ysh parses the code staically, so there might be some modifications on the parser's side to delegate AST construction to the macro system. I personally prefer to have macro epansion as a single layer before execution, i.e. our macro system is more like racket's than common lisp's(main difference being whether you can expand a macro in runtime or not)

Inspirations

• Elixir's metaprogramming system is a good demonstration of how macros should look like in a dynamic-typed ruby-like languge.
• TCL seems to build its entire language on string replace, and thus it's a kind of macro system. It may play especially well with shells as string is the API for unix in many scenarios.

Further information

I would like to help implementing this if the maintainer is interested. For now I think we need to collect more opinons from developers and end-users.

[glyh]

Seems to be a duplicate of reflective system.

[glyh]

Reopened as only macros can solve scoping issues. https://oilshell.zulipchat.com/#narrow/stream/384942-language-design/topic/Semaphores.3F/near/431423521

I also refined the description with some information comparing macros and reflection.