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?...
Ask HN: What would Your_Favorite_Compiler do?
11–20 of 28 posts
Re: Ask HN: What would Your_Favorite_Compiler do?
#12Think 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 go…
Java's result is 21
gcc says 22 and it gives you a warning, that this expression is illegal, we looked it up, because you cannot use a variable which is ++incremented more than once in the same expression.
Re: Ask HN: What would Your_Favorite_Compiler do?
#13y 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?...
That "comment" is called parentheses :)
Re: Ask HN: What would Your_Favorite_Compiler do?
#14 # let x = 10;;
val x : int = 10
# let y = x + ++x;;
Error: Syntax error
# 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
Re: Ask HN: What would Your_Favorite_Compiler do?
#15Think 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 go…
Sounds plausible, but I don't think it's true.
Compilers don't magically filter assignments out of expressions. The compiler already has the parse tree (+ x (1+ x)), and the arguments are pushed on the stack in reverse order because that's consistent with function calls (in c++ when you were to overload operator+ nothing would change, I suspect). So first 1+ x is evaluated and the value of x is updated, and the number 22 is returned.
Or to illustrate with a stack machine:
PUSH X
INC
STORE X
PUSH X
ADD
STORE Y
Re: Ask HN: What would Your_Favorite_Compiler do?
#16Think 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 go…
Sounds plausible, but I don't think it's true. Compilers don't magically filter assignments out of expressions. The compiler already has the parse tree (+ x (1+ x)), and the arguments are pushed on the stack in reverse order because that's consistent with function calls (in c++ when you were to overload operator+ nothing would change, I suspect). So first 1+ x is evaluated and the value of x is updated, and the numbe…
Java: "Regardless of their complexity, the meanings of expressions are allways well defined."
That's why you can infer that y = 21 in Java.
Would you call Java insane for that?
Re: Ask HN: What would Your_Favorite_Compiler do?
#17Interpreter, 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.
yup, that's python alright. Very odd behaviour
++x in python parses as +(+(x))
Re: Ask HN: What would Your_Favorite_Compiler do?
#18i'd think in this way:
y = operator+(x, operator++(x));
Re: Ask HN: What would Your_Favorite_Compiler do?
#19My_Favourite_Compiler would compile "x + ++x" as a call to abort(3). I think "undefined behaviour" is a horrible idea.
Undefined depends on the language. In many languages, the precedence rules are explicit enough that this code is clearly defined. In Ultilang (my own), Boo, and others, this would be parsed as x + {x += 1; x} and processed left-to-right.
Re: Ask HN: What would Your_Favorite_Compiler do?
#20I 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.