thanks for your answers, Alex

On Sun, Jan 29, 2017 at 9:48 AM, Alexander Burger <>

> > >    (if (testSomething) (doSomething1) (doSomething2) (doSomething3))
> > ...
> > but this also means the only way to indicate several executable
> expressions
> > in the "then-clause" is to surround them between parens, i.e.  (if (= 2
> 2)
> > ((print "equal") (print "2")) (print "not equal") (print "not 2"))   I
> No. This gives a crash (try it, and think about why ;).

I tried and it crashes with a segmentation fault, I was thinking about what
could be the reason and my guess is it is related with 'eval' function. I
think when the body of "if" function tries to eval the any2 expression it
fails with sementation fault if it is a list of lists, that is, the first
item of any2 expression is a list:

(eval 1)  -> 1
(eval (1)) -> (1)
(eval ((1))) ---- segmentation fault

My guess is eval tries to evaluate its parameter, thus when being a number
it evaluates to itself and an atom evaluates to its value:

(setq A 1)
(eval A) -> 1
(eval B) --- B is not defined

But when the parameter to evaluate is a list, eval tries to evaluate the
list which means to apply the function call represented by the list, with
special case of lists of numbers

(de f (X) (+ X 1))
(eval (f 1)) -> 2   # eval tries to evaluate the list viewed as a function
call so it applies function f to parameter 2 and gets the returned value as
the result of eval
(eval (1 2)) -> (1 2)  # the same as above but exploiting the special
treatment picolisp give to list of numbers in order to avoid quoting it

The problem appears when you pass eval a list of lists (or a list with a
first item which is also a list), in this case eval tries to evaluate but
doen't know how to eval a item list, it could be a function call because it
is not an atom. Using the analogy of stack when eval gets a simple list it
pops the first item which being an atom means it must be a function name so
two possible cases it's a defined function or it is not defined, if it is
defined but it's not a function but it also fails with segmentation fault
because you cannot apply an atom if it's not a function (and evaluating a
list means it must be a function call  --or a list of numbers--)

(de f (X) (* X X))
(setq A 1)
(eval (f 2)) -> 4
(eval (A 2)) --- segmentation fault
(eval f)  --- X undefined
(eval 'f)  -> ((X) (* X X))
(eval (f)) -> NIL # strangely in this case it doesn't say X undefined but
returns NIL

The problem seems to be only when eval expects an atom to be a function or
an undefined symbol and what it gets is an defined atom which is not a
function symbol:

(eval B) -> NIL
(eval (B)) --- B undefined
(eval (B 1)) --- B undefined
(eval ((B))) --- B undefined
(eval ((B 1))) --- B undefined
(setq B 2)
(eval B) -> 2
(eval (B)) --- segmentation fault
(eval (B 1)) --- segmentation fault
(eval ((B))) --- segmentation fault
(eval ((B 1))) --- segmentation fault

Also eval evaluates recursively the list passed as arguments

(de g (X) (+ X 1))
(de f (X) 'g)
(eval ((f 99) 2 )) -> 3

So my conclusion is eval always expect a list to be a valid function call
(or a list of numbers) and if it is not then fails with segmentation
fault.  And the reason for "if" to fail in a similar way is it tries to
eval the "then-clause" (any2)

If so what I don't understand is why to cause a segmentation fault, I think
it could easily avoid if eval phase in REPL simply detect a first item in a
list being a defined atom but not a function and throw an error (in a
similar way of "not defined" errors in previous examples) or even even
evaluating the atom to its value when it detects it is not a function (even
being the first item in a list).

What I mean is maybe a desiderable behaviour of eval would be:

(setq A 1)
(de f (N) (+ N 1))
(eval A) -> 1
(eval (f 1)) -> 2
(eval (A 2)) --- A is not a function  # case 1, eval knows it is not a
(eval (A 2)) -> 1   # case 2, even when it seems a function call since A is
not a function but a defined symbol resolve to its value
(eval ((A))) -> 1  # case 2, but could also be implemented as case 1 too

Is it my reasoning right?  or maybe I'm saying a nonsense?

Anyway I see the segmentation fault messages includes some numbers, are
they anyhow setted by picolisp or are they totally system dependent?

[1]    863 segmentation fault  ./pil +
 ^     ^^^
 |______|____ this numbers


Reply via email to