6 ms·

Some semantics are inherently slow though. If you are allowed to add fields to a class at runtime, you have to box all your objects. If you can eval in local sc

Some semantics are inherently slow though. If you are allowed to add fields to a class at runtime, you have to box all your objects. If you can eval in local scopes, you need to check to make sure you're running the right code. There are many types of semantic decisions with inevitable performance impact.

jhgb 5y ago
> If you are allowed to add fields to a class at runtime, you have to box all your objects. Do you? You could restructure your data in memory if you wanted to, at least if the assumption is that adding a field is a rare operation.
- lispm 5y ago
  I would not expect that such features are added under the assumption that it is rarely used. Common Lisp for example has the assumption in the standard, that the object system is fully dynamic and supports a wide variety of live changes (adding/removing/changing of methods, classes, slots, superclasses, ...).
  - jhgb 5y ago
    "Rarely" meaning compared to other elementary operations, such as function or method calls. So it makes sense to make function or method calls faster at the expense of making restructuring slower. That's basically the same principle as with Smalltalk and Lisp structures/objects being vectors as opposed to hash tables (like in Ruby or Python), even if it means that adding a field necessitates having to change the layout of existing instances. This way you'd need to also change the layout of other types that use the unboxed representation of the type being altered but the basic principle is the same and you already have the mechanism for updating your existing heap anyway -- so it should be possible and mere possibility of altering a type shouldn't necessitate boxing everything. "If you are allowed to add fields to a class at runtime, you have to box all your objects" should be no more correct than "if you are allowed to add fields to a class at runtime, all your object instances have to be hash tables".

jhgb 5y ago

> If you are allowed to add fields to a class at runtime, you have to box all your objects. Do you? You could restructure your data in memory if you wanted to, at least if the assumption is that adding a field is a rare operation.

lispm 5y ago
I would not expect that such features are added under the assumption that it is rarely used. Common Lisp for example has the assumption in the standard, that the object system is fully dynamic and supports a wide variety of live changes (adding/removing/changing of methods, classes, slots, superclasses, ...).
- jhgb 5y ago
  "Rarely" meaning compared to other elementary operations, such as function or method calls. So it makes sense to make function or method calls faster at the expense of making restructuring slower. That's basically the same principle as with Smalltalk and Lisp structures/objects being vectors as opposed to hash tables (like in Ruby or Python), even if it means that adding a field necessitates having to change the layout of existing instances. This way you'd need to also change the layout of other types that use the unboxed representation of the type being altered but the basic principle is the same and you already have the mechanism for updating your existing heap anyway -- so it should be possible and mere possibility of altering a type shouldn't necessitate boxing everything. "If you are allowed to add fields to a class at runtime, you have to box all your objects" should be no more correct than "if you are allowed to add fields to a class at runtime, all your object instances have to be hash tables".