> You are doing "interesting" things.
> 
> First, I can not remember having seen nested templates at all in Nim, at 
> least I never used that construct.
> 
> And putting a include inside a template is also "interesting".

My goal is to produce precise error message to the user of templates. One way 
I'm exploring is to control [when a template can be 
used](https://forum.nim-lang.org/t/6249). I'll explain here what I was trying 
to do...

**mymodule.nim**
    
    
    template foo*(...) =
      # Visible and usable externaly
    
    template bar*(...) =
      # How to control that bar can be used externaly by a client
      # only in the context of foo?
    
    
    Run

I want to prevent a consumer of `mymodule` use `bar` and get an error message 
like `Syntax error: ctx variable not defined`. This client must not know that 
`ctx` has been injected by `foo`. So using englobing template defines context 
when a template can be used: `bar` is not usable outside of a `foo` block.

But writing multi-levels tens of nested templates inside a big one is not that 
easy, and I turned to `include` for code management. The tricky part is that 
templates don't define scope as they are just code replacement and that's where 
`include` don't play well with visibility rules...

**mymodule.nim**
    
    
    type
      A = object
        # A custom object that is used by bar
    
    template foo*(...) =
      # Visible and usable externaly
      block:
        template bar(...) =
          # Now bar can be used only within foo.
    
    
    Run

In the code snippet above, if `bar` uses special types, like `A`, it would be 
simpler if `bar` is stored in another file to be included, that `A` definition 
goes into the same file too. And as everything was inside a `block:`, I thought 
that it declared somewhat a new scope where I can have type declarations. Well, 
I was wrong because of template hygiene...

This is becoming tricky as I mix visibility rules for consumers (`*` sufix), 
scope of objects/templates/macros, and code management.

Thanks @Hlaaftana and @gemath, this makes a lot of sense. For the moment, I 
reverted back all the pieces of code in a single file. It will be easier to 
debug. I'll try to break it again in pieces when it is debugged.

Reply via email to