CPY – Code C/C++ with no redundancy

The problem with (essentially) replacing the C/C++ syntax with a more lightweight (pythonic) one was already mentioned here in the threads: There will be a lot of corner cases which the CPY compiler does not understand.

For deduced types you can do

    auto a = 10;
    auto b = a;

For multiple return types you can do structured binding and make_tuple.

   auto [a,b] = func();

   auto func(){return std::make_tuple(1.5, 3);}

    for(auto i: irange(0,10)){

    fmt::print("{} {} {} ", a,b,c);

    # t.def
    page: t, basic_frame
        module: c

        a=10
        b=a
        $dump a, b

    $ mydef_run t.def
    PAGE: t
      --> [./t.c]
    gcc -std=c99 -O2 -o./t ./t.c  && ./t
        :a=10, b=10

MyDef is a general preprocessor, so I need the page and module declarations to tell what file and types I am generating. It always shows the command it actually runs, so there is no magic. And it does not pretend to replace C. It always produces `.c` file for debugging or merging with existing workflow.

As long as MyDef is strictly preprocessor, it is purely complementary. If you prefer straight C/C++ at places, just use straight C. If you have questions on what MyDef syntax does, just read the C output.

It does pose some restrictions on the C I write. I do not write long statements in multiple lines and rely on my editor to softwrap the lines. Long lines are difficult to read anyway with or without splitting and soft-wrapped lines are not much difficult to read anyway. I often can avoid long lines by refactoring. In rare cases that lines still end up too long, I leave it as is to remind me that it needs further work.

Sometimes I need import third-party raw c code during a progress of refactoring or code digesting. MyDef has template construct to quote them directly.

MyDef: https://github.com/hzhou/MyDef output_c: https://github.com/hzhou/output_c

I am a firm believer that the compiler should do as much work as possible, no matter the time it takes. I think the compiler ought to generate default pretty printers for structs and unions on its own, that may be overridden. Same for serialization formats and so on. The C++ compiler has more than enough information to make programmers lives more convenient at no added runtime expense, and I would be very willing to eat the compile time cost.

I wound up having to write my own preprocessor for C++ to automatically generate structure metadata for an embedded application. I wish there was more of a push for general preprocessors in this direction.

    // CPY loop to iterate from a down to b, c at a time
    for i a b -c
    
    // For comparison: pure C++11 and boost
    for(auto i : irange(a, b, -c))

Maybe I'm getting too caught up on the name, which suggests a Python-like experience, which CPY definitely not. If anything it is less like Python than C++! Sure it has the indentation vs braces thing, but that is probably one of the least important reasons why Python is so readable. A more important reason is the excellent visual cues in the syntax, and forcing you to spell things out e.g. with named parameters; "explicit is better than implicit". CPY seems to strip out visual cues, as shown above, by its four print functions that are cryptically called !, !!, ? and ??, and by the fact that it's even harder to spot function declarations in CPY than in C++.

In c++17 you can sort of do that but you still have to unpack the whole tuple (and the caller has to make one instead of simply doing ‘return a, b, c;’ to return three values. I understand why the C++ committee didn’t make this change (it would break valid programs, though there are likely few to none of them).

1. Act as a preprocessing step for any existing C++ file

2. Output perfectly servicable C++ in the case where you want to move away.

Additions like the "known" keyword make this look badly thought out.

In any case, the weakness of C++ in most cases is compilation speed, not typing speed. Even in the ideal case I can't see this adding more value than it detracts (preprocessing speed + buildsystem complication + extra dependency).

- Pure functional style (Haskell subset that is usable from C++)

- GC'd higher level gluing code (calls C++ but maybe not necessarily callable from it)

Am sure others are more qualified for suggestions, but I imagine other subsets like some for interfacing with representing relational data querying, different concurrency models (like Go, Erlang...)

Is this a sane suggestion?

I.e. nesting information is repeatedly encoded into every line. Nope, no redundancy here, move along!

I’m not sure I agree that the input is more readable, but good nonetheless.

If I had the choice, I’d move the syntax closer to Haskell do-notation than Python, but that’s just me.