Hacker News Reader

Comment by KMag | Hacker News Reader

Interpreted vs. compiled vs. JIT-compiled is usually not part of a language definition, and can easily change without it being considered a new language.

Many Lisp dialects include both compilers and interpreters. There was gcj and now Oracle's AoT for Java, etc. In the late 1990s, MIT's 6.270 robotics competition used an interpreted implementation of C. I haven't heard anyone claim that these implementation details should cause the implementation to be "not really Lisp", "not really Java", or "not really C".

Also, if you link in Boehm's libgc and start allocating via libgc, you've got (conservatively) garbage-collected C without violating any of the C standards.

View on HN

In some cases interpreted gives you more flexibility/possibilities.

For example in Julia you can define a function and compile it for all possible types. But what if you import a package with a new type? You have to recompile the function for parameters of that type or can't use it. Or if a function has 3 parameters and there are, say, 20 different types. That's a lot of combinations, compiling them all would be wasteful.

(I don't know how Julia handles these things internally so I might be wrong.)

Boehm violates ISO C. There is no such thing as retrofitting "after-market" garbage collection into a C implementation, without violating ISO C.

Citation needed

The interface to Boehm GC is that you call GC_INIT(), then you get some pointers from GC_MALLOC() and GC_REALLOC(). Nothing in ISO C requires that a function returning a pointer must guarantee that pointer remains valid forever. Which section number of any of the ISO C standards do you think Boehm GC violates?

The implementation details of the Boehm GC certainly exploit implementation-defined behavior and there's likely some undefined behavior there, too. However, those are implementation details of the library itself. If Boehm GC were written in assembly, then it could function exactly the same and ISO C would be irrelevant to its implementation.

> those are implementation details of the library itself.

By this reasoning, though, any behavior is defined as long as we box it off into a library.

(By "defined" here, I mean "ISO C defined" not "declared to be working, and maintained in that order by a library vendor").

> If Boehm GC were written in assembly

Every instance of undefined behavior that doesn't prevent translation results in machine code. We can infer its behavior from the instruction manual, and write assembly source which produces the same code. Therefore, there is no such thing as undefined behavior.

Your assertion was that using (linking/calling) Boehm GC causes the C program to violate ISO C and thus in some sense stop being a GC'd C program. This is then a property of the interface of libgc. If you're relying on an implementation detail of a library that's not visible from outside the library to make an argument about the actual language of any program that calls into it, you're violating the library abstraction.

A C program doesn't stop being a C program because it calls into a BLAS library that happens to be implemented in Fortran or some low-level library implemented in assembly.

Again: what property of the interface of Boehm GC breaks any revision of the ISO C standard?

My assertion was exactly this: "Boehm violates ISO C". A C program stops being an ISO C defined program when it calls into a translation unit that invokes ISO C undefined behavior, even if the call takes place through a good interface. If you call a library for loading a JPEG image, through a nice interface, but that library segfaults, your entire program has undefined behavior.

A C program also stops being an ISO C program when it calls a function that is not in the standard C library and that is written in Fortran. However, that Fortran code can be well-defined Fortran, and the call can be taking place through a C-Fortran calling mechanism documented by the compiler suite. So that even though we don't have a definition of behavior entirely coming from ISO C (so that the program is undefined as far as ISO C is concerned), we can piece together a definition of behavior from ISO C and additional sources, like the Fortran standard and the reference manual for the toolchain.

We don't have any such definition of behavior with Boehm GC. The behavior is empirically validated. No compiler document says that it's okay to scan memory looking for pointers, as a documented extension.

Reply on news.ycombinator.com