
Nymph: A slightly different version of C - nymph1324
https://github.com/roecrew/nymph
======
taspeotis
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.

[https://github.com/roecrew/nymph/blob/master/nymph/example/n...](https://github.com/roecrew/nymph/blob/master/nymph/example/nymph_compiler.c#L179)

~~~
user982
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.

~~~
qwertzuiop
Why is declaration wrong? I am in process of learning C, and I don't see
anything wrong.

~~~
sqeaky
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. */

------
efficax
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.

~~~
agumonkey
I'd even say Vala.

~~~
nurettin
Vala is much better with refcounting objects.

------
kazinator
> 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(...) { ... }

------
le-mark
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 :)

~~~
MaxBarraclough
No love for Vala?

~~~
le-mark
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?

~~~
MaxBarraclough
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.

------
bryanlarsen
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) ...

------
TorKlingberg
What is changed? Mostly added object-orientation? How is this different from
an early version of C++?

------
nostroso
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...](https://softwareengineering.stackexchange.com/questions/254694/why-
did-gcc-switch-from-bison-to-a-recursive-descent-parser-for-c-and-c)

"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.

------
Sir_Cmpwn
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.

------
CyberDildonics
If anyone wants to take a look at a solid attempt at a better C, take a look
at Clay.

[http://claylabs.com/clay](http://claylabs.com/clay)
[https://github.com/jckarter/clay/](https://github.com/jckarter/clay/)

------
ithilglin909
This would be more interesting if the goals section of the readme had
content...

------
dmytrish
Looks like C+.

------
laxentasken
Why?

~~~
user982
RTFA, this is clearly addressed:

    
    
      Goals
      
        ...

