Metaprogramming support when defining components

[quimt]

There is a musing by Araq that tends to stick with me:

As the examples grow larger it becomes more and more visible of what a DSL that composes with the builtin Nim control flow constructs buys us. Once you have tasted this power there is no going back and languages without AST based macro system simply don't cut it anymore.

There is of course a broader idea of how we would like the DSL to compose with builtin Nim constructs. Nim supports metaprogramming, so it would be great if we could do that with the standard component declaration syntax in happyX.

So lets run down what we might want and what is supported. As we will see, some of this could be handled by the framework, and some of this might have more general utility in a variety of other projects.

Generics

Generics are the most common strategy for avoiding code duplication, so it would be awesome to be able to write something like this:

component sayHello[T]:
  toWhom: T
  `template`:
    "hello, {toWhom}!"

Templates
Doesn't currently work, but not of huge interest.

Macros
Much more flexible, but AST macros can be extra annoying to write since they require introspection on the syntax of the DSL, which is not standard Nim.

quote do: and genAst() both currently fail for basically the same reason:

macro wwPretty(): untyped =
  result = genAst():
    component pretty:
      n: int
      color: string = "pink"
      `template`:
        tSpan(style = fmt"background-color: {self.color.val}"):
          for i in 1 .. self.n.val: "*"
          "I'm pretty"
          for i in 1 .. self.n.val: "*"

This fails, even in this example where the macro has no parameters. This appears to be because quote do is a quasiquoting operator and genAst() is a drop in replacement, all that we have for macro generation are quasiquotes that try to generate the AST in advance using the immediate context of the declaration.

Full quotes that are evaluated later inside the context of the DSL don't seem to be readily available in Nim, however one can implement a more sophisticated macro with parameters using macros.toStrLit() and macros.parseExpr()

It works, but just barely, and not very flexibly. It would start to work nicer if any code block could be literally quoted before it gets parsed, using a string to represent the code seems to be the only way currently, and results in an uglier experience, for instance with syntax highlighting. Perhaps a full, pre-parsed quote of a code block would be useful to other macros that manipulate DSL code, and would be something to request of nim-lang itself?

[Ethosa]

Templates

Doesn't currently work, but not of huge interest.

What are you mean?

[quimt]

Templates that write happyX components will use backticks to create identifiers and use keywords literally, which can be off-putting to someone learning Nim in order to use the framework.

From a program design perspective, templates are macros of a certain special, simple, type. This means, for example, that they have to operate on parsed AST and the template itself has to basically look like a complete AST, which makes writing DSL invocations with the template more difficult.

Secondly, because templates are simple, they can be processed in a single pass by the compiler. Macros, which can generate AST and join together fragments of AST, generally require multiple passes of the semantic phase of the compiler. Thus there is a sense in which macros are 'run earlier' than templates. Thus as a rule of thumb, once one is doing metaprogramming on a macro-based framework, it's usually going to be smoother in terms of debugging to write new macros to pre-write the base macros.

This is also one of the reasons for the suggestion to prioritize using the least powerful construct possible; generics before templates, and templates before macros. Once one has started using a more complex and harder-to-read construct, it's harder to metaprogram it further with less complex constructs. Hence the suggestion to write most of the code in templates and let macros 'glue' them together when necessary.

[Ethosa]

@quimt

[quimt]

Looks awesome. Does this currently support all of base Nim's type-checking so that one can place components without the [string] typedesc and so that more complex sets of generic parameters like[T: int|float; A, B: someUserInput]are possible?

[Ethosa]

Hmm... Yes?

[Ethosa]

Does this currently support all of base Nim's type-checking so that one can place components without the [string] typedesc

nope yet

[Ethosa]

@quimt
Components with generics can be parents of other components:

[Ethosa]

quote do: and genAst() both currently fail for basically the same reason:

@quimt, what about add alias for ``template``, ``style`` and ``script``?

• instead of ``template`` can use html;
• instead of ``style`` and ``script`` just style and script.

[quimt]

Seems reasonable. The backtick escaping does slow down coding. It will collide with my own use of a style field in some components, but I can always change my codebase.