Home » forums » LtU Forum

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]

By George Morrison at 2008-02-18 20:12 | LtU Forum | previous forum topic | next forum topic | other blogs | 5314 reads

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.

By Tim Sweeney at Mon, 2008-02-18 23:25 | login or register to post comments

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

By naasking at Mon, 2008-02-18 23:51 | login or register to post comments

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.

By Paul Snively at Tue, 2008-02-19 05:00 | login or register to post comments

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.)

By raould at Tue, 2008-02-19 18:18 | login or register to post comments

You Might Find...

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

By Paul Snively at Tue, 2008-02-19 20:12 | login or register to post comments

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?

By raould at Wed, 2008-02-20 22:21 | login or register to post comments

The link above is broken

It should be http://plan9.bell-labs.com/cm/cs/doc/85/1-05.ps.gz.

By johnwcowan at Mon, 2008-02-18 23:43 | login or register to post comments

Doh!

I forgot to fill in the link URLS. Fixed.

By George Morrison at Tue, 2008-02-19 06:02 | login or register to post comments