4 ms·

I honestly can't begin to contemplate how you expect stdio.h to work (without writing extra wrappers) if you don't support macros and a preprocessor. Some of t

I honestly can't begin to contemplate how you expect stdio.h to work (without writing extra wrappers) if you don't support macros and a preprocessor. Some of the "functions" in there are macros.

shasta 16y ago
import_c<stdio.h> You can import C headers without your language being a superset of C.
- ToastOpt 16y ago
  Yes. Many a time I have wished to import a library's symbols without importing its macros. Or better yet, import its symbols under alternate names. "namespace x = import<y.h>" anyone?
  - phaedrus 16y ago
    Yes, the biggest problem with #includes is the namespace cross contamination they can cause. I once tracked a build problem down to someone #defining usleep(time) to 'sleep(time/1000)' (or something similar). Problem was, usleep was included later, so the definition of the real usleep got replaced with gibberish that did math inside a function declaration.
  - sprout 16y ago
    I'm really looking forward to maintaining your code.
- haberman 16y ago
  Interesting idea, but how are you going to support "functions" like getc() that are actually macros?
  - _delirium 16y ago
    Most C libraries already implement those as both functions and macros. The macro definition usually shadows the function definition, but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. The macro is just a wrapper for a function anyway in glibc (the internal _IO_getc), so there's no real reason to retain it except for historical reasons. If macros were eliminated in user code, you'd just use the function versions. I think having them as macros at all is an efficiency hack dating back to the days when compilers didn't do function inlining.
    - nuxi 16y ago
      > but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. Are you sure about this?
      - JoachimSchipper 16y ago
        Yes (the macro must be define as #define getc(stream) ... of course, but that's the only legal definition anyway). ("Free-standing implementations" like kernels have a lot of freedom to muck with the standard library. But that's not really relevant.)
        nuxi 16y ago
        Ah okay, I understand what you meant now. One thing however - if it is a macro, couldn't it just be: #define getc fgetc_or_similar At least C89/90 only mentions that if it is a macro, it may evaluate arguments more than once (but then it may not, as in the above case).
        JoachimSchipper 16y ago
        Yes and no. Yes, that is a valid #define; but the following program must work: #include <stdio.h> #undef getc int main(void) { getc(stdin); return 0; } so it cannot be implemented as only a macro.

I honestly can't begin to contemplate how you expect stdio.h to work (without writing extra wrappers) if you don't support macros and a preprocessor. Some of the "functions" in there are macros.

shasta 16y ago

import_c<stdio.h> You can import C headers without your language being a superset of C.

ToastOpt 16y ago
Yes. Many a time I have wished to import a library's symbols without importing its macros. Or better yet, import its symbols under alternate names. "namespace x = import<y.h>" anyone?
- phaedrus 16y ago
  Yes, the biggest problem with #includes is the namespace cross contamination they can cause. I once tracked a build problem down to someone #defining usleep(time) to 'sleep(time/1000)' (or something similar). Problem was, usleep was included later, so the definition of the real usleep got replaced with gibberish that did math inside a function declaration.
- sprout 16y ago
  I'm really looking forward to maintaining your code.
haberman 16y ago
Interesting idea, but how are you going to support "functions" like getc() that are actually macros?
- _delirium 16y ago
  Most C libraries already implement those as both functions and macros. The macro definition usually shadows the function definition, but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. The macro is just a wrapper for a function anyway in glibc (the internal _IO_getc), so there's no real reason to retain it except for historical reasons. If macros were eliminated in user code, you'd just use the function versions. I think having them as macros at all is an efficiency hack dating back to the days when compilers didn't do function inlining.
  - nuxi 16y ago
    > but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. Are you sure about this?
    - JoachimSchipper 16y ago
      Yes (the macro must be define as #define getc(stream) ... of course, but that's the only legal definition anyway). ("Free-standing implementations" like kernels have a lot of freedom to muck with the standard library. But that's not really relevant.)
      - nuxi 16y ago
        Ah okay, I understand what you meant now. One thing however - if it is a macro, couldn't it just be: #define getc fgetc_or_similar At least C89/90 only mentions that if it is a macro, it may evaluate arguments more than once (but then it may not, as in the above case).
        JoachimSchipper 16y ago
        Yes and no. Yes, that is a valid #define; but the following program must work: #include <stdio.h> #undef getc int main(void) { getc(stdin); return 0; } so it cannot be implemented as only a macro.