Future goals and ideas

[dumblob]

Any plans to make the "structural" constructs (if, times, macro, ...) "complete" as follows?

1. allow to nest them arbitrarily without side effects
2. in case of times it's not only about i, but also about missing break (to simulate infinite loop or a while loop)
3. in case of macro it's about "hygiene" - i.e. any variable from the argument list shall be automatically "shadowed" in case of (both direct & indirect) recursion (now variables seem to be overwritten instead of always shadowed)
4. allow passing a macro to a macro without first expanding it (and implement also support for explicit expansion)

Ad 4: Maybe instead of:

````
macro m1 m2 begin ... m2 ... endmacro
macro m2 begin ... endmacro
m1 m2
````

just write:

````
macro m1 ( m2 ) begin ... expand m2 ... endmacro  # parenthesis in argument list are significant and denote the level of "quoting"; the "expand" command will try to strip one level of quoting and if none to be stripped, just expand it instead
macro m2 begin ... endmacro
m1 m2
````

I'm aware the point (3) goes against the "variables are global" mantra, but it'd make macros so much more useful and with that whole t2b.

[thosakwe]

Hi, I've actually been thinking about creating a version 2.0 of t2b. The initial version was more or less the results of 1 day of hacking, so some choices were made in the name of simply completing the project.

There are lots of things I would ideally like to improve in a future version, but I'm starting to think that such an effort would be similar to making an interpreter for an actual programming language, so I'm not sure when I would be able to get around to it.

Even as far as just fixing small bugs/nits in the existing implementation, I'm not sure when I would have a chance to, since I have limited time these days.

[dumblob]

That's great news. Keep me/us posted with what you envision.

but I'm starting to think that such an effort would be similar to making an interpreter for an actual programming language

It already is. But if the command set will stay similarly small and simple as the current command set, most of other things can users do using macros later in the future (actually many of the current commands can also be macros assuming the quoting/unquoting will be available). So don't think about the language itself as a big thing 😉.

Btw. I like t2b because I totally love to think about things in terms of expected outcomes (i.e. top-down approach). And because t2b can "only" spit out something it makes my thinking clearer. That's why I proposed the points above, because t2b as it stands became too limiting for me.

Even as far as just fixing small bugs/nits in the existing implementation, I'm not sure when I would have a chance to, since I have limited time these days.

Take your time. I'm also overly busy, so I can imagine what you mean.

[thosakwe]

Update - I'm highly considering picking this back up. Probably will use ANTLR4 to build a new parser; I have used it a lot, and think the added dependency is worth it.

The new language will have a handful of data types:

• string - UTF-32 string. Defines operator +.
• number - 64-bit floating point.
• dict - Map from string to value.
• bool - Boolean.
• vector - Growable vector
• void - Nothing.
• function - Top-level function or closure.

Existing functions, like strl and u8, will remain. The macro keyword will deprecated, since there'll be actual functions.

At the same time, compatibility is important, so I will aim to keep the syntax backwards-compatible. Certain things will be deprecated, like get and set, as well as hex mode.

There will be a --compat flag, to disable deprecation warnings. In addition, I'll add a -o flag. Lastly, I am considering supporting an import syntax.

Example:

let messages = ["Hello, world!", "This is t2b version 2.", "Enjoy!"]
for message in messages do
  log (format "Printing % as UTF-8" message)
  writeln (utf8 message)
endfor

[dumblob]

Ah, ok. I was mainly interested in the macro functionality as that's a more generic approach allowing better "interleaving" between the code which is being generated and the t2b lang code itself. Having macros was the main selling point for me 😉.

But I'm curious anyway what will come out of this effort as it might still be close to what I'd imagine. So don't let yourself be sidetracked by my rants.

[sab24]

Actually many of the features described here are already implemented in flat assembler, fasmg has a powerful macro syntax and other features to create binary files. Not only executables but also many others. It might be interesting to have a look.

[thosakwe]

Going back to the issue of scope creep - if fasm has these advanced features, then it might not be worth adding them to t2b.

[dumblob]

@sab24 thanks for the reference. It seems fasmg is actually closer to what I envisioned.

@thosakwe I think I'll take a look at fasmg - therefore I think you shouldn't pay any attention to my needs as of now. So feel free to not add any such features to t2b (at least for now 😉).

[hlorenzi]

If I may be so bold, I've got the customasm app, which has a similar feature set -- I'm always looking forward to sharing ideas!