Since Imba doesn't currently have a Macro System, I've been experimenting with the GNU M4 macro processor https://www.gnu.org/software/m4/manual/m4.pdf as well as some custom pre-processor code.
The Problem
However, the Imba parser / VS Code plugin flags macro calls as errors unless they are shadowing valid function calls or masked by multiline comment delimeters because none of the symbols involved in the macro call would otherwise be known to the language tooling.
A Possible Solution
Without having to implement a macro system, would it feasible to extend comment parsing to cover inline comments / macro placeholders?
This would be useful even in the absence of a macro expander since it would let one annotate individual function arguments and other constructs by having inline comments that didn't extend to the end of the line making it possible form them to be interspresed amid active code.
Semantics
Maybe we could use ⎡ and ⎦ for delimiters and delegate their removal from expanded output to whatever macro expansion system a user is working with or simply have the macro system wrap our macro expansions in ⎦ and ⎡ — which would provide the added benefit of using the ⎡⎦ digraph to indicate where macro-generated code appeared in the expanded imba source file.
At runtime, these inline delimeters and anything appearing between them would be ignored as comment text.
Then if an imba file contained ⎡m4_include(prelude) comment_box(Imported Graphics Libraries) ⎦ the non-imba macro invocation would not generate any errors and any typing errors would be supressed if a macro call occured in a function or control structure argument position since any errors would be pick up by the tooling in the generated replacement code post expansion.
Inline Imba For Systems Expecting Javascript Source Code Fragments
This syntax could also be mirrored by using⎣ and ⎤to delimit imba in non-imba source code files expecting line javascript source code (e.g. action blocks in peggy grammars). Imbac could recoginze such use cases if given an input file with a .imba. double file extension and output a . file after replacing its inline imba payload with its javascript expansion.
In this use case, all of the content of a file not appearing inside a⎣ and ⎤ wrapper would be regarded as comment text and passed on to the final output unmolested.
Advantages
This approach covers fine grained comments interspersed on a single line of imba, the embedding of arbitrary macro code in imba, and the use of imba to generate javascript in other DSL contexts like parser generator grammar definitions expecting inline Javascript source code.
Moreover, it suprresses pre-expansion errors that would otherwise make the imba syntax highlighter unsable with macro-augmented code while facilitating the use of external macro expanders until such time as imba gains a native macro system.
Since Imba doesn't currently have a Macro System, I've been experimenting with the GNU M4 macro processor https://www.gnu.org/software/m4/manual/m4.pdf as well as some custom pre-processor code.
The Problem
However, the Imba parser / VS Code plugin flags macro calls as errors unless they are shadowing valid function calls or masked by multiline comment delimeters because none of the symbols involved in the macro call would otherwise be known to the language tooling.
A Possible Solution
Without having to implement a macro system, would it feasible to extend comment parsing to cover inline comments / macro placeholders?
This would be useful even in the absence of a macro expander since it would let one annotate individual function arguments and other constructs by having inline comments that didn't extend to the end of the line making it possible form them to be interspresed amid active code.
Semantics
Maybe we could use ⎡ and ⎦ for delimiters and delegate their removal from expanded output to whatever macro expansion system a user is working with or simply have the macro system wrap our macro expansions in ⎦ and ⎡ — which would provide the added benefit of using the ⎡⎦ digraph to indicate where macro-generated code appeared in the expanded imba source file.
At runtime, these inline delimeters and anything appearing between them would be ignored as comment text.
Then if an imba file contained ⎡m4_include(prelude) comment_box(Imported Graphics Libraries) ⎦ the non-imba macro invocation would not generate any errors and any typing errors would be supressed if a macro call occured in a function or control structure argument position since any errors would be pick up by the tooling in the generated replacement code post expansion.
Inline Imba For Systems Expecting Javascript Source Code Fragments
This syntax could also be mirrored by using⎣ and ⎤to delimit imba in non-imba source code files expecting line javascript source code (e.g. action blocks in peggy grammars). Imbac could recoginze such use cases if given an input file with a .imba. double file extension and output a . file after replacing its inline imba payload with its javascript expansion.
In this use case, all of the content of a file not appearing inside a⎣ and ⎤ wrapper would be regarded as comment text and passed on to the final output unmolested.
Advantages
This approach covers fine grained comments interspersed on a single line of imba, the embedding of arbitrary macro code in imba, and the use of imba to generate javascript in other DSL contexts like parser generator grammar definitions expecting inline Javascript source code.
Moreover, it suprresses pre-expansion errors that would otherwise make the imba syntax highlighter unsable with macro-augmented code while facilitating the use of external macro expanders until such time as imba gains a native macro system.