Re: why forth over lisp?
Standish P
> I hate asking this question, but so far Ive read Leo Brodie's
> "Starting Forth" and a few other Forth tutorials and they all mention
> how Forth has very low level access to hardware that other languages
> dont have and how it is a operating system unto itself, but Im having
> trouble seeing this. To me Forth does the the exact same thing as
> Lisp, its a heirarchy of functions that nest within function and
> further into functions below that till you hit the lowest level
> functions which are machine instructions. But doesnt Lisp do the exact
> same thing? Lisp is made up of functions and these functions are
> themselves written in Lisp functions until they bottom out to
> barebones primitive functions that are part of the compiler. And Lisp
> compiles to machine language just like Forth so it can be quite fast.
> And also I dont see how Forth has any lower access than any other
> language like C. All these languages simply make OS system calls or
> interface with system libraries. Im sorry for asking this, but could
> anyone tell me what Im missing here?
You would never reach a fair understanding unless you hear from all
the sides by cross-posting to cll, cls and clc. I am interested in
hearing all sides so I am xposting it.
For the readers there, there are already 21 messages.
My take on this is as follows:
Forth is nothing but structured assembly.
One can write all the programming paradigms in assembly.
Forth inventor was at stanford and McCarthy was there, and most likely
in touch with the department since his graduation. He says that he
wrote algol compiler there.
All virtual machines, lisp, java etc use stack, so forth has no
monopoly over that. Only that they chose not to implement low level
access beyond, say print a character. Postscript, which is Forth, does
not have low level access to other devices except good access of
graphics.
Lisp and Forth are isomorphic in major concepts if not always in
implementations. People like Elizabeth consistently emphasize
differences in implementation without explaining clearly what they
actually are and how they do their thing in forth even if they dont
know about Lisp and Postscript.
Standish P
>
> - Show quoted text -
access beyond, say print a character [in Lisp].
John Passaniti
> My take on this is as follows:
Wow, you've packed a whole lot of wrong in one message. Allow me to
fix:
> Forth is nothing but structured assembly.
No, that's not a useful way to view Forth. Forth's interpreter allows
arbitrary extension and the process of extending Forth can allow
arbitrary semantics.
> One can write all the programming paradigms in assembly.
Eventually, yes. You can also write all programming paradigms on a
Turing machine, but you wouldn't want to. Your absurd reductionism
discounts the ease that languages bring to those paradigms. You can
for example write object oriented code in any language, but languages
that directly support object orientation are more pleasant,
productive, and expressive than languages that don't have such
features.
> Forth inventor was at stanford and McCarthy was there, and most likely
> in touch with the department since his graduation. He says that he
> wrote algol compiler there.
I am unaware of Charles Moore claiming to have written an Algol
compiler. His biography page on his web site does claim to have
written a Fortran-to-Algol converter, but it doesn't appear to have
been at Stanford.
> All virtual machines, lisp, java etc use stack, so forth has no
> monopoly over that.
False. The virtual machines in Lua, Python, Perl 6, and others are
not stack-based. Maybe using words like "all" isn't a good idea when
your knowledge clearly doesn't extend to "all". It might be said that
many or even most virtual machine architectures are stack-based, but
all are certainly not.
> Only that they chose not to implement low level
> access beyond, say print a character. Postscript, which is Forth, does
> not have low level access to other devices except good access of
> graphics.
Postscript is not Forth. It shares some concepts and flavor with
Forth, but is not Forth.
> Lisp and Forth are isomorphic in major concepts if not always in
> implementations. People like Elizabeth consistently emphasize
> differences in implementation without explaining clearly what they
> actually are and how they do their thing in forth even if they dont
> know about Lisp and Postscript.
This is vague. What specific "major concepts" are they "isomorphic
in"? Based on your previous messages, my guess is that in your zeal
to abstract away the important differences, you see "isomorphic"
commonality.
Paul N
> On Aug 14, 9:31 am, Brad Cantrell <cantre...@gmail.com> wrote:
> > I hate asking this question, but so far Ive read Leo Brodie's
> > "Starting Forth" and a few other Forth tutorials and they all mention
> > how Forth has very low level access to hardware that other languages
> > dont have and how it is a operating system unto itself, but Im having
> > trouble seeing this.
> > And also I dont see how Forth has any lower access than any other
> > language like C. All these languages simply make OS system calls or
> > interface with system libraries. Im sorry for asking this, but could
> > anyone tell me what Im missing here?
> Forth is nothing but structured assembly.
>
> One can write all the programming paradigms in assembly.
As I understand it, C has no equivalent of the "in" and "out"
instructions of the Z80 processor, so on a Z80 system it could
directly access any memory-mapped peripherals but not any of the (more
common) I/O mapped peripherals. The ZX Spectrum had IN and OUT
commands that could do this. I don't know whether Forth offers such
features or not.
> All virtual machines, lisp, java etc use stack, so forth has no
> monopoly over that.
I thought that a normal implementation of Forth required two stacks -
one for the programmer to keep values on and one for the computer to
keep track of where it had got to. C, by contrast, manages (in most
implementations) to use a single stack for both.
Standish P
> On Aug 21, 3:17 am, Standish P <stnd...@gmail.com> wrote:
>
> > My take on this is as follows:
>
> Wow, you've packed a whole lot of wrong in one message. Allow me to
> fix:
>
> > Forth is nothing but structured assembly.
>
> No, that's not a useful way to view Forth. Forth's interpreter allows
> arbitrary extension and the process of extending Forth can allow
> arbitrary semantics.
>
> > One can write all the programming paradigms in assembly.
>
> Eventually, yes. You can also write all programming paradigms on a
> Turing machine, but you wouldn't want to. Your absurd reductionism
> discounts the ease that languages bring to those paradigms. You can
> for example write object oriented code in any language, but languages
> that directly support object orientation are more pleasant,
> productive, and expressive than languages that don't have such
> features.
>
> > Forth inventor was at stanford and McCarthy was there, and most likely
> > in touch with the department since his graduation. He says that he
> > wrote algol compiler there.
>
> I am unaware of Charles Moore claiming to have written an Algol
> compiler. His biography page on his web site does claim to have
> written a Fortran-to-Algol converter, but it doesn't appear to have
> been at Stanford.
[BEGIN QUOTE]
Interviewer: Where did you learn to write compilers? Was this
something everybody at the time had to do?
Chuck: Well, I went to Stanford around ‘60, and there was a group of
grad students writing
an ALGOL compiler — a version for the Burroughs 5500. It was only
three or four of
them, I think, but I was impressed out of my mind that three or four
guys could sit down
and write a compiler.
I sort of said, “Well, if they can do it, I can do it,” and I just
did. It isn’t that hard.
There was a mystique about compilers at the time.
Interviewer: There still is.
Chuck: Yeah, but less so. You get these new languages that pop up from
time to time, and
I don’t know if they’re interpreted or compiled, but well, hacker-type
people are willing to
do it anyway.
The operating system is another concept that is curious. Operating
systems are dauntingly
complex and totally unnecessary. It’s a brilliant thing that Bill
Gates has done in selling
the world on the notion of operating systems. It’s probably the
greatest con game the
world has ever seen.
An operating system does absolutely nothing for you. As long as you
had something — a
subroutine called disk driver, a subroutine called some kind of
communication support, in
the modern world, it doesn’t do anything else. In fact, Windows spends
a lot of time with
overlays and disk management all stuff like that which are irrelevant.
You’ve got gigabyte
disks; you’ve got megabyte RAMs. The world has changed in a way that
renders the operating
system unnecessary.
Interviewer: What about device support?
Chuck: You have a subroutine for each device. That’s a library, not an
operating system.
Call the ones you need or load the ones you need.
[END QUOTE]
> > All virtual machines, lisp, java etc use stack, so forth has no
> > monopoly over that.
>
> False. The virtual machines in Lua, Python, Perl 6, and others are
> not stack-based. Maybe using words like "all" isn't a good idea when
> your knowledge clearly doesn't extend to "all". It might be said that
> many or even most virtual machine architectures are stack-based, but
> all are certainly not.
I said "use stack" and you talk of "stack-based".
>
> > Only that they chose not to implement low level
> > access beyond, say print a character. Postscript, which is Forth, does
> > not have low level access to other devices except good access of
> > graphics.
>
> Postscript is not Forth. It shares some concepts and flavor with
> Forth, but is not Forth.
>
> > Lisp and Forth are isomorphic in major concepts if not always in
> > implementations. People like Elizabeth consistently emphasize
> > differences in implementation without explaining clearly what they
> > actually are and how they do their thing in forth even if they dont
> > know about Lisp and Postscript.
>
> This is vague. What specific "major concepts" are they "isomorphic
> in"? Based on your previous messages, my guess is that in your zeal
> to abstract away the important differences, you see "isomorphic"
> commonality.
This is vague because corporatists wont bring in crisp explanations.
You gotta run after them and if they give you personally to keep less
circulation, still come and share.
They want you to worship the so called "CHUCK" and keep on buying
their scrap out of ignorance.
Elizabeth D Rather
> On 21 Aug, 08:17, Standish P<stnd...@gmail.com> wrote:
>> On Aug 14, 9:31 am, Brad Cantrell<cantre...@gmail.com> wrote:
>>> I hate asking this question, but so far Ive read Leo Brodie's
>>> "Starting Forth" and a few other Forth tutorials and they all mention
>>> how Forth has very low level access to hardware that other languages
>>> dont have and how it is a operating system unto itself, but Im having
>>> trouble seeing this.
>
>>> And also I dont see how Forth has any lower access than any other
>>> language like C. All these languages simply make OS system calls or
>>> interface with system libraries. Im sorry for asking this, but could
>>> anyone tell me what Im missing here?
>
>> Forth is nothing but structured assembly.
>>
>> One can write all the programming paradigms in assembly.
>
> As I understand it, C has no equivalent of the "in" and "out"
> instructions of the Z80 processor, so on a Z80 system it could
> directly access any memory-mapped peripherals but not any of the (more
> common) I/O mapped peripherals. The ZX Spectrum had IN and OUT
> commands that could do this. I don't know whether Forth offers such
> features or not.
Yes, Forth's @ ("fetch") and ! ("store") instructions can read and write
memory-mapped I/O ports. There are variants of @ and ! for the most
common sizes of data or port (8-bit, 16-bit, etc.). For platforms
without naturally memory-mapped I/O it's common to find P@ and P! (Port
fetch and store) commands, and for portability they are often available
as alternative names to their standard equivalents (most commonly C@ and
C! for 8-bit access).
>> All virtual machines, lisp, java etc use stack, so forth has no
>> monopoly over that.
>
> I thought that a normal implementation of Forth required two stacks -
> one for the programmer to keep values on and one for the computer to
> keep track of where it had got to. C, by contrast, manages (in most
> implementations) to use a single stack for both.
Yes. And both are directly visible and usable to the programmer,
provided the rules regarding them (especially the return stack) are
respected. The actual implementation and use of stacks in Forth and C
differ significantly.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
toby
> On Aug 21, 3:17 am, Standish P <stnd...@gmail.com> wrote:
>
> > All virtual machines, lisp, java etc use stack, so forth has no
> > monopoly over that.
>
> False. The virtual machines in Lua, Python, Perl 6, and others are
> not stack-based.
Actually Lua's VM is heavily stack oriented, if I recall correctly
from experiences embedding it in C/C++.
Alex McDonald
The LUA version 5 VM has 250 "registers" which are indices into the
current stack frame. None of the 38 opcodes has any stack-like
operations; http://luaforge.net/docman/view.php/83/98/ANoFrillsIntroToLua51VMInstructions.pdf
Albert van der Horst
Standish P <stn...@gmail.com> wrote:
<SNIP>
>
>One can write all the programming paradigms in assembly.
Is that can as in:
if there is a path, I can walk to the moon.
It's just one step behind the other, isn't it?
Have you actually tried writing a program?
It is tedious enough as it is.
<SNIP>
Groetjes Albert
P.S. I've written some non-trivial all-assembler stuff.
See my web site below.
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
>their scrap out of ignorance.
>
Mr. Standish and others, could you please sign your message.
Google is just a miniscule part of Usenet.
[I need to mess with the headers to find the poster, and even
some posters have no sender in the header that I can find.]
Groetjes Albert
Albert van der Horst
It is interesting what happens if they are not there.
A Forther will type (or start his program with)
"
CODE P! POP|X, DX| POP|X, AX| OUT|D, X'| NEXT, END-CODE
"
and get it over with.
More than anything this sets Forth programmers apart :
they actually have the confidence to do this
they actually have the expertise to do this
they actually do this
>Cheers,
>Elizabeth
Groetjes Albert
[Disclaimer: code shown is ciforth's postit-fixup assembler.
Actual code differs among Forth compilers.]
P.M.Lawrence
> On 8/21/10 5:45 AM, Paul N wrote:
.
.
> > I thought that a normal implementation of Forth required two stacks -
> > one for the programmer to keep values on and one for the computer to
> > keep track of where it had got to. C, by contrast, manages (in most
> > implementations) to use a single stack for both.
>
> Yes. And both are directly visible and usable to the programmer,
> provided the rules regarding them (especially the return stack) are
> respected. The actual implementation and use of stacks in Forth and C
> differ significantly.
The way I would describe it is that the data stack is directly visible/
accessible but the return stack is indirectly visible/accessible,
since to get at the latter you work through keywords that go via the
former. P.M.Lawrence.
John Passaniti
> [BEGIN QUOTE]
> I sort of said, “Well, if they can do it, I can do it,” and I just
> did. It isn’t that hard.
The quote is about Forth, not Algol. He's saying it wasn't hard to
create a Forth compiler. Your claim was that he wrote an Algol
compiler. You're wrong.
> > > All virtual machines, lisp, java etc use stack, so forth has no
> > > monopoly over that.
>
> > False. The virtual machines in Lua, Python, Perl 6, and others are
> > not stack-based. Maybe using words like "all" isn't a good idea when
> > your knowledge clearly doesn't extend to "all". It might be said that
> > many or even most virtual machine architectures are stack-based, but
> > all are certainly not.
>
> I said "use stack" and you talk of "stack-based".
And for some reason the semantic distance between "use stack" and
"stack-based" in some way validates your claim? Your statement was
that "all virtual machines [...] use stack." One presumes you're
talking about the fundamental execution model, and not something
completely trivial like "somewhere in the code, they use a stack."
So, you're either wrong or you're making a distinction that is so
trivial as to be useless.
> > This is vague. What specific "major concepts" are they "isomorphic
> > in"? Based on your previous messages, my guess is that in your zeal
> > to abstract away the important differences, you see "isomorphic"
> > commonality.
>
> This is vague because corporatists wont bring in crisp explanations.
> You gotta run after them and if they give you personally to keep less
> circulation, still come and share.
>
> They want you to worship the so called "CHUCK" and keep on buying
> their scrap out of ignorance.
I have no idea what you're talking about. And based on this thread, I
doubt you do.
John Passaniti
> > False. The virtual machines in Lua, Python, Perl 6, and others are
> > not stack-based.
>
> Actually Lua's VM is heavily stack oriented, if I recall correctly
> from experiences embedding it in C/C++.
Older versions of Lua (4.x and prior) did indeed use a stack-based
virtual machine. Version 5.0 was the first that switched to a
register-based virtual machine.
George Neuner
Lua 5 still is basically a stack machine - it's a variant of what's
generally called a "deep access" stack, in which the machine can
access "deep" stack elements directly. Lua's variation does away with
push/pop/etc. top-of-stack instructions.
George
John Passaniti
> Lua 5 still is basically a stack machine - it's a variant of what's
> generally called a "deep access" stack, in which the machine can
> access "deep" stack elements directly. Lua's variation does away with
> push/pop/etc. top-of-stack instructions.
That's not how the authors characterize it: http://www.lua.org/doc/jucs05.pdf
I think there may be some confusion here between the C interface to
Lua (which does use a stack) and the execution model for the Lua VM
(which is a register-based VM).
George Neuner
<john.pa...@gmail.com> wrote:
>On Aug 23, 12:18 pm, George Neuner <gneun...@comcast.net> wrote:
>> Lua 5 still is basically a stack machine - it's a variant of what's
>> generally called a "deep access" stack, in which the machine can
>> access "deep" stack elements directly. Lua's variation does away with
>> push/pop/etc. top-of-stack instructions.
>
>That's not how the authors characterize it: http://www.lua.org/doc/jucs05.pdf
Actually, that's exactly how they characterize it. See page 11:
"... This register-based machine also uses a stack, for allocating
activation records, wherein the registers live. When Lua enters a
function, it preallocates from the stack an activation record
large enough to hold all the function registers. All local variables
are allocated in registers. ..."
Lua 5 "registers" are slots in the function's stack frame and the VM
instructions index them directly. Deep-access stack.
George
Alex McDonald
> On Mon, 23 Aug 2010 09:46:32 -0700 (PDT), John Passaniti
>
Reminds me of the activation records in IBM S/360/370. I can't
remember ever calling them deep-access stacks...
Nick
> Lua 5 still is basically a stack machine - it's a variant of what's
> generally called a "deep access" stack, in which the machine can
> access "deep" stack elements directly. Lua's variation does away with
> push/pop/etc. top-of-stack instructions.
I find it hard to attach the term "stack" to something that doesn't have
"push/pop/etc". That is, to me, what makes it a stack rather than some
other sort of data structure.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Duane Rettig
> George Neuner <gneun...@comcast.net> writes:
> > Lua 5 still is basically a stack machine - it's a variant of what's
> > generally called a "deep access" stack, in which the machine can
> > access "deep" stack elements directly. Lua's variation does away with
> > push/pop/etc. top-of-stack instructions.
>
> I find it hard to attach the term "stack" to something that doesn't have
> "push/pop/etc". That is, to me, what makes it a stack rather than some
> other sort of data structure.
Think of a stack as a LIFO (Last In, First Out) queue. The question
is: what is going in and out? In this day and age of cache
management, a push/pop of a single natural word (4 or 8 bytes) is
ludicrous for performance, especially when the movement of the stack
pointer is sometimes accompanied by extra checks and/or guard page
faults. So think of a higher level program which uses activation
frames as a cached stack, which beef up performance in the area of
stack access. The frames are still layed into memory in LIFO fashion
(with exceptions, of course, like non-local exits and, in some
languages, Continuation Passing Style, but this does not remove the
importance of the stack at the lower level.
Duane
George Neuner
It is an example of a stack activation record.
>I can't remember ever calling them deep-access stacks...
The term "deep access" comes from stack machine literature. In their
pure form stack machines only address the "top" of the stack with
push/pull/peek instructions. "deep access" variant stack ISAs allow
more generalized stack relative addressing.
Most everybody here knows this following, but for the sake of
exposition:
Virtually all CPUs allow stack relative addressing ... but as the
stack grows and shrinks the offset to any particular stack resident
datum keeps changing. This is why the function call sequence for most
CPUs reserves a "framing" register so that stack elements can be
addressed using fixed offsets even as the stack top changes.
By using fixed size activation records and disallowing code to use the
stack for temporary dynamic storage (alloca et al), stack relative
addressing is just as easy as frame relative. This somewhat
simplifies ISA by removing a required register and makes it easier to
map a virtual machine onto real hardware.
Most decent C compilers have the option to not use explicit framing.
It places some minor limitations on the code but for that you gain a
general index register which can be helpful on register starved
architectures like x86. (And even on 68K ... sometimes you really
need that 7th address register 8-).
George
George Neuner
<3-no...@temporary-address.org.uk> wrote:
>George Neuner <gneu...@comcast.net> writes:
>
>> Lua 5 still is basically a stack machine - it's a variant of what's
>> generally called a "deep access" stack, in which the machine can
>> access "deep" stack elements directly. Lua's variation does away with
>> push/pop/etc. top-of-stack instructions.
>
>I find it hard to attach the term "stack" to something that doesn't have
>"push/pop/etc". That is, to me, what makes it a stack rather than some
>other sort of data structure.
Well, its a stack of activation records rather than a stack of
individual elements.
George
Nick
I've got absolutely no problem with that - but I'd say you push and pop
activation records on and off the stack.
I often push records onto stacks in C - linked lists of structures.
It's still a stack and it's still pushing and popping to me.