Nymph: A slightly different version of C(github.com)
github.com
Nymph: A slightly different version of C
https://github.com/roecrew/nymph
39 comments
Oh my god, what is that. I guess the .xcodeproj was a bad sign after all.
Seeing how many variables are declared and used like
int *myDictLen = malloc(sizeof(int));
*myDictLen = 0;
Why is declaration wrong? I am in process of learning C, and I don't see anything wrong.
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:
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.
There is nothing wrong with the syntax itself. Its simply that it's usually preferable to allocate variables on the stack. To do this, you would do:
int var_a = 5;
and use &var_a when you want to acess that variable as a pointer within that scope. Not only is this more efficient, it is much easier to read.
int var_a = 5;
and use &var_a when you want to acess that variable as a pointer within that scope. Not only is this more efficient, it is much easier to read.
I am aware of that actually....
Are you aware that malloc() is slow and doing all these tiny allocations is probably the biggest bottleneck in your program?
To be fair, C has a bunch of weird things with its syntax like the comma separator commonly used with for loops.
You can't really write a compiler if you don't know all the "weird things" of the language.
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.
Is this intended to replace C? I don't see anything that suggests that's what this project is about.
All I see is "C with different syntax". That could easily be a challenging side project whilst learning compilers / language design.
I've always found changing things up a useful means of practice. I wanted to learn how HTTP servers worked. I wanted to learn more Lisp. I implemented it in Common Lisp. I learned a lot.
All I see is "C with different syntax". That could easily be a challenging side project whilst learning compilers / language design.
I've always found changing things up a useful means of practice. I wanted to learn how HTTP servers worked. I wanted to learn more Lisp. I implemented it in Common Lisp. I learned a lot.
As a point of reference, implementing a broken, partially complete, and definitely error filled version of Scheme on C is how I finally wrapped my head around Lisp. I'd been running into that one for a long time before figuring out.
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;
{
side_effect();
int x = initializing_expr();
int y = x + 2;
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.
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 :)
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 would want
http://www.little-lang.org/
- String type that has the memory managed by the runtime
- Some perl: if (buf =~ /regexp/)
- associative arrays as a built in thing
http://www.little-lang.org/
No love for Vala?
No, I really admire vala, my understanding it's kind of dead ie won't migrate to future versions of gtk. What's your take on it?
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 seem to recall that the bindings weren't totally up-to-date though. The latest GTK outpaced the available Vala bindings.
My take on Vala is Lazarus. (Won't really miss refcounting once you get used to create/try/finally pattern)
You're right, because exclusive heap allocation would be so slow that it would defeat any advantage of using this new language over C
These sort of announcements should include language similar to Linux's:
I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) ...
I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) ...
What is changed? Mostly added object-orientation? How is this different from an early version of C++?
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:
https://softwareengineering.stackexchange.com/questions/2546...
"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.
https://softwareengineering.stackexchange.com/questions/2546...
"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.
If anyone wants to take a look at a solid attempt at a better C, take a look at Clay.
http://claylabs.com/clay https://github.com/jckarter/clay/
http://claylabs.com/clay https://github.com/jckarter/clay/
[deleted]
This would be more interesting if the goals section of the readme had content...
Looks like C+.
https://github.com/roecrew/nymph/blob/master/nymph/example/n...