Guido van Rossum wrote: > That's all good. I just don't think that a presentation in terms of > code in-lining is a good idea. I was trying to describe it in a way that would give some insight into *why* the various aspects of the formal definition are the way they are. The inlining concept seemed like an elegant way of doing that. However, I've since realized that it's not quite as unambiguous as I thought it was when a return value is involved. I'll see if I can find another approach. > some languages *do* work that way (e.g. macro languages and Algol-60), Algol-60 doesn't actually work that way, they just used a similar trick to define certain aspects of the semantics (although in that case I agree there were better ways they could have defined it). I'm asking you to use a different word, since "inlining" to > me has pretty strong connotations of textual substitution. That's not what it usually means, as far as I can see. When you declare a function 'inline' in C, you're not asking for a blind textual substitution. Rather, you're asking the compiler to generate whatever code is needed to get the same effect as an actual call. -- Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4