Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nimrod: C + Macros + GC

nimrod-code.org

Post reply on HN
Print view View original

91–100 of 116 posts

Re: Nimrod: C + Macros + GC

#91

Post by ANTSANTS »

bjz_ wrote: post #84
xaa wrote: post #74

Earlier quoted context omitted.

In Nimrod, when you are declaring a variable with an explicit type, the syntax is: var x, y: int as opposed to the more concise C family way of doing it: int x, y; In C, there is no keyword needed to signal that this is a variable declaration. Similarly, in Nimrod, if you declare the return type of a function, you write it in addition to the "proc" keyword. IMO, the C++0x/D way of declaring a type inferred variable/f…

If you have type inference, this is usually not a problem. Also, it is much easier to parse, both for humans and compilers. Rust uses the former way, and it's extremely readable. Even Herb Sutter, of C++ fame agrees: > One of the things Go does that I would love C++ to do is a complete left-to-right declaration syntax. That is a good thing because the left-to-right makes you end up in a place where you have no ambigu…

I prefer Pascal-style type declaration as well, but playing Devil's advocate for a moment: There's nothing that says you can't have a left-to-right type declaration syntax and have the variable name appear on the right. So something like this:

  var ptr_to_array_of_ptr_to_int : *[](*int)
would become something like this:

  *[](*int) ptr_to_array_of_ptr_to_int
The former syntax is slightly easier for a program to parse, makes it easier to see variable names, and is more consistent with typical syntax for type inference during variable assignment:

  var something := some_function(whatever)
  auto something = some_function(whatever)
However, the latter does, as xaa said, eliminate some keystrokes. I also happen to find

  byte foo = 10
to read more nicely than any of these:

  var foo : byte = 10
  var foo := (u8)10
  var foo := 10'u8

Re: Nimrod: C + Macros + GC

#92

Post by WalterBright »

Araq wrote: post #51
WalterBright wrote: post #48

Earlier quoted context omitted.

Since I've written a C compiler, I know how to read C source files. The problem with automated conversion is you can do 90% of the job without any trouble, but there's that darned last 10% that doesn't map to D without some human decision making. For example, there are the preprocessor macros. Most are straightforward, but it seems most C .h files succumb to the temptation at some point to do something wacky with the…

This is very true; however c2nim distinguishes between #def and #define for this reason and this helps a lot. #def means c2nim needs to expand the macro, #define means it's some macro that should be translated into a Nimrod template. Coming up with heuristics to do this #def vs #define distinction automatically seems to be quite easy and might be implemented in a later version of c2nim.

#def, according to https://github.com/Araq/Nimrod/blob/master/doc/c2nim.txt, requires modification of the C header files. I don't think this is a practical option, for example, they might be system .h files.

Re: Nimrod: C + Macros + GC

#93

Post by winter_blue »

copx wrote: post #58
codygman wrote: post #52

Earlier quoted context omitted.

why?

One good argument I can think of would be compile time. C compiles slowly compared to almost every other language not C++. And of course you get the C compile time on top of the compile to C time, so I expect the Nimrod compile chain to be quite slow. Doesn't mean that I am generally opposed to compiling to C, it's often a good trade-off.

A good solution to this is to go with a language like C-- (if you are too scared of LLVM).

Re: Nimrod: C + Macros + GC

#94

Post by tomp »

evincarofautumn wrote: post #33
jaytaylor wrote: post #4

I wonder what other wonderful languages I've never heard of. Really, please share!

Kitten, a statically typed, globally type-inferred, GC-less functional stack language, with opt-in layout-based syntax and an effect system to separate pure and impure operations. Disclaimer: I wrote this; it’s nowhere near complete, but not bad to play around with. We’re working toward a release in a few weeks, to include some missing language features and a new x86_64 runtime. https://github.com/evincarofautumn/kit…

Can I ask you one thing: why did you decide to write a stack-based programming language?

I'm really curious, as I personally see nothing good with them. The same kind of non-mathematical syntax as LISP (`1 2 +` as opposed to `+ 1 2`), without any of the goodness (code is data).

