asgeir

Have you tried looking into something like NASM's macro functionality?

It often refers to programmers that develop things that other programmers use to construct applications. A systems programmer may work on compilers, operating systems, framework libraries, etc.

They will also often work with lower-level abstractions, such as threads, so that the higher-level developers need not think about them in their own designs.

It's possible that we are talking at cross purposes.

I think you might be arguing that the object itself does not include the set of functions/methods/operations that act on it, whereas I see them as another attribute of the class/type which is an attribute of the object.

I would still classify that as object oriented behavior.

You have a class/type of objects, and you have a set of functions or operations which are associated with (loosely or tightly) and operate on that type of object.

For example, I would say that file descriptors are a handle to a type of object. They encapsulate the thing that they represent (file, DRM buffer, eventfd, whatever), and some of the functions that operate on them are polymorphic. For example, read, close, ioctl, etc., don't care if the file descriptor is a file, a queue, or whatever.

You use syscalls to interact with file descriptors, but they are just as much object handles.

It's not a requirement, but an immutable object has fewer uses than a mutable one.

Functions/methods/actions/operations are just different names for the operations which mutate the state of the object. So, I would argue that they are a necessary attribute of mutable objects.

In my experience, LLMs tend to perform better if you give them instructions before the data to be operated on. At least for the ~13b size models.

So,something like: Please count the number of words in the following sentence. "What is the number of words in the sentence coming before the next one?"

edit: Which might be an artifact of the training data always being in that kind of format.

It seems that you may be correct.

At the very least I am unable to construct a counter-example so I concede this point

The undefined behavior can still affect code generation even though the program gets translated.

It's just that the generated code may not do exactly what you expect it to do because the presence of undefined behavior allowed the compiler to make assumptions which may surprise you.

edit: It seems that I am incorrect

USB-C has the springs in the plug while the receptacle is only fixed contacts. Lightning on the other hand has the springs inside the receptacle.

This means that for USB-C you replace the cable when the springs wear out, but for Lightning you need to replace the port.

Cleaning lint out of a USB-C receptacle with a toothpick is safe, but sticking anything into a Lightning port could damage the springs.