Обсуждение: list macro names
I will, of course, be running pgindent on the source just before beta. I would also like to change a few of list macro names that I can never remember, and I am sure others have the same problem. --------------------------------------------------------------------------- lappend is good lcons should be ladd (adds to the front of the list, while lappend adds to end nconc should be lconcat, because it concats two lists lconsi becomes ladd_int lappendi becomes lappend_int nreverse becomes lreverse set_difference becomes set_difference_int --------------------------------------------------------------------------- What do people think? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> I would also like to change a few of list macro names that I can never
> remember, and I am sure others have the same problem.
> lappend is good
> lcons should be ladd (adds to the front of the list, while lappend adds to end
> nconc should be lconcat, because it concats two lists
> lconsi becomes ladd_int
> lappendi becomes lappend_int
> nreverse becomes lreverse
Ack! As you know from looking at the comments in the code, the original
Postgres was apparently written in Lisp. All of the list-oriented
behaviors and conventions date from that time.
I've spent quite a bit of time with the parser especially, and would
like to not have to learn other obscure names. Why bother changing them;
the new names can't _that_ much clearer unless we move to Cobol. Let's
see...
lappendi becomes append_list_and_integer
...
Besides, I'm now working on a large project in Lisp, so this stuff seems
more normal than it did before.
In case I'm being to subtle: I'd strongly prefer leaving these things
alone for now :)
- Tom
> > I will, of course, be running pgindent on the source just before beta. > > I would also like to change a few of list macro names that I can never > remember, and I am sure others have the same problem. > > --------------------------------------------------------------------------- > > lappend is good > > lcons should be ladd (adds to the front of the list, while lappend adds to end But 'cons' is the absolute standard lisp nomemclature for this. And all these operations are part of the lispish heritage of postgres. > nconc should be lconcat, because it concats two lists > > lconsi becomes ladd_int And this adds an integer arithemetically or listwise? Not less confusing, just a different confusion. > lappendi becomes lappend_int > > nreverse becomes lreverse > > set_difference becomes set_difference_int Why is this more clear? What is next, Hungarian notation? > What do people think? I think we should not rework code that everyone is getting used to unless there is some functional reason. -dg David Gould dg@informix.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 - If simplicity worked, the world would be overrun with insects. -
> > > > I will, of course, be running pgindent on the source just before beta. > > > > I would also like to change a few of list macro names that I can never > > remember, and I am sure others have the same problem. > > > > --------------------------------------------------------------------------- > > > > lappend is good > > > > lcons should be ladd (adds to the front of the list, while lappend adds to end > But 'cons' is the absolute standard lisp nomemclature for this. And all these > operations are part of the lispish heritage of postgres. > > > nconc should be lconcat, because it concats two lists > > > > lconsi becomes ladd_int > > And this adds an integer arithemetically or listwise? Not less confusing, just > a different confusion. > > > lappendi becomes lappend_int > > > > nreverse becomes lreverse > > > > set_difference becomes set_difference_int > > Why is this more clear? > > What is next, Hungarian notation? > > > What do people think? > > I think we should not rework code that everyone is getting used to unless > there is some functional reason. > > -dg > > David Gould dg@informix.com 510.628.3783 or 510.305.9468 > Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 > - If simplicity worked, the world would be overrun with insects. - > OK, I seem to the only one who wants the change. They stay as is. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)