Introduce command that characterizes a section as a n-dot base section.

[xekoukou]

Recently, I had to dynamically include some files. This cannot be done with a single ribosome execution. We need to execute ribosome twice.

The first time, we generate the include commands. In the second, we execute the produced .dna file.

Unfortunately, to do the above, we have to put an additional dot in most of the file that is not executed in the first ribosome execution.

So, it would be nice if we added a command that specified that this section has a n-dot base. We need a way to specify the start as well as the end of that section.

[xekoukou]

For consistency, this n-base should also apply to nested embedded expressions.

With a 3 base:

....@3{b} 

is the same as

.......@6{b}

[sustrik]

The two options I can see are:

1. Add construct to "add dots" implicitly:

./!quote
...
./!unquote

1. Add construct to run ribosome in a nested way and insert the result in the place of the execute command, e.g:

.!/exec(arg1, arg2, arg3)
...
.!/endexec

What do you think?

[xekoukou]

The second option is definitely better.

[sustrik]

Have you though of doing it this way:

1. Generate only the includes: ribosome makeincludes.js.dna > includes.js.dna
2. Including the generated file into the main dna script: ./!include("includes.js.dna")

?

[xekoukou]

Yes, this is the easiest way to do it now.

But this is also a general problem. We need to not have to put so many dots at the start of each line of a .dna file if we are to use that very nice feature of generating a .dna file from a .dna file.

[sustrik]

I've been thinking about it and the problem seems to be somehow deeper IMO. Specifically, if there are multiple compilation steps, they may require different inputs, available at different times. Think of compile time vs. run time but with even more steps. For example, first compilation I may do myself. I then pass the result to the customer who does second compilation based on their data (these are not available to me, so I can't do step2 even if I wanted). I am not sure how to abstract this kind of complex behaviour...

[sustrik]

One more idea: What if we simply added a new, optional, parameter to /!include() function, an integer that would specify how many dots to add to each line of the included file?

That way the generation would still be a two step process, thus preserving separation of concerns, but, at the same time it wouldn't require the author of the included file to know anything about the context it will be used in (the "nesting level" it is included at).

[xekoukou]

I think we need to implement them all because each one has cons and pros.

a. Adding dots allows us to have multiple levels of dotness at the same file but you have to check the point that it ends, it makes things a bit confusing of you miss the end. b. the include option puts each level at a different file which is bad in my opinion because we lose the context of why we are doing this (unless the context is not required). c. the execute option is good because most of the higher levels will probably be very small, thus the endexec will be close to the exec command, making them easier to truck. But the c option has the problem you mentioned.

I would start with the first option.

./!quote(n)
...
./!unquote(n)

We can emulate b. easily with a.

./!quote(n)
./!include("path")
./!unquote(n)

[xekoukou]

Ok in order to have the effect of c(locality), without actually executing in place, we can abandon the unquote command and simply have a quote command which accepts negative numbers as well.

We add an initial quote at the beginning of the project. and then go up and down depending on what we want to do, with additional quote commands.

Imagine that we want to add a level in the future, we simply increase the initial quote of the project and we are done.