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

101–110 of 116 posts

Re: Nimrod: C + Macros + GC

#101

Post by coldtea »

xaa wrote: post #74
eru wrote: post #71

Earlier quoted context omitted.

What's redundant about the `var' syntax? Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.

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…

>as opposed to the more concise C family way of doing it

The "C family way of doing it" is problematic, and gets crazy complicated with more involved declarations (e.g involving function pointers and such).

Nimrods/Go/etc way is much better.

Re: Nimrod: C + Macros + GC

#102

Post by coldtea »

tomp wrote: post #94
evincarofautumn wrote: post #33

Earlier quoted context omitted.

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

Seriously? Ever heard about this Forth thing?

Re: Nimrod: C + Macros + GC

#103

Post by coldtea »

ballard wrote: post #98

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

The above comment is content-free (at least argument wise).

What are those "sins"? What are the non-orthogonal constructs, and how are they "non-orthogonal"? What's unwieldy about them?

Seems mostly like pissing on somebody's work for the fun of it.

Re: Nimrod: C + Macros + GC

#104

Post by stonemetal »

dom96 wrote: post #39
xaa wrote: post #19

This reminds me a lot of D. It's low-level, GCed, essentially intended as a nicer C/C++. But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. As another commenter below noted, the var and proc thing is also redundant and…

> But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. I can't think of a better alternative. Can you suggest one? The fact that Nimrod compiles to C already is a huge plus, it makes wrapping C code very easy.

If the language has "A real package system" why not allow for packages written in other languages? If a C build system can look at a .h and a .lib and figure out what symbols are exported and use them then I seen no reason why a compiler for xyz could not also do that. If you reused OSS projects like Clang it may not even be a monumental effort.

Re: Nimrod: C + Macros + GC

#105

Post by commentzorro »

ballard wrote: post #98

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

>> ...unwieldy collection of non-orthogonal constructs...

>> ...doesn't paper over the sins upon sins...

Please elaborate. I didn't see any of that and honestly don't know what "non-orthogonal constructs" means. I'm no language design expert but would like to know what, to you, are the obvious deficiencies.

Re: Nimrod: C + Macros + GC

#106

Post by Araq »

pilif wrote: post #82

Reading the tutorial is indeed very pleasant. I have to say however, that from such a new language I would ask for more correct string handling as opposed to the let-me-sidestep-encoding-issues-and-still-call-it-UTF8 that's going on. Defining characters as 8 bit is not quite correct (you will get char variables holding a fraction of a character), treating strings as arrays of characters by conversion also isn't (now…

Strings should be converted to UTF-8 as part of input validation. For proper input validation we have the taint mode already. Note that often a file does not include any information about the encoding, so you can only use heuristics.

Re: Nimrod: C + Macros + GC

#107

Post by evincarofautumn »

tomp wrote: post #94
evincarofautumn wrote: post #33

Earlier quoted context omitted.

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

In Factor, code is data. Remember, though, that there are many sources of goodness in a language. As for your actual question, I decided to write a stack-based language because:

• They can be implemented very efficiently on real hardware. The stack-based VM is well established as an implementation technique for non–stack-based languages.

• Like in Lisp, the simple structure makes them suitable for useful visualisations beyond the program text. Static typing creates even more cool possibilities for such analysis.

• There is fertile ground for new research, and applying existing theory to these languages for the first time—particularly type and effect systems.

• It’s just a lot of fun. :)

Re: Nimrod: C + Macros + GC

#108

Post by xaa »

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…

Go is a good example. It does variable declaration quite concisely while avoiding parsing ambiguity (although it falls into the same trap as Nimrod on function declaration with its "func" keyword).

Type inference can be useful, but important secondary purposes of declaring types, beyond informing the compiler what type a variable is, are as documentation to yourself, and as a sort of compile-time assertion, to ensure that the variable type is indeed what you thought it was. Thus, a language with type inference should not treat manually declared types as some kind of corner case.

Re: Nimrod: C + Macros + GC

#109

Post by tomp »

evincarofautumn wrote: post #107
tomp wrote: post #94

Earlier quoted context omitted.

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

In Factor, code is data. Remember, though, that there are many sources of goodness in a language. As for your actual question, I decided to write a stack-based language because: • They can be implemented very efficiently on real hardware. The stack-based VM is well established as an implementation technique for non–stack-based languages. • Like in Lisp, the simple structure makes them suitable for useful visualisatio…

I agree with all of those, to me is just seems like transformation into stack-based language should be made as part of the compilation process, not written down by the programmer. Maybe it's just me, I totally admit that I'm not used to thinking in concatenative languages as I've never used one, but mathematics, with named variables and control- and data-flow denoted by functions or sequential lines of operations, seems the most natural notation to read, write and think in.

Re: Nimrod: C + Macros + GC

#110

Post by pekk »

I don't understand why Nimrod has to mostly look like Python, but then make all kinds of innovations in syntax and formatting which have nothing to do with performance.
Post reply on HN