It seems like the compiler allocates memory a lot, and is very optimistic in assuming a) the allocation will succeed and b) strings won't exceed 999 characters plus a null terminator.
Seeing how many variables are declared and used like
int *myDictLen = malloc(sizeof(int));
*myDictLen = 0;
I strongly suspect that the author is basically unaware of the & address operator. I would suggest that learning C syntax is a prerequisite to improving it.
You shouldn't new or malloc unless you need to. The more you allocate the more you leak.
Just stack/automatically allocate the resource and take the address with & then pass the pointer around. Because the data is automatically cleaned up you know you won't have any leaks (and certain whole other classes of bugs).
EDIT - Consider:
int myDictLen = 0;
int* myDictLenPtr = &myDictLen;
/* now you can pass around the pointer myDictLenPtr
to functions that can used an int* and it will be
available in this scope and automatically cleaned
up for you. */
If a function takes an argument of type pointer-to-int, you can simply pass a reference to an int variable on the stack with "&myInt". The code in question seems to be using heap allocation just to get a pointer-to-int, which makes one suspect that the author doesn't know about the & operator.
Sure you can, it just won't be "right." It depends on your use case and target audience if you care about "right" vs "functional." I'd say anyone who wants to really understand how programming works, should write at least one toy compiler/interpreter. It's interesting the kinds of insights you can pickup trying to pull that off.
Getting back to this particular case, there's something to be said for the idea of learning C before trying to replace C. C certainly isn't a flawless language, but now it's hard to have much faith that OP knows it well enough to understand its flaws.
The comma operator has more uses than that. One of them is to introduce some needed side effect in a sequence of definitions, without introducing a statement (out of esthetics, or C90 compatibility concerns):
{
int x = (side_effect(), initializing_expr());
int y = x + 42;
From C99 onward, this could be:
{
side_effect();
int x = initializing_expr();
int y = x + 2;
We use the comma operator in for loops because it has places in its syntax which take one expression. This limitation can arise in other contexts, like some macro MAC(E) where E must be a single expression. If want to to have two sequenced effects in there, we can use MAC((eff1, eff2)).
It looks like `new` instead of `malloc` and, what, `object`? But `printBox` takes object as an argument instead of binding it to `this` or `self` etc, so yeah, what's the point of this? Go, Rust and D exist, y'know.
> Let's see what we can achieve by reworking C syntax ..
Without a shred of specification, only code: I predict, absolutely not a damn thing.
If code is your specification, then every time you type "git commit" you're changing the specification.
On the plus side, your code always implements the specification 100%, at all times.
The public and private stuff is irksome. Make one of them default. Have a way to declare that all names in a region of a file are public or private so that programmers don't have to repeat themselves.
private: // default: can be omitted
void helper_function_a(foo *f) { ... }
void helper_function_b(foo *f) { ... }
public:
int api_function(...) { ... }
Looking at the examples, not sufficiently different from C to be interesting, imo. Also, go?
Edit; Adding a bit more; when I think of a C like language I'd like to have, I'd like exceptions (naive impl with setjmp longjmp for example), and Java like "everything's a pointer, all allocation on the heap". And reference counting gc. I don't think anyone else would like this :)
I generally like the language, and its compiles-to-C model. It doesn't pretend to be anything other than what it is: a GObject-specific language, not really a competitor to C++.
I seem to recall that the bindings weren't totally up-to-date though. The latest GTK outpaced the available Vala bindings.
I find the remarks a bit discouraging. It is not a bad exercise. It is quite creative as well. I had a look at nymph_compiler.c. Without using a lexer/parser generator, it is a bit hard to guarantee much about what it will be doing, or even to produce BNF specifications. But then again, I think they also abandoned bison for gcc, and started hand-coding the parser. Maybe the bison approach is also naive in its own way:
"A hand-written recursive-descent C++ parser has replaced the YACC-derived C++ parser from previous GCC releases."
"GCC switched to hand-written parsing because error messages are more meaningful when using recursive descent techniques. Also, C++ is becoming such a (syntactically) complex language to parse that using parser generators is not worthwhile for it."
It is strange, because the more complex the language, the more I would expect that they would move to lexer/parser generator tools, while it seems to be exactly the other way around.
I think what we really need is a more accessible process for proposing features for C. The difficult part will be balancing this with keeping C a small, focused language.
https://github.com/roecrew/nymph/blob/master/nymph/example/n...