My opinion? Lisp is prefix FORTH. That hit me right off the bat when
I started learning Lisp. Similar (for a beginner) experience of
working with symbol table + interpreter.
Prefix requires full parenthesisation, whereas postfix requires no
parenthesisation, and FORTH opted not to put in parenthesisation.
Full paranthesisation leads to comprehensible complex operand
arrangements. Despite so many '))))' happening, folks can parse out
what the operators and operands are. That gets hard in postfix
without parenthesis. So operators stay fairly simple. Lisp could
grow larger and more complex due to the paranthesis. Also Lisp had
academic attention and bias in its favor for developing complexity.
Although nobody could claim FORTH has not been successful! Its goals
were less lofty from the start, I think.
Notice that Chuck Moore, developer of FORTH, took a class on Lisp from
John McCarthy before developing FORTH.
fortunatus <daniel.elia...@excite.com> wrote on Tue, 8 Nov 2011 :
> My opinion? Lisp is prefix FORTH.
That's certainly one difference, but hardly the most important one.
> Prefix requires full parenthesisation, whereas postfix requires no
> parenthesisation, and FORTH opted not to put in parenthesisation.
If you think the two languages are basically identical, except that one
put the operators before the operands and the other put them afterwards
... you'll come away with a very broken impression of both Forth and
Lisp.
-- Don
___________________________________________________________________________ ____
Don Geddis http://don.geddis.org/ d...@geddis.org
Correlation may not cause causation, but they often occur together.
On 2011-11-08, fortunatus <daniel.elia...@excite.com> wrote:
> My opinion? Lisp is prefix FORTH.
The syntactic structure of a Lisp expression can be grasped even if you don't
know what it means.
If a Lisp expression adds two numbers X and Y together,
it usually looks like (+ X Y). This is a unit which stays together
even if you rearrange the rest of the expression.
None of the above holds in Forth. A Forth "expression" is just a sequence of
words. To know how they go together, you have to know their implementation.
An expression which adds together X and Y could have this in it:
X Y +
That's if you're lucky. In between these words, there could be arbitrary
quantities of other words, which will work if these sequences leave
the stack where it is, so that by the time we get to the +, it has
the value of X and Y on top of the stack:
X a b c d Y e f g h +
This is a kind of better assembly language for idiots savants.
The success stories on the Forth website are nearly all about trivial one-man
embedded projects, where Forth is an alternative to assembly language (and in a
good number of them, in parallel with assembly language).
To their credit some, some of the projects are mission-critical deployments.
But assembly language is also used in similar mission-critical deployments.
The Blub programmer working in Forth looks down at assembly language and sees
how Forth is so much easier to manipulate.
> Prefix requires full parenthesisation, whereas postfix requires no
Prefix does not require parenthesization when you fix the arity of every
operator:
* + x y + z w (x + y) * (z + w)
This is called polish notation, and the postfix mirror image of
that is reverse polish notation (RPN).
RPN is more prevalent because it can be processed from left to
right using a stack.
> Full paranthesisation leads to comprehensible complex operand
> arrangements. Despite so many '))))' happening, folks can parse out
> what the operators and operands are. That gets hard in postfix
> without parenthesis. So operators stay fairly simple.
Not only that, but more importantly, /programs/ stay fairly simple.
E.g. you don't see a workstation with mass storage, mouse+window GUI and
networking, programmed from hardware on up in Forth.
On Nov 8, 7:02 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> Prefix does not require parenthesization when you fix the arity of every
> operator:
> * + x y + z w (x + y) * (z + w)
Nice analysis on all points... of course, what the heck was I
thinking?? Even, I think, you can't do postfix without parens unless
you fix the arity of the operators, can you?
On Nov 8, 5:23 pm, Don Geddis <d...@geddis.org> wrote:
> If you think the two languages are basically identical, except that one
> put the operators before the operands and the other put them afterwards
> ... you'll come away with a very broken impression of both Forth and
> Lisp.
Oh, crikey! I believe I qualified the limits on my opinion pretty
well: "Similar (for a beginner) experience of working with symbol
table + interpreter."
Kaz Kylheku <k...@kylheku.com> wrote:
> Not only that, but more importantly, /programs/ stay fairly simple.
> E.g. you don't see a workstation with mass storage, mouse+window GUI and
> networking, programmed from hardware on up in Forth.
the HP48 & related calculators were quite substantially programmed in a
sort- of Forth. it's not really Forth though, and it certainly is hard to
write substantial programs.
I do think Forth is spiritually similar to Lisp in some ways though.
> the HP48 & related calculators were quite substantially programmed in a
> sort- of Forth. it's not really Forth though, and it certainly is hard to
> write substantial programs.
There are Forth machines, see greenarrays.com and ask on comp.lang.forth if
you're really interested. The previous poster's comments were incorrect and
uninformed.
> I do think Forth is spiritually similar to Lisp in some ways though.
How? They are dissimilar in fundamental ways. FORTH is based on a stack
machine and it's not meaningful when separated from the underlying
architecture. LISP is a complete abstraction from its implementation. FORTH
is fundamentally interactive, LISP is not, not fundamentally. FORTH is not
appropriate for everything, nor is LISP. When you use tools appropriately
you get the best results. The only general purpose languages are assemblers
and low-level languages like C, PL/I, PL/M. Any higher than that and a
domain specific language helps. Yes I can pound nails with a screwdriver but
no I don't have to.
Better to compare Factor and Lisp. Forth is simply too low level for
appropriate comparison. It is no type system whatsoever, for
instance, either run time or compile time. Obviously such could be
implemented, but that is not standard practice. It also lacks
facilities for higher order functional programming, which Joy/Factor
remedy.
Also, I wrote this stack language integrated into emacs lisp:
On Nov 9, 6:55 am, jvt <vincent.to...@gmail.com> wrote:
> Better to compare Factor and Lisp. Forth is simply too low level for
> appropriate comparison. It is no type system whatsoever, for
> instance, either run time or compile time. Obviously such could be
> implemented, but that is not standard practice. It also lacks
> facilities for higher order functional programming, which Joy/Factor
> remedy.
> Also, I wrote this stack language integrated into emacs lisp:
> But, again, its much more like Factor than Forth.
It also bears mention that Factor has stack-effect checking. When you
define a word, you also have to define the stack effect. If the
defined effect doesn't match the results of the definition, the word
won't compile.
Stack effect inference and checking is a really interesting aspect of
Factor which I wish Slava would write a paper about (maybe he already
has?) Checking stack effects is essentially like a very simple type
system, and so can serve as a kind of toy model for type checking and
inference.
Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net>
writes:
>> the HP48 & related calculators were quite substantially programmed in a
>> sort- of Forth. it's not really Forth though, and it certainly is hard to
>> write substantial programs.
> There are Forth machines, see greenarrays.com and ask on comp.lang.forth if
> you're really interested. The previous poster's comments were incorrect and
> uninformed.
>> I do think Forth is spiritually similar to Lisp in some ways though.
> FORTH is fundamentally interactive, LISP is not, not
> fundamentally.
Tim Bradshaw <t...@tfeb.org> writes:
> Kaz Kylheku <k...@kylheku.com> wrote:
>> Not only that, but more importantly, /programs/ stay fairly simple.
>> E.g. you don't see a workstation with mass storage, mouse+window GUI and
>> networking, programmed from hardware on up in Forth.
> the HP48 & related calculators were quite substantially programmed in a
> sort- of Forth. it's not really Forth though, and it certainly is hard to
> write substantial programs.
> I do think Forth is spiritually similar to Lisp in some ways though.
The programming language used in the HP-48 family of calculators is
called RPL - Reverse Polish Lisp.
+---------------
| Kaz Kylheku <k...@kylheku.com> wrote:
| > Prefix does not require parenthesization when you fix the arity of every
| > operator:
| > * + x y + z w (x + y) * (z + w)
| | Nice analysis on all points... of course, what the heck was I
| thinking?? Even, I think, you can't do postfix without parens unless
| you fix the arity of the operators, can you?
| | (LAMBDA (A B &REST C) ... )
+---------------
IIRC, PostScript [and maybe Smalltalk as well?] has a way of MARKing
the argument stack, and then APPLYing all of the args between the mark
and the top of the stack to a function. I forget the exact syntax,
but that's the effect. [I think the Adobe extension "pdfmark" does
approximately that: "mark <arg1> <arg2> ... <argn> <function> pdfmark"
is roughly (APPLY FUNCTION (LIST ARG1 ARG2 ... ARGn).]
Yes, it's not terribly uniform/orthogonal. Many of the mark-using
operators are named DOFUNCTIONTOMARK, e.g., "dicttomark", "cleartomark",
but not all (or even most?). Some take alists as args, e.g.,
"mark <key1> <value1> <key2> <value2> ... .dicttomark" ==> <dict>".
But as I said, I don't remember the exact details. (Anyone?)
-Rob
-----
Rob Warnock <r...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403
> IIRC, PostScript [and maybe Smalltalk as well?] has a way of MARKing
> the argument stack, and then APPLYing all of the args between the mark
> and the top of the stack to a function. I forget the exact syntax,
> but that's the effect. [I think the Adobe extension "pdfmark" does
> approximately that: "mark<arg1> <arg2> ...<argn> <function> pdfmark"
> is roughly (APPLY FUNCTION (LIST ARG1 ARG2 ... ARGn).]
> Yes, it's not terribly uniform/orthogonal. Many of the mark-using
> operators are named DOFUNCTIONTOMARK, e.g., "dicttomark", "cleartomark",
> but not all (or even most?). Some take alists as args, e.g.,
> "mark<key1> <value1> <key2> <value2> ... .dicttomark" ==> <dict>".
> But as I said, I don't remember the exact details. (Anyone?)
I never wrote much PS, but... On my old HP48G, there were commands of the form <stack> <N> <op>, where <N> specified how many parameters <op> would consume from <stack>. For example, ROLL would use this to determine how many levels of the stack to rotate.
> The programming language used in the HP-48 family of calculators is
> called RPL - Reverse Polish Lisp.
People often did call it that, I agree, though I think it's not clear if HP did. The expericne of programming in it, I found, was much more Forth-like than Lisp-like though. What I really meant though was that the HP48 was a kind of mini RPL-machine in the interesting Lisp-machine sense of being a fairly seamless environment built around a language, not the boring "executes the language directly in HW" sense.
Tim Bradshaw <t...@tfeb.org> writes:
> On 2011-11-09 20:40:26 +0000, Raymond Wiker said:
>> The programming language used in the HP-48 family of calculators is
>> called RPL - Reverse Polish Lisp.
> People often did call it that, I agree, though I think it's not clear
> if HP did. The expericne of programming in it, I found, was much more
> Forth-like than Lisp-like though.
Of course. The essential difference between lisp code and the other
programming languages, is that in lisp, you don't need to know the arity
of the operators (or the "priority" of the operators, there's no such
notion in lisp), since applications are always parenthesized.
This is the feature (with attendant homoiconicity) that makes macro
programming a breeze in lisp, but more importantly, that frees
programmer neurons for better programming. It allows lisp programmers
to read lisp code even without knowing thee operators used. On the
other hand, in forth or Postscript and even with languages with complex
syntaxes, you cannot read the code without knowing all the operators,
their arity, and their priority.
On 2011-11-10, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> to read lisp code even without knowing thee operators used. On the
> other hand, in forth or Postscript and even with languages with complex
> syntaxes, you cannot read the code without knowing all the operators,
> their arity, and their priority.
Note that even raw machine language in a disassembly dump does not
have this readability issue.
"On the other hand, in forth or Postscript and even with languages with complex syntaxes, you cannot read the code without knowing all the operators, their arity, and their priority."
That's not correct, as in Forth you don't need to know priority, as is the case for all stack based languages.
"Pascal J. Bourguignon" <p...@informatimago.com> wrote:
> Tim Bradshaw <t...@tfeb.org> writes:
> Of course. The essential difference between lisp code and the other
> programming languages, is that in lisp, you don't need to know the arity
> of the operators (or the "priority" of the operators, there's no such
> notion in lisp), since applications are always parenthesized.
Yes, that's right, I think: in Forth and RPL you don't have to worry about
priority, but you do have to know the arity, and that makes it hard, I
find.
> > FORTH is fundamentally interactive, LISP is not, not
> > fundamentally.
> What do you mean?
The first LISPs ran on IBM machines, in batch AFAIK and this was true for
many years. That is as far from interactive as it gets. You code something,
you punch it on cards, you submit a job to the operator, he runs it when he
gets a chance, it prints out, the operator hands you the printout when he
gets a chance. You fix what you mispunched or miscoded and try again.
There is nothing fundamentally interative about LISP.
FORTH is fundamentally interactive. That's how Moore designed it. You type a
command (word) or a definition for a word. The machine accepts it or flags
and error. You build your program step by step, interactively.
