Re: choice of character for relational division

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:5zYPh.15514$6m4.4187_at_pd7urf1no...
> 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.
>

Single user customization is also a cultural choice. Too much capability of overrides allows
the proliferation of dialects. This raises havoc with code legibility across the community of experts in the language. Can you imagine trying to help someone with his incorrect or inefficient code when you have to learn his dialect before you can read what he wrote?

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

I think the language aware source code editors are good for this.

> p
>
Received on Mon Apr 02 2007 - 07:20:35 CEST