Getfield overloading (again)

[ihnorton]

The recent discussion of NamedTuple in #22194 and here on Discourse reminded me of a question I continue to ponder for getfield overloading: how could we make it general enough to allow modules to be implemented as a user-level feature?

For example, can the Module resolution optimizations in codegen (and inference) be generalized a little bit without destroying compiler performance.

Jeff touched on this in the 1974 thread:

The biggest issue is that modules have special behavior with respect to … In theory, this would just be another method of getfield, but the problem is that we need to resolve module references earlier since they basically behave like global variables. I think we will have to keep this a special case in the behavior of … There is also a bit of a compiler efficiency concern, due to analyzing (# types) * (# fields) extra function definitions. But for that we will just see what happens.

but I think that comment was mainly considering the cost of a full method lookup everywhere – obviously that would be prohibitive. However, the “deferred binding” aspect of getfield keeps leading me to look for an analogy with reader macros. It might not be too expensive to add one more binding table specific to getfield, akin to *readtable* – which apparently isn’t too expensive to query token-wise in many Lisps?

[jeff.bezanson]

Yes, it’s interesting to think about. One thing I’d say is, if method lookup is too slow, the answer is always to make method lookup faster

Implementing modules at the user level is difficult. The core system consists of a finite set of things, and to be able to use them you need to be able to name them. So they exist in some kind of namespace. The next question is whether there is only one such namespace, or if there can be many of them. I find it easier to introduce modules at this point, and say there can be many of them. But, I think any reasonable form of getfield overloading will be general enough to allow experimentation with this.