What is .tmpl file?

[ghost]

CudaText said it's HTML Handlebars but it seems it's something kind of quake code. This code looks like Lua. It feels like more a real programming language than cmake's language. What I wonder is if quake a build system like he said on https://github.com/modula3/cm3/issues/1070 why we need "Quake functions to instantiate operations on generic matrices." like it said on the beginning of the file? So is it somekind of preprocessor like Qt's MOC? It's getting complicated now. GNU Modula 2 is more simpler and straight forward than this.

[mikanystrom]

.tmpl files contain Quake code, yes.

.tmpl files are also entirely optional. They are (at least usually) used to extend the Quake language so that you can make shorthand instantiations of generics. You can still use the long-form generic instantiations without .tmpl.

Part of the issue here is that while the semantics of generics are defined in Modula-3 (and are quite simple), the way to indicate to the compiler which generics to build, with what parameters, and what to call the results, is not part of Modula-3, but is part of the build system (i.e., Quake for almost all Modula-3 implementations.)

On Fri, Sep 9, 2022 at 4:07 PM pwd96m4a @.***> wrote:

CudaText said it's HTML Handlebars but it seems it's something kind of quake code. This code looks like Lua. It feels like more a real programming language than cmake's language. What I wonder is if quake a build system like he said on #1070 https://github.com/modula3/cm3/issues/1070 why we need "Quake functions to instantiate operations on generic matrices." like it said on the beginning of the file? So is it somekind of preprocessor like Qt's MOC? It's getting complicated now. GNU Modula 2 is more simpler and straight forward than this.

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1074, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKYNJLM5F5US3BBTBHOTH3V5O7MDANCNFSM6AAAAAAQJCG3BU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jpgpng]

They are (at least usually) used to extend the Quake language so that you can make shorthand instantiations of generics. You can still use the long-form generic instantiations without .tmpl. Part of the issue here is that while the semantics of generics are defined in Modula-3 (and are quite simple), the way to indicate to the compiler which generics to build, with what parameters, and what to call the results, is not part of Modula-3, but is part of the build system (i.e., Quake for almost all Modula-3 implementations.)

Could you clarify it more. At least give an example pls. I found it vague.

[mikanystrom]

Sure, consider

https://github.com/modula3/cm3/tree/master/m3-libs/libm3/src/table

Here you have some generics for making hash tables:

GENERIC INTERFACE Table(Key, Value); (* Where "Key.T" and "Value.T" are types that... To use this interface, you have to instantiate it.

Suppose now you have two interfaces MyKey and MyValue that define types MyKey.T and MyValue.T that follow all the rules in the generic, and you want to use these to make a hash table keyed on MyKey.Ts, holding MyValue.Ts.

Your first approach would be to instantiate the generic directly. You can simply make a .i3 and a .m3 as follows:

INTERFACE MyKeyValueTbl = Table(MyKey, MyValue) END MyKeyValueTbl. MODULE MyKeyValueTbl = Table(MyKey, MyValue) END MyKeyValueTbl.

include these in your m3makefile as usual:

module("MyKeyValueTbl")

And you don't need any more than that.

But cm3/quake has convenience functions to make this a bit less cumbersome.

In your m3makefile you might write

build_generic_intf (MyKeyValueTbl, "Table", [MyKey, MyValue], HIDDEN) build_generic_impl (MyKeyValueTbl, "Table", [MyKey, MyValue])

which will make a HIDDEN (package-private / opposite is VISIBLE) interface MyKeyValueTbl and an implementation MyKeyValueTbl, which you can actually see in your derived directory when you build. And then you don't need to instantiate the generics yourself.

Of course this isn't all that useful since it's still wordy and a bit cumbersome. So now the library designer defines a few convenience functions ...

readonly proc table (nm, key, value) is local tab = nm & "Tbl" build_generic_intf (tab, "Table", [key, value], HIDDEN) build_generic_impl (tab, "Table", [key, value]) end

and now all you have to write in your m3makefile

table("MyKeyValue", "MyKey", "MyValue")

The definition of "table" (and its VISIBLE counterpart, Table) is what is in table.tmpl, see

https://github.com/modula3/cm3/blob/master/m3-libs/libm3/src/table/table.tmpl

Nothing more than that.

Less wordy example:

https://github.com/modula3/cm3/blob/master/caltech-other/mst/src/mst.tmpl

Mika

On Sat, Sep 10, 2022 at 2:12 AM jpgpng @.***> wrote:

They are (at least usually) used to extend the Quake language so that you can make shorthand instantiations of generics. You can still use the long-form generic instantiations without .tmpl. Part of the issue here is that while the semantics of generics are defined in Modula-3 (and are quite simple), the way to indicate to the compiler which generics to build, with what parameters, and what to call the results, is not part of Modula-3, but is part of the build system (i.e., Quake for almost all Modula-3 implementations.)

Could you clarify it more. At least give an example pls. I found it vague.

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1074#issuecomment-1242677033, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKYNJI4T6FX7CJXMETHT7LV5RGJHANCNFSM6AAAAAAQJCG3BU . You are receiving this because you commented.Message ID: @.***>