3 ms·

What if f is a macro. Then it has a lexically determined meaning. What if f is a function. Then it has a parsing determined meaning. What if the ++ operator has

What if f is a macro. Then it has a lexically determined meaning. What if f is a function. Then it has a parsing determined meaning. What if the ++ operator has been redefined. Et cetera.

gravypod 10y ago
If F is a macro then it will just be expanded. Lets say F was #define f(a, b) printf("%d %d\n", a, b); This would change absolutely nothing. A macro is just a piece of code that is expanded. It still follows all of the rules (and disallowances) of C.
- foota 10y ago
  Fairly certain you can have compound statements as the result of the macro. e.g., the macro could expand to if(a) {printf("%d\n", b);} for example
  - Normal_gaussian 10y ago
    You can. Of course you don't even need the logical connector #define f(a,b) \ f_var1 = a; \ f_var2 = b Equally you could use macros to make it a whole lot worse #define f(a,b) \ f_arr[a][b] += f_arr[b][a]
- snovv_crash 10y ago
  What if the macro uses a and/or b more than once?
loeg 10y ago
At least, the ++ operator cannot be redefined in C.
- tathougies 10y ago
  The ability to redefine the ++ operator would not alone make it difficult to add proper semantics to the C language. What is preventing that is that no one can really describe how function application truly works in C (in terms of operation ordering), except that we all have an idea similar enough that our systems seem to work together in practice. For all the criticism Haskell gets over the purported difficulty on describing sequential computation, at least the order of monadic operations is clearly captured by the requirements to be a monad. There is no such concept for C, except that each compiler mostly seems to perform operations sequentially.
  - rwmj 10y ago
    At least some of it is defined. Annex C of the C99 standard defines when sequence points occur (commonly the ';' operator, but also in a few other places). Source: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf page 439 (!) Note that Annex C is merely informative, but it contains references back to the actual standard where these things are defined. Edit: I think a better advantage of Haskell is that Haskell is much more free to not define sequence points. Haskell effectively defaults to not sequencing expressions unless you use a monad or there is some obvious dependency between those expressions like the output of one function used as the input to another. All that implicit parallelism is something that C compilers have to work hard to derive, but in Haskell it's explicit in the source.
    - eru 10y ago
      Monad's are not such basic building blocks. It's not monads that define sequencing points. It's that data flow in Haskell is the only way to define control flow. (And Monads make use of that.)

What if f is a macro. Then it has a lexically determined meaning. What if f is a function. Then it has a parsing determined meaning. What if the ++ operator has been redefined. Et cetera.

gravypod 10y ago

If F is a macro then it will just be expanded. Lets say F was #define f(a, b) printf("%d %d\n", a, b); This would change absolutely nothing. A macro is just a piece of code that is expanded. It still follows all of the rules (and disallowances) of C.

foota 10y ago
Fairly certain you can have compound statements as the result of the macro. e.g., the macro could expand to if(a) {printf("%d\n", b);} for example
- Normal_gaussian 10y ago
  You can. Of course you don't even need the logical connector #define f(a,b) \ f_var1 = a; \ f_var2 = b Equally you could use macros to make it a whole lot worse #define f(a,b) \ f_arr[a][b] += f_arr[b][a]
snovv_crash 10y ago
What if the macro uses a and/or b more than once?

loeg 10y ago

At least, the ++ operator cannot be redefined in C.

tathougies 10y ago
The ability to redefine the ++ operator would not alone make it difficult to add proper semantics to the C language. What is preventing that is that no one can really describe how function application truly works in C (in terms of operation ordering), except that we all have an idea similar enough that our systems seem to work together in practice. For all the criticism Haskell gets over the purported difficulty on describing sequential computation, at least the order of monadic operations is clearly captured by the requirements to be a monad. There is no such concept for C, except that each compiler mostly seems to perform operations sequentially.
- rwmj 10y ago
  At least some of it is defined. Annex C of the C99 standard defines when sequence points occur (commonly the ';' operator, but also in a few other places). Source: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf page 439 (!) Note that Annex C is merely informative, but it contains references back to the actual standard where these things are defined. Edit: I think a better advantage of Haskell is that Haskell is much more free to not define sequence points. Haskell effectively defaults to not sequencing expressions unless you use a monad or there is some obvious dependency between those expressions like the output of one function used as the input to another. All that implicit parallelism is something that C compilers have to work hard to derive, but in Haskell it's explicit in the source.
  - eru 10y ago
    Monad's are not such basic building blocks. It's not monads that define sequencing points. It's that data flow in Haskell is the only way to define control flow. (And Monads make use of that.)