BR wrote:
>>Lisp refuses to be categorised. I think the closest you could get would
>>be to say that Lisp allows Domain Oriented Programming, meaning that
>>Lisp allows you to get as close to your problem as is possible, and
>>write your code in a way that makes it look like you have a language
>>that was designed specifically with your domain in mind.
If you ask me, Lisp can easily be categorized. It is an imperative
language with lots of features, like: higher-order functions, OO,
multiple return values, all kinds of control-flow operators, exceptions.
Its abstract syntax (well, trees of s-exps) allow you to define truly
powerful macros.
> Couldn't the same be said for Forth?
Forth is somewhat harder to categorize, IMHO. It is very low-level, in
that you have to express all dataflow on two explicit stacks. OTOH,
there's no implicit allocation, so you need no GC; you can define pretty
much anything you want as a word, including control.
I'd say Forth is the best ever language for embedded systems and allows
very nicely for data-oriented programming (create , does>) and has a
very tiny footprint.
Lisp, in comparison has a more general syntax (I wouldn't call Forth
syntax :D) and allows you to not worry about stack contents. It's just
higher level, at the cost of a much larger footprint.
In comp.lang.forth Ulrich Hobelmann <···········@web.de> wrote:
> Forth is somewhat harder to categorize, IMHO. It is very low-level, in
> that you have to express all dataflow on two explicit stacks. OTOH,
> there's no implicit allocation, so you need no GC; you can define pretty
> much anything you want as a word, including control.
To me there seems a duality to the stacks; if you get trapped into it, you're
writing machine code for a dual stack CPU. If you stay up on top of it, the
stacks seem more like a natural part of a dataflow-like language, where
you're invoking successive transformations to achieve the desired result.
In the former scenario, you inevitably start wishing for a third stack, or
registers (aka local variables), or whatever. In the latter scenario, you
don't need them, and would find their use clunky even if they were available.
I added local variables (actually they act more like a lambda binding) to
ForthOS. Much more than half the time, when I use them I come back and
clean up the definition, removing their use and simplifying the code at
the same time. It's really hard to write good Forth when your background
is C (experience speaking here).
Andy Valencia
In article <···············@individual.net>,
Ulrich Hobelmann <···········@web.de> wrote:
>BR wrote:
>
>If you ask me, Lisp can easily be categorized. It is an imperative
>language with lots of features, like: higher-order functions, OO,
>multiple return values, all kinds of control-flow operators, exceptions.
>
>Its abstract syntax (well, trees of s-exps) allow you to define truly
>powerful macros.
>
>> Couldn't the same be said for Forth?
>
>Forth is somewhat harder to categorize, IMHO. It is very low-level, in
>that you have to express all dataflow on two explicit stacks. OTOH,
>there's no implicit allocation, so you need no GC; you can define pretty
>much anything you want as a word, including control.
Forth is in fact reverse polish lisp. As everybody knows a stack
is a trick to get rid of brackets.
Groetjes Albert
--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.
Albert van der Horst wrote:
>>Forth is somewhat harder to categorize, IMHO. It is very low-level, in
>>that you have to express all dataflow on two explicit stacks. OTOH,
>>there's no implicit allocation, so you need no GC; you can define pretty
>>much anything you want as a word, including control.
>
>
> Forth is in fact reverse polish lisp. As everybody knows a stack
> is a trick to get rid of brackets.
It is, in a way. However in Lisp you have macros, while in Forth
usually most words are executed in order. Also, as Pascal pointed out,
Lisp has variable arguments (veeery nice, IMHO). Higher order functions
are possible in Forth in a way (execute), and you can create closures
with create/does>, but the languages are different. I'm thinking if one
should develop a more abstract Forth with non-evaluating words and
nesting, somewhat more akin to Joy. But then prefix-notation like in
Lisp allows nice regular indentation of code :)
Anyway, I like both languages for different reasons.
Albert van der Horst <······@spenarnc.xs4all.nl> writes:
> In article <···············@individual.net>,
> Ulrich Hobelmann <···········@web.de> wrote:
> >BR wrote:
> >
> >If you ask me, Lisp can easily be categorized. It is an imperative
> >language with lots of features, like: higher-order functions, OO,
> >multiple return values, all kinds of control-flow operators, exceptions.
> >
> >Its abstract syntax (well, trees of s-exps) allow you to define truly
> >powerful macros.
> >
> >> Couldn't the same be said for Forth?
> >
> >Forth is somewhat harder to categorize, IMHO. It is very low-level, in
> >that you have to express all dataflow on two explicit stacks. OTOH,
> >there's no implicit allocation, so you need no GC; you can define pretty
> >much anything you want as a word, including control.
>
> Forth is in fact reverse polish lisp. As everybody knows a stack
> is a trick to get rid of brackets.
You still need the brackets for variadic functions. Do they do in
Forth the same as in Postscript, placing a marker on the start at the
beginning of the variable length list, and using operator that pop the
list up to the marker?
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
"Albert van der Horst" <······@spenarnc.xs4all.nl> wrote in message
···············@spenarnc.xs4all.nl...
>
> Forth is in fact reverse polish lisp. As everybody knows a stack
> is a trick to get rid of brackets.
My HP-48G is programmable in Reverse Polish Lisp (RPL) and I have written
some RPL code. Believe me, it is *NOT* Forth!
--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
- http://www.mvps.org/ArcaneIncantations/consulting.htm
·········@mvps.org