Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: cHaR <cHaR-shinigami@outlook.com>
Newsgroups: comp.lang.c
Subject: Introducing the C_ Dialect
Date: Sat, 1 Mar 2025 03:07:55 +0530
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <vptabl$3rjjp$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 28 Feb 2025 22:37:58 +0100 (CET)
Injection-Info: dont-email.me; posting-host="45186cde5876bb4b0f119bde71ea97eb";
	logging-data="4050553"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EzYn2xggunXitiA5oip7O"
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
Cancel-Lock: sha1:4IciF1KztfAKcQUqYrgdShG9ePA=
Content-Language: en-US
X-Mozilla-News-Host: news://news.eternal-september.org:119
Bytes: 5514

I started working on a preprocessing-based dialect of C a couple of 
years ago for use in personal projects, and now that its documentation 
is complete, I am pleased to share the reference implementation with 
fellow programmers.

https://github.com/cHaR-shinigami/c_

The entire implementation rests on the C preprocessor, and the ellipsis 
framework is its metaprogramming cornerstone, which can perform any kind 
form of mathematical and logical computation with function composition. 
A new higher-order function named "omni" is introduced, which provides a 
generalized syntax for operating with arrays and scalars; for example:

`op_(&arr0, +, &arr1)` adds elements at same indices in arr0 and arr1
`op_(&arr, *, 10)` scales each element of arr by 10
`op_(sum, +, &arr)` adds all elements of arr to sum
`op_(price, -, discount)` is simply price - discount

The exact semantics are a tad detailed, and can be found in chapters 4 
and 5 of the documentation.

C_ establishes quite a few naming conventions: for example, type 
synonyms are named with a leading uppercase letter, the notable aspect 
being that they are non-modifiable by default; adding a trailing 
underscore makes them modifiable. Thus an Int cannot be modified after 
initialization, but an Int_ can be.

The same convention is also followed for pointers: `Ptr (Char_) ptr` 
means `ptr` cannot be modified but `*ptr` (type Char_) can be, whereas 
`Ptr_(Char) ptr_` means something else: `ptr_` can be modified but 
`*ptr_` (type Char) cannot be. `Ptr (Int [10]) p1, p2` says both are 
non-modifiable pointers to non-modifiable array of 10 integers; this 
conveys intent more clearly than the conventional `const int (* const 
p1)[10], p2` which ends up declaring something else: `p2` is not a 
pointer, but a plain non-modifiable int.

C_ blends several ideas from object-oriented paradigms and functional 
programming to facilitate abstraction-oriented designs with protocols, 
procedures, classes and interfaces, which are explored from chapter 6. 
For algorithm enthusiasts, I have also presented my designs on two 
new(?) sorting strategies in the same chapter: "hourglass sort" uses 
twin heaps with quick sort, and "burrow sort" uses a quasi-inplace merge 
strategy. For the preprocessor sorting, I have used a custom-made 
variant of adaptive bubble sort.

The sample examples have been tested with gcc-14 and clang-19 on a 
32-bit variant of Ubuntu having glibc 2.39; setting the path for header 
files is shown in the README file, and other options are discussed in 
the documentation. I should mention that due to the massive (read as 
obsessive) use of preprocessing by yours truly, the transpilation to C 
programs is slow enough to rival the speed of a tortoise. This is 
currently a major bottleneck without an easy solution.

Midway through the development, I set an ambitious goal of achieving 
full-conformance with the C23 standard (back then in its draft stage), 
and several features have evolved through a long cycle of changes to fix 
language-lawyer(-esque) corner-cases that most programmers never worry 
about. While the reference implementation may not have touched the 
finish line of that goal, it is close enough, and at the very least, I 
believe that the ellipsis framework fully conforms to C99 rules of the 
preprocessor (if not, then it is probably a bug).

The documentation has been prepared in LaTeX and its generated PDF (with 
300-ish pages of content) can be downloaded from
https://github.com/cHaR-shinigami/c_/blob/main/c_.pdf

I tried to maintain a formal style of writing throughout the document, 
and as an unintended byproduct, some of the wording may seem overly 
standardese. I am not sure if being a non-native English speaker was an 
issue here, but I am certain that the writing can be made more 
beginner-friendly in future revisions without loss of technical rigor.

While it took a considerably longer time than I had anticipated, the 
code is still not quite polished yet, and the dialect has not matured 
enough to suggest that it will "wear well with experience". However, I 
do hope that at least some parts of it can serve a greater purpose for 
other programmers to building something better. Always welcome to bug 
reports on the reference implementation, documentation typos, and 
general suggestions on improving the dialect to widen its scope of 
application.

Regards,
cHaR