Re: choice of character for relational division

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? If so, then join is overloaded (supports different relation types) and so is "=" (usuallty supports all kinds of different types besides relational ones)!

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.

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.

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.

p Received on Mon Apr 02 2007 - 02:58:41 CEST