On Sun, 2005-12-04 at 12:25 +0100, Leopold Toetsch wrote: > And it doesn't answer my question at all, sorry. Which HLLs are able to > divide their symbols into above categories?
Ah, maybe I see what you're getting at. At compile-time, a HLL knows whether it is compiling a sub or a variable. But at runtime, the HLL may or may not know whether a name is associated with a sub or a variable. But I see two cases where the HLL will be able to successfully use 'add_sub' and 'add_var': 1. If the HLL supports reflection/introspection (the ability of a running program to learn about its own types), then it should certainly have enough information to be able to use 'add_sub'/'add_var'. 2. The HLL may choose to store some kind of symbol table within its private namespace (for the express purpose of supporting 'add_sub'/'add_var'). Amber will do this, because Amber is a minority language and will be critically dependent on interoperability to be viable. I can understand that the "big players" might not be bothered, though. Any HLL that doesn't know which names are subs can just call 'add_var' for everything and let the receiving HLL cope as best it can. > Remaining for me is the distiction between a variable and a function > symbol: > > - python: no (all names are just names) This is an orthogonal issue, no? Python can't have a variable and a sub both named "foo", but that's unrelated to whether it knows if some particular "foo" is a variable or a sub. Regards, Roger Browne
