"billy" <wtanksleyjr@[EMAIL PROTECTED]
> wrote in message
news:a25801be-161b-4d0e-b936-8c643e3c4a15@[EMAIL PROTECTED]
> "cr88192" <cr88...@[EMAIL PROTECTED]
> wrote:
>> [I am responding, though not in a very good mood]
>
> There's no rush. Life is more im****tant than Usenet.
>
>> "billy" <wtanksle...@[EMAIL PROTECTED]
> wrote:
>> > 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.
>
> The question of high-level can't be how close the language is to the
> machine, but how close the language can be brought to the problem/
> solution domain (and how many obstacles it puts in your way while
> bringing it to that level). High level languages are nice because they
> allow you to think in the problem/solution domain, NOT because they
> force you to think differently from the computer.
>
> Think about that last phrase: if a language forces you to think
> differently from how the computer works, the 'natural' ways to do
> things in the language will be non-natural for the computer to do. In
> other words, your programs will be slow and bloated.
>
not necessarily.
ammusingly, I have found, higher abstraction leads to smaller and more
efficient code. why? because it can give the compiler far more room to
make
decisions and reorganize things.
for example, in my RPNIL language, I end up feeding in far more input than
I
get output, why? becuase most of the input drives the compiler machinery,
which only generates instructions when needed.
for example, 'exch', does this need to generate any output instructions?
not
necessarily. the compiler may realize it has 2 values that can be swapped
absent generating any inteructions, so, the change happens in the
compiler,
and not in the output.
similarly, SSA or CPS is more abstract than assembler, yet we can often
get
a whole lot more effort in compiling first to SSA, and having SSA work out
the details, than compiling directly to assembler.
I do agree on the point though that higher-level is useful for putting one
closer to the problem domain. this is after all why I so much like C style
syntax. one can, if they want, give even very difficult concepts very
terse
syntax, for example, my compiler also has vector geometry and quaternion
math as builtin parts of the compiler.
this pays off, as I can generate much faster vector code than I can
currently get out of gcc...
>> 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
>> passes as well.
>
> Yes, you can build a Forth compiler that does all of this. You don't
> have a parsing stage or a liveness analysis stage, but all the rest is
> still there. Register allocation is a bit easier because your
> dataflows are prioritized by their order on the stack, but that
> doesn't make it trivial.
>
maybe.
luckily, I use a stack machine as the basic model in my compiler (reason:
I
find the stack concept a lot easier to work with than, for example,
directly
with SSA). additionally, it is also not too difficult to convert from a
stack machine to CPS (I was hypothetically considering this idea
recently).
> Anyhow, as I mentioned above, you're approaching the question
> backwards.
>
possibly, one can argue this.
>> > 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).
>
> Do you find my definition of 'high-level' at all useful?
>
> Given my definition, would you agree that "plain AST" is not innately
> lower-level than fancy AST? For example, compare a scheme-syntax for
> Prolog to the classical Prolog syntax. Which one is lower level? I'd
> say they're both about the same level, but one has a simpler syntax.
>
S-expressions are painful to type and ugly to look at, IMO...
none the less, one of my compiler stages does work primarily in terms of
an
S-expression like representation (this is prior to converting it to RPN).
the possibly considered future stage, would likely be placed between the
S-Expr and RPN stage, where I am considering, instead of converting
directly
to RPN, I use the S-Exps in effect to drive a secondary stack machine,
which
will mimic some of the behavior or the RPN machine in the upper compiler.
this would provide far more powerful typeflow information (the upper
compiler currently does little to no type-flow based processing), and
would
allow the addition of some more advanced features (aka: me implementing
languages more "advanced" than plain old C).
the other possibility would be to add them to the lower compiler,
requiring
the nature of the RPN to be changed (currently, it is essentially passive,
but the change would require me to add full turring completeness and
metaprogramming abilities to the lower compiler, turning it into a far
more
complicated and monolithic beast than it is already...).
>> 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.
>
> That depends on your purposes and goals. In order to make that
> decision, you can't start out with inaccurate statements like "RPN is
> low level".
>
'low level' does not necissarily mean 'worse' in my rules, but I do have
more than my own fair amount of experience and observation. even if my
views
were to change and I was to view RPN as the one true syntax, few others
would, and I would be making more stuff with almost no real chance at
acceptance.
my definition of level is primarily that of abstractness.
the more abstract the syntax, the more power it can weild.
> By the way, do you know why RPN was invented? It was designed as a
> mathematical notation to get rid of ambiguities in the old style
> infix. In other words, it was designed to solve a problem in
> mathematics, not to run efficiently on machines. As such, it is a high-
> level notation. Forth was designed to run efficiently on machines;
> it's a low-level notation. Postscript was designed to format printed
> pages; it's a high-level notation. Three different RPNs; three
> different levels.
>
and, what happened?...
RPN did not move in the direction of more abstractness, rather, in the
direction of less.
an abstract mathematical syntax would be one where nearly every idea was
hidden away and what was going on, or even what one was looking at,
depended
almost entirely on context (but, not ad-hoc, rather, it will be a context
so
subtle that we don't even see there is a difference).
abstractness is in the direction where we realize that the complex and
vector spaces are unified under quaternions, and we no longer worry about
exact type.
non-abstractness is where we have numerous different integer and floating
point types, and have to worry about which operations will be used.
and, the stack model, whatever it can offer, can't abstract away itself...
> (I must add that Forth is more flexible than Postscript; it's intended
> to be general purpose. Thus, it can quickly become higher level than
> Postscript.)
>
ok.
>> 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.
>
> Correct. This doesn't (or mustn't) make them invulnerable, though.
>
true, but conservativism is needed, not revolution.
as is, the computer industry already too much emphasized "new" and
"different".
so, what is new needs to be based on what is old, moving in the direction
of
ideal.
>> but, what it has done well has been very different than what the C
family
>> has done well...
>
> Yup.
>
>> >> 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.
>
> This is very im****tant.
>
>> > 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.
>
>> > 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.
>
>> 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.
>
> This gain _removes_ the limits from formatting, because it removes the
> need for format according to the language's built-in rules (which are
> by definition low-level) and allows you to format according to your
> problem domain.
>
but, this is a major part of the problem as well...
if we format different, it looks different.
unity, not divergence.
> If your problem domain doesn't need rules, don't have any formatting.
> If it needs them, follow them. Nothing gets in your way.
>
rigid formatting rules and structure are actually part of the gain, not a
cost.
>> > 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,
>
> No. Compare all the different indentation styles (K&R 1, BSD, GNU,
> ANSI...). They're all readable once you're used to them; they're also
> radically different. C requires formatting by nature; it doesn't
> specify what that formatting is. (Python does specify formatting.)
>
yes, and I totally dislike code formatted differently than I like it
formatted, because then it is a lot harder to read.
now, as for python, it has a gain and a cost. sometimes we *need* a little
more freedom when it comes to formatting, and C-style syntax does not make
formatting a "set in stone" issue.
and, sometimes, readability is improved by making the formatting worse...
>> 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.
>
> Writing in a stack language does not destroy the programmer's ability
> to indent. Nor does it seriously impair the programmer's sanity (what
> did you mean by that?).
>
indentation is not nearly so clear-cut of an issue, and thus can lead to a
lot of variation and chaos wrt formatting.
>> one has to read the code linearly, rather than a whole block of code at
a
>> time (more of an outward-inward style).
>
> But nobody writes code like this. You put the definition name at the
> left margin, and the definition body stretches to the left. Ideally
> there's only one line in the definition, so skip it if you don't want
> the details (just trust the function name and the comments). If you do
> want the details, read the single line.
>
not write, read.
one writes code by thinking in terms of expressions and lines, and
sometimes
blocks.
one reads by reading a whole mass of code at a time (by page-downing or
scrolling through it).
every so often, I encounter a new project and want to know about how it
works. I scroll through much of the code of a project and get a general
idea.
I often don't much use or read comments, as I can usually process the code
chunks faster than I can the comments.
and, later on, what all I read beats around in my head some (doing
whatever
magic it does), and I more or less understand the project and much of its
workings.
>> 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...
>
> Reading an English novel is _quick_. Reading an English law is _slow_.
> In one case you're skimming for meaning; in the other you're parsing
> for deep consequences. But if you're not familiar with English,
> skimming is not an option; you have to spend your time figuring out
> the grammar rather than understanding the meaning.
>
I am slow with English, even though I am a native speaker and have been
reading and writing the language all my life...
I don't often read novels though, as this is too long and tedious for not
much gain (in terms of usable information and so on).
I like text I can read quickly and understand easily, aka, a lot of
technical stuff.
I get annoyed with the horridly long-winded and verbose styles often found
in standards documents (ITU is especially bad in my book, with ISO being
in
the middle, and W3C and the IETF often doing fairly well).
....
I don't really like ambiguous writing styles, albeit (sadly), I am one
apparently known for my ambigous, long winded, and often incomprihensible
writing style...
> You aren't familiar enough with any RPN language to be able to skim it
> yet. I am, and others here are. The fact that you can't do it yet
> doesn't mean it's hard to do.
>
maybe.
who can really judge this though?...
and, even if true, in what direct way does this have that much relevance
(if
one thinks on a large scale, in terms of the whole mass of programmers,
code, and languages)?...
> -Wm
|
