top | item 12827400

(no title)

netsettler | 9 years ago

There are reasons to think second-class isn't always bad. Function objects aren't second class but the privileged position of the function namespace means you can watch what's being stored there at storage time, which happens infrequently, and can jump to things faster, which happens comparatively more frequently.

But also, there was a very interesting proposal to ISO that did not survive in which variable number of arguments were handled by an alternate namespace with very specific operations that were understandable to a compiler. You could promote them to the regular namespace if you needed to, but the compiler could do nice things with the stack if you kept them in their more limited arena where it could figure out what you were meaning to do with them. That proposal got voted down, and I was one who didn't like it, but I came to think it was less of a bad idea than I had thought when I saw some of the confusions that came up with managing rest lists on the stack in CL, which are very hard to manipulate and know for sure when they need copying and when not. First class implies that there's probably a halting problem in the most general case of a compiler trying to do code analysis on what you're doing with a thing. Often compilers can recognize sufficient idioms that this doesn't come up in practice, but second class spaces can lead you in certain ways to do things that are better.

Each paradigm has its value.

discuss

order

No comments yet.