"Jerry Avins" <jya@[EMAIL PROTECTED]
> wrote in message
news:0qadnRaZILrcj97anZ2dnUVZ_rOqnZ2d@[EMAIL PROTECTED]
> cr88192 wrote:
>> "Jerry Avins" <jya@[EMAIL PROTECTED]
> wrote in message
>> news:XLGdnQv36Ipbid_anZ2dnUVZ_jqdnZ2d@[EMAIL PROTECTED]
>>> cr88192 wrote:
>
> ...
>
>> but, what I am talking about is not what is "natural", but "generally
>> superior".
>
> I must have misread you. By what criterion is infix "generally superior"
> to RPN?
>
> ...
>
one reason:
spatial associativity (operators are often between what they relate to);
tradition (people have long since used such conventions);
abstraction (the syntax is not necessarily tied to the underlying
machinery);
....
>> so, the question is not, which is more natural, but which is better...
>
> Please define "better". Better for what?
>
better for humans.
machine cost can be ignored, as can parser/complier complexity (usally
only
much worry to compiler writers);
....
so, the question is, what "looks" best, and what form requires the minimal
level of mental involvement to process.
for example, if one can just quickly scroll the code past and know about
how
it works, that is good.
if one actually has to 'read' the code (aka: a good solid look, not just a
quick glance before they next press 'page down'), that is not so good.
for example, a good deal of readability is contained in the use of braces
and indentation.
if the braces or intendation are not right, or spaces are used or not used
in some unusual way, then code readability is greatly reduced, and one has
to actually read the code.
but, at least, the uses of braces and indentation as the major cues is
possible.
>> think conservatively...
>>
>> if for no other reason than this, this is how things are.
>>
>> is the 8 bit byte any more "natural" than a 12 bit one?...
>> yet, if someone suggests that the entire industry goes over to 12 bit
>> bytes, we regard the person as uninformed...
>
> The C compiler for one embedded processor I use has 16-bit bytes. The
> compiler for another uses 32-bit bytes. With it, sizeof(long) is 1.
>
true, but note that, in general, compilers for such archs often 'fake' the
good old 8 bit bytes.
if these bytes are not maintained, our fileformats break, and everything
is
thrown into chaos...
>> if one understands conservativism, and gradual refinement, one may well
>> understand syntax...
>
> Interesting. Would you mind expanding on the link between syntax and
> gradual refinement? You might think of RPN as a refinement of infix that
> avoids ambiguity. Infix requires disambiguation rules; RPN does not. In
> some infix languages, 2+3*4 is 20, in others, 24. Is that "better"?
>
well, infix also carries the assumption of precedence ordering.
now, it can be noted that right and left associative languages are nearly
universally rejected.
as such, any valid infix language would follow good old PEMDAS, in one
form
or another.
most C family languages follow the C style precedence ordering, even
though
IMO, a slight reorganization would make sense (bitwise operators being put
at at least similar precedence to arithmetic operators, ...).
but, no, I say, modern C style syntax is the refinement of K&R style C
syntax, which is a refinement of B, which is a refinement of BCPL, ...
look at FORTRAN or ALGOL code, and it is just ugly.
FORTRAN, with its ad-hoc structure and brittleness;
ALGOL, with all its words (we need structure, not words, structure for
syntax and words or letters for variables and objects...).
look at newer langs, like C#, and the syntax is much cleaner than, say,
C++...
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
> ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
|
