Re: How to improve the readability of (any) LISP or any highlevel functional language to the level of FORTH ?

[Doug Hoffman]

On 1/6/11 2:20 PM, Pascal J. Bourguignon wrote:
> Doug Hoffman<glidedog@gmail.com>  writes:
>
> > 2) The following is one way (of many) to approach this in standard Forth:
> >
> > : quad f{ a b c -- root }
> >    b FNEGATE b FDUP F* 4e a c F* F* F- FSQRT F+ 2e a F* F/
> >    ;
> >
> > -2e 7e 15e quad f.
> > -1.500000
> >
> > Is it readable?  Unless you're a Forther I would say no.  But notice
> > the complete lack of parentheses and operator precedences to resolve.
> > Any competent Forther could quickly see exactly what is going on.
>
> Now, as a Forth programmer, ask yourself what you would have to do, to
> call an operator with a variable arity?

One way to handle a variable number of input parameters is to precede 
them with a count.  There is at least one ANS Forth word that does this. 
 I've seen the technique used a lot elsewhere in Forth code.  Supplying 
a "mark" is also something I've seen.

If I am going to apply a single operator to a list of many items, in 
Forth I would likely put the items in a list, perhaps a list of objects 
depending on the nature of the items, and then iterate over the list.


Just to be clear, so we don't get sidetracked on a Lisp vs Forth 
tangent:  I commented that I believed the Lisp example is somewhat 
readable to someone unfamiliar with Lisp, Forth is not readable to 
someone unfamiliar with Forth.  The standard "Fortran/spreadsheet" 
syntax version is the most readable for this example regardless of 
language familiarity, again in my opinion.

[snip]

>     (F/ (F* a 2e)
>         (F+ (FSQRT (F- (F* c a 4e)
>                        (F* (FDUP (- b)))))))
>
> so it becomes readable again and you can see there's a bug in the Forth
> expression.

No, I can't see any bug in the Forth example.  Could you point it out 
more clearly?

-Doug