Re: choice of character for relational division

On Apr 1, 5:58 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> Marshall wrote:
> > ...
> > It's a design issue. There is a balance to be struck. On the one
> > hand, attempting to completely avoid any overloading of any
> > character is going to lead to something that is wildly verbose,
> > and probably not very readable. On the other hand too much
> > overloading and programs start to look like line noise, and
> > again readability suffers.
> > ...
>
> Isn't any operator that supports multiple types overloaded?

That's the conventional parlance.

For myself, I'm beginning to distinguish between two cases that are usually lumped together: a function/operator that has different parameters and/or different semantics, vs. one that is simply supporting different type but keeping the attributes and semantics the same. The first case is logically overloaded; the second case is not, and may or may not be physically overloaded.

An example of the latter being + defined on integer and rational, for example.

> If so, then
> join is overloaded (supports different relation types) and so is "="
> (usuallty supports all kinds of different types besides relational ones)!

The usual parlance there would be to say that join is not overloaded, but rather that it is defined on a parameterized (or "generic") type: relation in this case.

> I've used languages where I had to type 'OR' and 'AND' and being
> something of a touch typist, at least for the letter alphabet, I found
> those faster to type without error than '&' and so forth (in fact, I'm
> using a Mac keyboard right now, the keys are a little filthy and I can't
> seem to find the vertical bar for 'or'). But I realize this is also
> cultural, for many years I wrote nothing but assembler where 'or' and
> 'and' were opcodes.

Sure.

> If it is a cultural kind of choice, then I think that is a good argument
> for engines to come with run-time start-up options that let people
> over-ride op symbols and replace them with anything they want including
> multi-character mnemonics. I really don't see why it is something that
> a parser must cast in stone.

There is a danger, though, at least in an industrial setting. If some guy is working alone, there's no reason for him not to tweak everything just the way he likes it. But if it's a team of 100, then probably it *should* be cast in stone or we'll get the Tower of Babel.

The Holy Grail of this sort of thing would be if it was possible for everyone to see code in exactly the format they like. There are actually a lot of subtle problems with trying to make this happen, and my feeling is that it's a lot of work to solve a problem that really isn't much of a problem.

> What would be more important to me is a language that is susceptible to
> (limited) mechanical analysis, in the sense that it has tools to
> identify tables used and so forth as well as to rename components of
> definitions such as attribute names.

Hear hear!

Marshall Received on Mon Apr 02 2007 - 03:46:51 CEST