Ask HN: What would Your_Favorite_Compiler do?

  (let* ((x 10)
         (y x))
    (+ x (incf x)))

  vs

  (let* ((x 10)
         (y x))
    (prog1
      (+ x x)
      (incf x)))   

  [INCF does it with side-effects, use 1+ or directly evaluate  (+ 1 x) for the clean version]

Not everyone puts up with semantic ambiguity in operator precedence and evaluation. Some of us program in parse trees, directly :-)

  (+ x (incf x))

  (do
    (incf x)
    (+ x x))

  f(x) -> x + succ(x)
  y = f(10) 

I predicted 21 and got 22 with gcc on mac. This is why I hack Haskell :)

My_Favourite_Compiler would compile "x + ++x" as a call to abort(3). I think "undefined behaviour" is a horrible idea.

My favourite compiler, would have a manual one page long. I should be able to read it and program 'hello world' in five minutes. It should come with about 40 primitives and leave the rest to me and its community!(It should also throw an error if you type y=x + ++x

:)

Interpreter, really:

    >>> x = 10
    >>> x + ++x
    20

I suspect my other favorite compiler will say 'Type error: Could not match "Num a => a" against "Num a => [a] -> [a]"', but I don't want to wait for it to finish installing.

Think about how this is compiled. In machine language there are no nested expressions, so the compiler will have to split the expression up.

    expression( ... ++x ... )

will probably be translated to

    x = x+1;
    expression( ... x ... )

This is the simplest way to compile ++x:

    1. put x=x+1 before the expression
    2. replace ++x with x

So I think most languages would get 22.

But in languages where + is a function there's a good chance you get 21.

    PUSH X
    INC     
    STORE X
    PUSH X
    ADD
    STORE Y

y is 22. But my favourite imaginary compiler doesn't allow you to compile the second statement unless 1. your IQ is above a certain threshold 2. you explained in a comment - why?...

    # let x = 10;;
    val x : int = 10
    # let y = x + ++x;;
    Error: Syntax error

Hmm. Let's try that again:

    # let x = ref 10;;
    val x : int ref = {contents = 10}
    # let y = !x + incr x;;
    Error: This expression has type unit but an expression was expected of type int

So nothing, I guess!

i'd think in this way:

    y = operator+(x, operator++(x));

and therefore operator++(x) would be called before operator+()

I would expect 22. On a related a aside this reminds me of a time in school where I wrote a recursive function that I called using the post decrement operator as follows, some_func(x--) which was supposed to stop recursion when x reached zero. Of course, it never did and went until it filled the stack. One of those things that stares you in the face and yet takes hours before you're like duh.

    val x = unsafePerformIO $ readIORef x

    inc x = unsafePerformIO $ modifyIORef x (1+) >> readIORef x

    main = do
      x <- newIORef (10::Int)
      print $ val x + inc x

The result is 21.

Edit: an explanation. GHC runs on graph reduction, and will do "normal order" reduction in the normal case. + is strict in both arguments, so (val x) will be fully evaluated before (inc x) is evaluated.

If we replace with a lazy operator like (:), then we can get different results. Here is a program which will evaluate the (inc x) first:

    main = do
      x <- newIORef (10::Int)
      print $ reverse $ val x : inc x : []

the expression is not fully evaluated until it is printed, and then it is evaluated in reverse order, so inc x runs before val x. The result is [11,11].

Of course, none of this can be relied on. GHC does a lot of optimizations, and unsafe operations are unsafe.

The formal answer for C and C++ is "undefined", because the + operator is not a sequence point (meaning that the side-effect of ++ may or may not flushed). So my favourite compiler would issue a warning :)