On 20/12/2021 16:59, James Harris wrote:
> On 20/12/2021 12:11, Bart wrote:
>> It sounds like you're thinking of a special language just for
>> declarations, which transpiles to multiple targets.
> I don't know that it would be a 'language' but preferably something much
> simpler. For example, the master file might have a couple of constants,
> one typed and one not typed.
> constant int32 LIMIT 906
> constant BLOCKSIZE 512
> That would result in assembly something like
> LIMIT dd 906
> BLOCKSIZE equ 512
> and in C something like
> int32_t LIMIT = 906;
> #define BLOCKSIZE 512
> IOW the typed one would reserve storage whereas the other would not, and
> there could be an arbitrary number of each. For C, LIMIT and BLOCKSIZE
> would likely be written into a header and after being imported could be
> used in other C code as normal.
This looks like a language to me. It's just one that consists of
declarations, or rather, non-executable code.
A bit like the kind of language I once proposed for defining APIs in a
So it's perhaps not as simple as you think. For my purposes,
declarations can include all these aspects:
* Basic types
* Aggregate types (structs, arrays)
* Pointers, strings
* Named constants of those types
* Variables of those types, including arrays and tables
* User-defined structs
* User-defined types
* In my case, 'tabledata' (enums + parallel arrays)
* Function signatures, mainly for importing/exporting across programs
and across languages
* Using previously defined user-defined structs and types for any of these
* Literals used to define consts and variables: strings (with escape
codes), integers, floats with separators and in various bases
* Macros (in my case, simple expression macros)
* Possibly, making use of 'include' (to incorporate and share such info
in other files) and 'strinclude' (string literals from a file).
* Possibly, read-only attributes (not something I do ATM)
So perhaps half a language; a univeral one translatable to any other,
including assembly. It would need a syntax and a specification.
Maybe your requirements are simpler, but when I produce a DLL, the above
is typical of what might need to be shared. At the least, function
signatures, types/structs, and enums/named constants.
If you are really talking about a configuration file, then that will be
a lot simpler - mainly keywords and values - but I can't see it needing
to be converted into actual language syntax.
>> (I found a problem with M generating DLL, so that I'm working on
>> devising my own shared library format for my own languages. I think
>> that can still be packaged within a regular DLL too, but that's low
>> priority; it will also need an external tool to generate the core DLL
> If your master info is in one of your own languages won't you end up in
> the same position as many other languages: something that has to be
> translated with no clear master? Wouldn't it be better to have some form
> which is clearly the master format for conversion to any and all languages?
I'd designate one language as the master, probably the static one as
that has a full static type system. The dynamic one has partial support
There might still need to be a process by which the master is translated
into the other language. For me, that is when the M program is compiled
to a shared library; then the necessary API file is regenerated.