Re: Nimrod: C + Macros + GC

#95

Post by 0x09 »

pjmlp wrote: post #80
xaa wrote: post #63

Earlier quoted context omitted.

Obviously, I have no perfect solution. I was initially harboring the vague hope that Nimrod would be able to avoid this problem by virtue of compiling to C. But I do still assert that this is a "fatal flaw" for a systems programming language . When I wrap a C library in, say, Python, I am already forced to write a wrapper layer, so there's no discomfort or surprise in declaring a few additional structs or function pr…

> I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure. The main reason were actually - Most C compiler vendors bundled C++ compilers in the begining - The C and C++ compiler vendors that matter are OS vendors Any language can replace C or C++, if an OS vendor decides that it is the wa…

> This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level

Actually they've recently gone back on that and are implementing c99 language[1] and standard library[2] features in an apparent sudden realization that the rest of the C world has moved on (since they cite FFmpeg as a reason, my pet theory is that they were just that embarrassed by Ron Bultje's c99 to c89 translator[3])

[1] http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-con...

[2] http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar...

[3] http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-s...

Re: Nimrod: C + Macros + GC

#96

Post by pjmlp »

foobarbazqux wrote: post #70
prodigal_erik wrote: post #64

Earlier quoted context omitted.

You may also be surprised that "??!" is a trigraph for "|" in case your keyboard doesn't have one. I am not making this up.

Ohhhh... GCC warns about trigraphs, so I tend to forget about them, but wow did I fall for that one. C++ is a wonderful language for people who like puzzles, and it's also good for making fun of know-it-alls.

> C++ is a wonderful language for people who like puzzles, and it's also good for making fun of know-it-alls.

Except trigraphs are another wart inherited from C (ANSI C section 5.2.1.1 A).

Re: Nimrod: C + Macros + GC

#97

Post by dbaupp »

Symmetry wrote: post #68

I actually discovered this yesterday and spent Saturday morning learning about it. I really like most of the syntax, especially the "var/const/let" distinction together with "if/when". I'm sort of wish that Rust and Go would just copy that. The semantics seemed to be up to par with this generation of potential C replacements, but not any better than the others.

Rust has let mut, let and static which seem to correspond fairly closely to var, let and const.

Re: Nimrod: C + Macros + GC

#98

Post by ballard »

Ugh, the community is barely alive and it's an unwieldy collection of non-orthogonal constructs. Generics and a few whiz-bang features doesn't paper over the sins upon sins. I see this project cutting back features or dying under the weight of crushing unmaintainability. (sad.)

Re: Nimrod: C + Macros + GC

#99

Post by pjmlp »

0x09 wrote: post #95
pjmlp wrote: post #80

Earlier quoted context omitted.

> I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure. The main reason were actually - Most C compiler vendors bundled C++ compilers in the begining - The C and C++ compiler vendors that matter are OS vendors Any language can replace C or C++, if an OS vendor decides that it is the wa…

> This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level Actually they've recently gone back on that and are implementing c99 language[1] and standard library[2] features in an apparent sudden realization that the rest of the C world has moved on (since they cite FFmpeg as a reason, my pet theory is that they were just that embarrassed by Ron Bultje's c99 to c89 translato…

Those C99 features are only at library level and are partially required by C++11 and C++14, there is no change of mind going on, at least for the moment.

Re: Nimrod: C + Macros + GC

#100

Post by userulluipeste »

prodigal_erik wrote: post #64
foobarbazqux wrote: post #37

Earlier quoted context omitted.

std::cout If you're using namespace std then it's obvious (note that this is considered bad practice), assuming you haven't overridden <<, but otherwise it depends on endl's type and value. Maybe you meant std::endl?

You may also be surprised that "??!" is a trigraph for "|" in case your keyboard doesn't have one. I am not making this up.

The fact that the C++ preprocessor deals with that trigraph case inside quote marks does not have anything to do with what foobarbazqux said about std::endl.
Post reply on HN