Re: [Cbor] CDDL 2.0 import and paths

[Carsten Bormann <[e-mail]>]

Hi Jeremy,

> On 2023-02-06, at 17:03, Jeremy O'Donoghue <[e-mail]> wrote:
> 
> Recursive includes are enough of a problem that generations of C programmers have learned the approach below.
>  
> #ifndef _name_of_file
> #define _name_of_file
>  
> /* definitions follow… */
>  
> #endif

Thanks for this interesting thought!

I see this C/C++ language practice less as a protection against recursion than a protection against dual incorporation of the include file text.  C/C++ are now slowly getting module systems in place, which are certainly interesting to look at.  C++ has had namespaces for a long time, which is again interesting to look at.  But let’s look at basic C.

In C, include file text is not idempotent.
It is also highly order-dependent, so sometimes you need to include early.

CDDL has idempotent rule definition, as well as order independence, except for identifying the start rule and for /= and //= (and I must admit that my implementation doesn’t pay a lot of attention to the latter, and we probably should be more explicit about the use cases where /= and //= are appropriate).

The import semantics further reduce the damage from importing something twice (which is innocuous but could greatly increase file sizes) by only filling in names that have been undefined before; you deliberately don’t get that with the include semantics.

Include semantics is what you probably want for controlled use within a project; import semantics is more useful for referencing another project from your project.

> IOW, you either need to define a module system with semantics and namespaces, or re-implement the C preprocessor.

I think the question whether the module system can be implemented in a preprocessor is quite open.  “The C preprocessor” obviously is not something we want to copy.

But I’d like to zoom in a bit more about “with semantics and namespaces” — what exactly do we need here?

Grüße, Carsten