Re: PUSH structure versus visualization

[Margot Flowers <Flowers at YALE>]

     it is nice to have a kind of visual concordance between list structure
     AS IT IS VISUALIZED (prints out) and the functions that manipulate list
     structure.  That, after all, is one of the main virtues of backquote;
     the lists it constructs look like the code you write.

Actually, I should have emphsized structure over visual order.  That is,
the structure of the function's s-expression should (in my mind) reflect
the structure of what is being constructed.  Necessarily this shows up in
the visual representation of that s-expression.

-----
In-Reply-To:  Pitman's message of 20-May-82 4:26PM-EDT (Thu)

     ...  Any argument based on reflecting the internal representation
     of anything is suspect.  ...  I think Margot's idea of worrying
     about making code reflect internal detail is a bad one.  -kmp

I agree with most of his argument except for the conclusions.

Having code depend upon the internal format (which I do not advocate) is
not the same as using your MODEL of that structure to help remember how to
use the functions which are applicable to that structure.  The internals
are unimportant as long as it behaves according to the model.  Like it or
not, people do use models to keep straight otherwise disconnected rules,
and when models are not provided, that people construct them.  For this
reason, it is unrealistic to say that:
     the only thing you should really have to know about PUSH is
     that (PUSH loc x) followed by (POP loc) gives you back x and
     returns the contents of loc to the state it had before the PUSH.
If a model is suggested, and the available functions are not consistent
with that model, then programming errors will result.  As long as you talk
about PUSH and POP I'm going to think of stacks, and of lifo lists.  Even
if the PLIST internals are different, I'm going to think of a list of
associated property-names and values.  Thus, a design as consistent as
possible with the models people use makes a language easier to use.  (But
my code will use PUT and GET etc. rather than CAR and CDR to access
plists.)

Besides, when I constuct my own structures, I cannot be ignorant of their
structural properties even though I don't write my code to depend upon
them.

-----
As far as English usage goes, if a function name has a clear English
meaning, then that should be exploited in the language design, it is either
that or confusion.  If the language design differs from English usage, then
don't use English.