Hacker News new | ask | show | jobs
by zelphirkalt 854 days ago
If `c` does not depend on `a`, then the re-arrangement seems simple: Define `c` later.
1 comments

> If `c` does not depend on `a`, then the re-arrangement seems simple: Define `c` later.

How does that prevent 'a' from being in the scope where 'c' is defined? It is not clear to me what you mean by defining 'c' later. Later where? And how do we ensure that 'a' is not accessible there?

I think lex-lightning's comment has a point. We need to define 'a' and we need to define 'c' and then we need to print 'c' before printing 'a', so although 'c' does not depend on 'a', we still need to keep 'a' in scope because we cannot print it before we print 'c'.

Perhaps a convoluted solution to the problem posed in lex-lightning's comment would be something like this:

  #include <stdio.h>

  int getint() {
      return 42;
  }

  int main()
  {
      int a = getint();
      int b = getint() + a;
      int c;

      {
          // Shadow 'a' here to make the outer 'a' inaccessible in this scope.
          int *a = NULL;
          (void) a;
          c = getint();
      }

      int d = b / c;

      printf("%d\n", d);
      printf("%d\n", c);
      printf("%d\n", b);
      printf("%d\n", a);

      return 0;
  }
Output:

  $ cc -std=c99 -Wall -Wextra -pedantic foo.c && ./a.out
  2
  42
  84
  42
I see now how the problem is. Thanks. I have a suspicion, that this depends on side effects and that without assignments and without side effects things might look different. Somehow I don't seem to come across these scenarios, when I write FP programs.
Hey I’m down to party with some monads, but I leave that as an exercise to the reader.

One note: each variable only gets assigned to once, so FP won’t magic that away.

The side effects might have a different way of management in FP. But the IO will happen in the same order in reality anyway.

So I don’t think there’s a way out, but I honestly would be interested to see it.

I will definitely keep an eye open now, to see whether I hit such a situation in the future.
I appreciate your interest.

I’d argue that even declaring ‘c’ is against the spirit though. To say nothing of the eldritch shadow cast there (no disrespect, I think we’re both enjoying playing around here)

> I’d argue that even declaring ‘c’ is against the spirit though.

Yes, I agree. My code example is meant to show the best we can possibly do to solve the problem in your comment and how contrived that solution is. The fact that this solution is contrived and diverges from the intended spirit of the problem only emphasizes the point of your comment.

That's why I am eager to understand what zelphirkalt really meant when they wrote, "the re-arrangement seems simple: define `c` later". It seems far from simple and, in fact, impossible if we want to avoid contrived solutions.

I’m a contrived idea man, not a contrived solution man, damnit.