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

[girosenth <girosenth@india.com>]

On Jan 1, 6:15 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> girosenth <girose...@india.com> writes:
> > How to improve the readability of (any) LISP or any highlevel
> > functional language to the level of FORTH ?
>
> > There are many people who have trivia complaints about parens in lisp,
> > but I dont.
>
> > LISP is a prefix notation.
>
> > sequence of operations would look like this on operands (ops) :
>
> > (f ops (g ops (h ops (j ops (k ops (l ops ))...))))
>
> > How do you make it readable ?
> > How do you home to the center or centers ?
>
> > (f (g (h (j (k (l ops)))...)))
>
> > is easy to read or
>
> > ops l k j h g f
>
> > ???
>
> I think we can call you a troll.

Factually, such a level of prejudice is not good for health, intellect
or discussion.

> Is it not obvious how you home to the center?http://www.informatimago.com/~pjb/bulleye.png
> Is it not a flagrant proof that lisp is the most easy to read?

There are things that I was hoping experienced programmers would fill
in that I forgot to state.

In a one liner which is an accurately represented by the subsets your
image displays, it is infact true that the center(s) are immediately
obvious. But if each of the f,g,h,...k,l are huge functions (in the
definitions) then they may occupy parts of a screen and the whole may
occupy several screens, or several tens of screens. Note also that I
have ops only before , but they can be everywhere. Function
(definition) enclosures have a 1-1 correspondence with trees as any
hierarchical objects and may look like a herringbone tree.

Sphagetti code which was promoted by a goto was brought under control
by "structured" programming which had only 3 forms (thus removing the
need for a flow chart) ie sequence, selection and iteration.
Functional language adds another useful form which is recursion and
(as a side comment) recursion is not representable by a flowchart.

The sequence, which is the simplest of the construct is essentially
imperative in nature. Sequence of state changes.

A purely functional program would have a single huge nested function.

One could say that a huge function can be broken into simpler
functions. Logic could always be chased LINE BY LINE by a determined
reader with unlimited time, but for most of us, programming efficiency
is an issue. However, to break a several screen or even a smaller set
of computation, I am faced with how to break it into parts due to
coupling in its parts. I was doing it inside let* to avoid setq
(fair ?) but I have a function that must return a number or a string
depending on if a regex was found and its index or a message that it
was not found.

(string-match REGEXP STRING &optional START)

inside a (cond) I return a string or the number

I am constrained to write like this because I wrote a quick and dirty
working and structurally (in the sense of structured) readable code
but WITHOUT taking care of failures or errors. Now I am trying to
modify it to take care of errors.

I must test it as soon as string match what type of regexp was not
found.

As I started modifying it, I lost track of its structure. I could
understand it at the write time but I know that after forgetting, at
the read time I will not understand it in the linear sense of the size
increase.

Even as I explained to a friend, I realized that I need to home in to
the center and reading was not linear as FORTH promises and any
postfix language with action words (functions) reads. The reading is
not linear.

I realized that you can read infix notation or standard function
notation f(x) of (f x) only because they are simpler functions, not
the recursive type functions of McCarthy. Those functions have if then
else logic embedded that is not apparent as you start reading it.

Our math functions are very simple, and most often single letters.
That is why algebraic notation is easy for them.

In comparison to prefix, postfix seems in the order of the action.
Certainly, it starts with the center object moved to the left most.

One gentleman has advocated ruby. The thread will be enriched by
perspectives from other functional languages. Suppose, I want to stick
to elisp and then move to CL (since almost everyone who has not taken
a course in lisp or scheme and who starts with linux comes to emacs
and elisp first) instead of ruby, then it appears to me that macros
which are being discussed without any examples in elisp or even CL
might be an answer to take care of sphagetti code or highly coupled
code. I was considering making a huge MIMO function that takes in many
bits and makes an output to be used by others. Atleast, the main
program would be readable. Such a function would have no analogy to
the real world object or operation and thus built on fictional lines
and unstable in construction and likely to be challenged by then next
exception that I would encounter in my build-fix method and thus beg
for recoding and re-reading again. Readability then is an issue.

I read your post somewhere with your example of flatten. I was
honestly not impressed with readability. All that you did was to
compress cond and also to use push/pop which would be indicated by a
text comment as clearly. Admitted that the code took smaller part of
the screen.

In modern IDE's there is a feature which allows code to be collapsed.
I am using older version of emacs I dont know if RMS and his team has
copied such features from eclipse and other IDEs into emacs and
debugged them or a bold adventurer would be on their mercy.

In the hygenic macro thread currently in progress, I want to ask them
to show me how macros can be written to prove their claims assuming
that I have good grasp of basics like quote, backquote, unquote and
splice.

I know some of these might sound unpleasant to commercial entities
with so much invested in it but for us, honest discussion and support
of claims by demonstration example is what really counts.

girosenth

> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
> A bad day in () is better than a good day in {}.- Hide quoted text -
>
> - Show quoted text -