Nymph: A slightly different version of C

https://github.com/roecrew/nymph

by nymph1324 • 9 years ago

49 37 9 years ago

github.com

laxentasken• 9 years ago

Why?

user9822• 9 years ago

RTFA, this is clearly addressed:

  Goals
  
    ...

nymph13242• 9 years ago

It's for fun...

le-mark2• 9 years ago

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

corndoge• 9 years ago

You're right, because exclusive heap allocation would be so slow that it would defeat any advantage of using this new language over C

MaxBarraclough2• 9 years ago

No love for Vala?

le-mark2• 9 years ago

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?

luckydude• 9 years ago

I would want

    - String type that has the memory managed by the runtime
    - Some perl:  if (buf =~ /regexp/) 
    - associative arrays as a built in thing

and I have such a language, sort of, here:

http://www.little-lang.org/

TorKlingberg• 9 years ago

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

efficax• 9 years ago

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• 9 years ago

I'd even say Vala.

nurettin2• 9 years ago

Vala is much better with refcounting objects.

bryanlarsen• 9 years ago

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

taspeotis• 9 years ago

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

user9822• 9 years ago

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.

slaymaker1907• 9 years ago

To be fair, C has a bunch of weird things with its syntax like the comma separator commonly used with for loops.

qwertzuiop• 9 years ago

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

nymph13242• 9 years ago

I am aware of that actually....

revelation• 9 years ago

Oh my god, what is that. I guess the .xcodeproj was a bad sign after all.

Sir_Cmpwn• 9 years ago

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.

dmytrish• 9 years ago

Looks like C+.

ithilglin909• 9 years ago

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

kazinator2• 9 years ago

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

CyberDildonics2• 9 years ago

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/

nostroso• 9 years ago

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.

Nymph: A slightly different version of C

Related Stories