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

Nimrod for C programmers

github.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Nimrod for C programmers

#61

Post by Nursie »

audunw wrote: post #54
Nursie wrote: post #29

Earlier quoted context omitted.

Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately. Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. Overflow is a separate issue and you must either make sure you either know the range of the data and pick an appropriately sized storage type, or explicitly check for o…

> Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately. I just started working on this kind of application (well, USB protocols, but same issues) in Nimrod. First of all: just do "import unsigned" and you can work with unsigned just fine. I don't see why this is an issue, any more than that you have to do "import libusb". Seco…

Sorry, wasn't saying it was an issue with the language, just another case where unsigned, raw data was useful.

I don't really see how unsigned are that much of a problem that they have to be dealt with specially...

Re: Nimrod for C programmers

#62

Post by [deleted] »

rbehrends wrote: post #50
pcwalton wrote: post #43

Earlier quoted context omitted.

I think this demonstrates a problem with C-style for loops (as opposed to iterators) more than unsigned integers.

The problem lies with len-1 underflowing, not the loop that uses the result. For another example, to test congruence of x and y modulo m, you check if (x-y) % m == 0. This also blows up for unsigned integers if y > x unless m is a power of 2. Even iteration is not always over containers or some other structure in a way where the boundaries can be inferred and do not have to be computed, and not always in an order tha…

[deleted]

Re: Nimrod for C programmers

#63

Post by detrino »

rbehrends wrote: post #50
pcwalton wrote: post #43

Earlier quoted context omitted.

I think this demonstrates a problem with C-style for loops (as opposed to iterators) more than unsigned integers.

The problem lies with len-1 underflowing, not the loop that uses the result. For another example, to test congruence of x and y modulo m, you check if (x-y) % m == 0. This also blows up for unsigned integers if y > x unless m is a power of 2. Even iteration is not always over containers or some other structure in a way where the boundaries can be inferred and do not have to be computed, and not always in an order tha…

It's a problem with C for loops. There is really no good way to write a counting down loop using a for loop. The fundamental problem is that a for loop is: test a condition, run a loop body, then run a step function. This is suited to counting up loops but when counting down what you want is: test a condition, run a step function, then run a loop body. If you use while loops instead of for loops, you will see the two loops are symmetrical and there is no underflow for unsigned types. See http://ideone.com/1ABiCw

Re: Nimrod for C programmers

#64

Post by dscrd »

jessaustin wrote: post #21
SeanDav wrote: post #18

Earlier quoted context omitted.

A "C" type programming language with no curly brackets (or equivalent) and significant whitespace is a huge negative for me and utter deal breaker. This is the first time I have heard about Nimrod and was very interested to see more. It was all looking so good until I came to this part. Literally I stopped browsing the Nimrod site and closed it down (with some regret) as soon as I saw this. Not interested anymore.

Does this strong preference come from any particular experience? E.g., has Python's significant whitespace caused persistent errors on a project?

It makes copy/paste programming so much more difficult...

Re: Nimrod for C programmers

#65

Post by rbehrends »

pcwalton wrote: post #59
rbehrends wrote: post #50

Earlier quoted context omitted.

The problem lies with len-1 underflowing, not the loop that uses the result. For another example, to test congruence of x and y modulo m, you check if (x-y) % m == 0. This also blows up for unsigned integers if y > x unless m is a power of 2. Even iteration is not always over containers or some other structure in a way where the boundaries can be inferred and do not have to be computed, and not always in an order tha…

Even iteration over explicit ranges of unsigned integers can be handled by a Python range()-style iterator, without the risk of this bug (since the iterator itself is responsible for avoiding this gotcha).

Only if the language has ONLY iterators that are of the [closed, open) kind of interval. If you have, e.g., Smalltalk/Scala-like to:/to iterators (even if you have also iterators that exclude the upper end), you get the same problem in conjunction with unsigned integers (except that these languages use signed integers, so the problem doesn't show up).

Re: Nimrod for C programmers

#66

Post by rbehrends »

detrino wrote: post #63
rbehrends wrote: post #50

Earlier quoted context omitted.

The problem lies with len-1 underflowing, not the loop that uses the result. For another example, to test congruence of x and y modulo m, you check if (x-y) % m == 0. This also blows up for unsigned integers if y > x unless m is a power of 2. Even iteration is not always over containers or some other structure in a way where the boundaries can be inferred and do not have to be computed, and not always in an order tha…

It's a problem with C for loops. There is really no good way to write a counting down loop using a for loop. The fundamental problem is that a for loop is: test a condition, run a loop body, then run a step function. This is suited to counting up loops but when counting down what you want is: test a condition, run a step function, then run a loop body. If you use while loops instead of for loops, you will see the two…

I don't like C for loops, either, but this can happen with other types of for loops, either. E.g. in Pascal:

  for i := 0 to len-1 do begin ... end
This is counting up, not counting down, and len-1 is still going to be either 2^k-1 or result in an error when you're using unsigned integers.

While loops also don't fix it (not to mention that they have their own problem, such as forgetting or misplacing the iteration step). The primary issue is that len-1 is underflowing. Yes, you can avoid calculating len-1, but by that token, no error is ever a problem, because they can all be avoided with enough diligence and foresight. In that universe, Heartbleed never happened and the Ariane 5 never blew up. It is, however, not the world we live in.

Re: Nimrod for C programmers

#67

Post by detrino »

rbehrends wrote: post #66
detrino wrote: post #63

Earlier quoted context omitted.

It's a problem with C for loops. There is really no good way to write a counting down loop using a for loop. The fundamental problem is that a for loop is: test a condition, run a loop body, then run a step function. This is suited to counting up loops but when counting down what you want is: test a condition, run a step function, then run a loop body. If you use while loops instead of for loops, you will see the two…

I don't like C for loops, either, but this can happen with other types of for loops, either. E.g. in Pascal: for i := 0 to len-1 do begin ... end This is counting up, not counting down, and len-1 is still going to be either 2^k-1 or result in an error when you're using unsigned integers. While loops also don't fix it (not to mention that they have their own problem, such as forgetting or misplacing the iteration step…

That's a representation problem. C/C++ use half open ranges and have no problems with unsigned integers.

This is also a non-issue in C++ as you have iterators and counting loops are easy to abstract away using counting iterators or style functions.

Post reply on HN