Re: [clisp-list] FP using CL

[Kaz K. <ka...@ky...>]

On 2021-05-05 23:28, Jean Louis wrote:
> * Kaz Kylheku <ka...@ky...> [2021-05-03 22:41]:
>> On 2021-05-01 11:00, Duke Normandin wrote:
>> > Noob here!
>> >
>> > All of my previous non-pro, hobbyist hacking experience has been
>> > imperative.
>> > I want to give FP a shot using CL.
>> > Problem: I don't seem to grok how to start the process of creating a
>> > CL program using **just** functions.
>> 
>> The good news is that pretty much "nobody" does that. Common Lisp is a
>> multi-paradigm language.
> 
> It is easy to find examples of Common Lisp as functional language,
> rather hard to find procedural examples.

Where are you looking? It's hard to find examples of Common Lisp as
a procedural language in a book or tutorial that is ideologically
geared toward functional.

If you look in real code, it's not hard to find procedural coding.

Just now, I headed to github and tried to think of some known CL 
project.

For some reason, the word *cl-who* popped into my head, probably
because my mind drifted toward authors and I was thinking "who" do
I look for?

And so, I searched for cl-who and immediately landed on this:

https://github.com/edicl/cl-who/blob/master/who.lisp

Whoa! Look, it's full of setf, loop, incf, nreverse ...

Next, I just recalled a the existence of a Common Lisp program that
was part of someone's Ph. D. thesis about solving certain
geometric shape arrangement puzzles, namely tangrams. Aha,
here it is:

https://github.com/lambdamikel/Common-Lisp-Tangram-Solver

That's academic stuff doing some lofty algorithms, including
some approaches that must be novel if they fetched a Ph. D.

Academia is obsessed with functional nowadays. Still, can we
find imperative coding in it?

Let this be the first file I select for inspection:

https://github.com/lambdamikel/Common-Lisp-Tangram-Solver/blob/main/src/main/covering3.lisp

I see loops there. Loops are not inherently non-functional though;
sometimes their variable stepping is not relevant. I.e. they
basically emulate the math sigma notation, which isn't procedural.

More importantly, I see this in the file:

       (let ((ox (decode-ccw (orientation x)))
             (oy (decode-ccw (orientation y))))

         (when (eq ox :clockwise)
           (orientate-counterclockwise x))

         (when (eq oy :counterclockwise)
           (orientate-clockwise y))

         ...)

This is a let form with multiple body arguments, which means
they are being evaluated for an effect. The value of the first
(when ...) form is not being returned; it is ignored. Which
means that (oreintate-counterclockwise x) has an effect on the
object denoted by x.

It looks like the orientations of objects x and y are being
decoded, and then these objects are tweaked with an opposite
orientation, probably in order to normalize them in order to
reduce the number of cases later, or something.

See? You can do Ph. D. level work in computational geometry,
accompanied by imperative code written in Lisp.

I feel I could sit here all day, and easily land into one
Common Lisp source after another that is full of effectful
programming.

Cheers ...