4 ms·

I don't think its really a single global 'namespace'. It seems that instead of using actual names for the key in the k/v database, you would use something clos

by ohyes 15y ago

I don't think its really a single global 'namespace'. It seems that instead of using actual names for the key in the k/v database, you would use something closer to an ip-address. give the function a unique id, and then make it have a really good description. To find the function, you use the description, and then reference the unique id. To reference it in your code, you would bind the unique id to the descriptive name. What I want to know is how you prevent massive duplication of functionality in this k/v database (with slightly different argument conventions or implementation details, for example).

bartonfink 15y ago
You'd have the duplicate functionality problem anyhow, as function tables essentially work as k/v databases already. The keys are the method signatures (e.g. name, parameters, return type) and the value is the actual implementation. Unless your language syntax specifies that argument conventions (e.g. names or ordering of parameters) are part of the method signature, you're always going to have to deal with the problem of foo(int a, char b) mapping differently from foo(int i, char c) or foo(char b, int a). You could do this, but it's not really widespread as far as I know. I know of no language that deduplicates functions based on implementation details.
- pavpanchekha 15y ago
  Furthermore it's undoable in general. Equivalence of lambda terms being undecideable and so on. Point being, at some point functions become sufficiently different that it's hard to tell. What if you write one md5 function in Erlang, another in whatever that Ruby syntax for Erlang is called. I'm sure the Erlang they both generate, or bytecode, or what-have-you (I don't know how BEAM or HIPE work on the inside) are very different, to the point that checking that they are truly equivalent is going to be near-impossible, even for a very strictly defined program like MD5.

by ohyes 15y ago

bartonfink 15y ago

You'd have the duplicate functionality problem anyhow, as function tables essentially work as k/v databases already. The keys are the method signatures (e.g. name, parameters, return type) and the value is the actual implementation. Unless your language syntax specifies that argument conventions (e.g. names or ordering of parameters) are part of the method signature, you're always going to have to deal with the problem of foo(int a, char b) mapping differently from foo(int i, char c) or foo(char b, int a). You could do this, but it's not really widespread as far as I know. I know of no language that deduplicates functions based on implementation details.

pavpanchekha 15y ago
Furthermore it's undoable in general. Equivalence of lambda terms being undecideable and so on. Point being, at some point functions become sufficiently different that it's hard to tell. What if you write one md5 function in Erlang, another in whatever that Ruby syntax for Erlang is called. I'm sure the Erlang they both generate, or bytecode, or what-have-you (I don't know how BEAM or HIPE work on the inside) are very different, to the point that checking that they are truly equivalent is going to be near-impossible, even for a very strictly defined program like MD5.