Uniform naming

Via research!rsc, I came across The Hideous Name. Although it's mainly about file and email names, this paragraph was interesting.

Although this syntax may seem unnecessarily cumbersome, it has a precedent: it is analogous to expressions in programming languages. Consider a C expression such as *structure[index].field->ptr. If * were postfix and / the only dereferencing operator, the expression might be written structure/index/field/ptr/. Functionally-minded programmers might use the notation contents(ptr(field(index(structure)))). (A single character cannot be used in C because it could not distinguish X[Y] and X->Y, with X a structure pointer and Y an integer or structure element respectively, but this ambiguity could be eliminated in a different language.) C and VMS use syntax to distinguish the types of the components of a name. Instead, the UNIX file system deliberately hides the distinctions. Aside from the obvious advantages such as simplicity of syntax and the usurping of only a single character, the uniformity also makes the name space easier to manipulate: the mount system call aliases a disk and a directory.

Do any languages use a uniform naming system for all entities?

[Edit: fixed the links]

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Dereferencing operators

If all dereferencing-like operators are made postfix as in Pascal, then you can write: structure[index].field^.ptr^. This is clearly superior to to the messy combination of prefix and infix path operators in C++ that lead to ugly expressions like *((*a)->b[c].e)->f. That half of your proposal has much merit.

But, merging all such operations into a single symbol would have undesirable consequences. For example, in C++/Java/C#, a.b looks up b in the scope of a, while a[b] looks up b in the current scope. If you combined syntax, then the scope in which "b" is found in "a/b" would depend on whether a is a class or array. Context-dependent scoping would add undesirable complexity.

For example, in C++/Java/C#,

For example, in C++/Java/C#, a.b looks up b in the scope of a, while a[b] looks up b in the current scope.

I don't think I understand what you mean by 'current scope'. Surely the value returned by a[b] is the value of b in the scope of a, just like a.b. Unless you're referring to the distinction between variables and literals. If b is a literal, the meaning is the same, but if b is a variable, then a.b is currently meaningless for structs, but for arrays it's value in the current scope is used. We would need something like first-class labels and a disambiguation strategy to be able to use them both (as they are both useful). Something like the syntax for string substitution in various scripting languages:

//look up 'b' under scope 'a'
a/b

//variable 'b' from current scope spliced into the access
a/$b

Perhaps...

...although I think Alloy makes an interesting choice: everything is represented as a relation, even scalars, tuples, and sets. The "dot" operator, then, is a join, but it works uniformly given this uniform representation. See Alloy in 90 Minutes (PDF) for more.

Cool, thanks for the PDF link

time to re-read-up on alloy again. (for various reasons, i've been thinking nebulous thoughts about how i want to try writing code which basically has a relational database in memory and then a bunch of rules which operate using that data. so this sounds like food for thought in that general vicinity.)

You Might Find...

MetaKit or Rel interesting. See also Out of the Tar Pit, right here on LtU.

Categories and Allegories oh my

I don't completely grok category theory wrt programming languages, so I am even more at sea with this, but it sounds like there is some angle on relational data modeling via allegories?

The link above is broken

Doh!

I forgot to fill in the link URLS. Fixed.