[I am responding, though not in a very good mood]
"billy" <wtanksleyjr@[EMAIL PROTECTED]
> wrote in message
news:be2b1c4e-6ed1-4bbe-af99-854697fcddd9@[EMAIL PROTECTED]
> "cr88192" <cr88...@[EMAIL PROTECTED]
> wrote:
>> "billy" <wtanksle...@[EMAIL PROTECTED]
> wrote in message
>> > "cr88192" <cr88...@[EMAIL PROTECTED]
> wrote:
>> >> yes, RPN has uses, but I will argue, is still not the best model for
>> >> general programming.
>> > syntax type). I do think that RPN is as useful as any other syntax
>> > type, but simply less studied and formally understood. Oh, and it's
>> > also useful in different specific areas than the areas in which infix
>> > or prefix are useful.
>
>> yes, I will agree to this.
>> where it works very well, IMO, is in many of the same kinds of places
>> that
>> assembler works well...
>
> Assembler works well in precisely one place: as an extremely low-level
> approach to a specific microprocessor. There are (currently) no major
> microprocessors that use RPN, so RPN cannot possibly work well in that
> niche. Therefore you can not possibly mean that.
>
no, but RPN is far lower level than their AST based languages, as RPN is
very much closer to the way the machine works, than is an AST.
a single pass conversion is all that is needed (in the simple case) to
really convert an RPN language to raw machine code.
a higher level language (such as C or C++), ends up requiring a large
stack
of various compiler stages (mine currently uses a 5-stage system, but I
may
need to add in a 6th stage), and some of these stages operate in multiple
p***** as well.
> I _think_ what you're trying to say is that RPN is inherently low-
> level. I disagree. Postscript is an example of a high-level RPN
> language; although not strictly well designed, it operates at a 'page
> layout' level of abstraction. Enchilada, Joy, and Cat are more
> carefully designed examples of high-level RPN languages (even though
> the author of Cat originally thought as you do, that RPN was good only
> for intermediate languages).
>
I still believe this, that RPN is primarily useful for ILs, and IMO,
somewhat lower-level than plain AST languages (such as Scheme).
>> >> so, the downfall of forth is not that it is 'unnatural', but rather
>> >> that
>> >> no one can really read and follow the code...
>> >> one has to 'study', even their own code in a language they may know
>> >> well,
>> >> just to figure out what the hell they were doing.
>
>> > This is not necessarily so in general; and to the extent that it is
>> > true for specific cases, it's true for all language types.
>
>> I will disagree, in that I find some forms of syntax to be more easily
>> understandable than others, for different arguably subjective reasons.
>
> That's reasonable. Of course, what I said is theoretically true; but I
> understand that your personal experience leads you to add that in
> practice, it might not be the whole story. The problem is that you're
> attempting to prove a negative, "there is no RPN language such that
> there are nontrivial problems/solutions which can be expressed more
> clearly in it than in any other language format." You can't do that;
> all you can do is offer your experience.
>
I am not saying that RPN is the worst of syntax styles, but rather, that
IMO
the styles used in languages that have actually gained popularity, these
are
the styles worth the most consideration.
if something catches on quickly and it becomes stable, then it has done
something right.
if it has the right position, but never really gains much more than niche
popularity, then it is not doing something right...
IMO, C did something right, and so did C++.
C# and Java, IMO, have a few flaws, and are likely kept going partly by
the
powers of commercial life-sup****t, but still have some good points worth
consideration...
> I can offer mine. I assert that I have implemented clear solutions to
> nontrivial problems in RPN languages.
>
but, can people readily look at and understand your code?...
and, about how large of a project?...
50 kloc, 100 kloc, 500 kloc, ?...
> I further assert that there is a theoretical background for WHY
> certain things are easier in an RPN language. That background is
> discussed on the Yahoo group named 'concatenative', and the theory is
> explained on the first website that explored the issue,
> http://www.latrobe.edu.au/philosophy/phimvt/joy.html
(there are many
> other places to go now, but that's a fine start).
>
potentially.
>> as far as the languages themselves go, C, C++, and Java, are almost
>> universally understood, which means, again, that there is strong reason
>> to
>> emulate them.
>
> You're absolutely right here. When language acquisition time trumps
> problem solving time, one should stick with an already-acquired
> language, regardless of whether some other language might
> hypothetically solve the problem in less time.
>
> But you haven't shown or claimed that this is always, often, or even
> _sometimes_ true.
>
this was another point.
I also think that the issue is partly circular as well:
these style languages are accepted because they are understood, and have
things they have done well;
there is strong reason to emulate them, because they are understood.
so, languages rise and fall. the ones that rise, do something notable, and
fall when generally superseded.
and many languages appear, maybe even with glory and thunder, but never
really gain much apart from some narrow niche, or promptly fall into
oblivion...
after all, RPN has done at least 'something' right, because we are, after
all, still talking about it.
but, what it has done well has been very different than what the C family
has done well...
it is like comparing a bicycle, a car, and a cruise ****p...
>> one of the major problems I have found before with RPN is the
difficulty
>> in
>> breaking and indenting things in a more or less "sane" manner (due in
>> large
>> part to the non block-and-statement style structuring of such
languages).
>
> This is very telling, and I think illustrative of many people's
> problems with RPN.
>
> Because RPN languages have no blocks, they get lost on how to indent
> their blocks. The answer is: you can't solve a problem that doesn't
> exist. Stop trying.
>
> Let me explain.
>
> Block indentation was invented to solve the problem of how to present
> a 2-dimensional structure (a parse tree) using a 1-dimensional medium
> (a stream of text). By using whitespace (space, tab, newline)
> carefully, we manage to display that 2-dimensional structure very
> neatly. Of course, there are flamewars over the proper use of it,
> since it's only an approximation...
>
> But the parse structure of an RPN language is a flat list. There's no
> 2D structure to display. The optimum format for a definition is a
> single line.
>
> And there's your solution -- don't write multiline functions. One line
> should be the norm. I'm not telling you how long your one line should
> be here; that's a different issue that won't be decided based on
> purely syntactic considerations.
>
and, at the same time, this gain/limitation, since it limits formatting,
also nearly destroys using the formatting as a quick and dirty way of
mentally processing large chunks of code at a time.
> Pleasantly, this solution eliminates an ambiguous point in block
> structured programming language: in those, you have to balance between
> using indentation to display the parse tree, and using indentation for
> other purposes (for example, to group arbitrary statements together).
> In an RPN language, you don't have to choose; you can use indentation
> for other purposes, because it's not used otherwise.
>
and, again, the above.
the C family's readability depends in large part on its formatting, and
failure to indent sanely seriously hurts readability. in a language
without
the ability to indent sanely (or, almost mechanically), it is also not
possible to achieve this same level of readability.
one has to read the code linearly, rather than a whole block of code at a
time (more of an outward-inward style).
to a lesser extent, English has this same problem, which, along with its
highly inconsistent semantics, makes reading english far more tedious and
painful than reading code...
> -Wm
|
