Return value not as expected in Emacs Lisp function

Return value not as expected in Emacs Lisp function

[Thorsten Jolitz]

Hi List, 

I have a hard time to understand the following behaviour of an Emacs Lisp
program of mine. Here is an abstract version of this program:

#+begin_src emacs-lisp
  (defun my-fun ()
    (let ((result (concat
                    "(prog "
                    (mapconcat
                     (lambda ...)
                     lst "")
                    ")")))
      (message "%s" result) ; just for logging
      result))
#+end_src

After running the program, I find, as expected, something like this in
the *Messages* buffer:

#+begin_quote
(prog (click NIL 1)(press NIL 1)(click NIL 4)(click NIL 1))
#+end_quote

so the value of 'result' is just fine in the second-last line of the
fun.

But the return value is not what I would expect

#+begin_src emacs-lisp
 (print (my-fun))
#+end_src

or 

#+begin_src emacs-lisp
 (message "%s" (my-fun))
#+end_src

yield

#+begin_quote
(prog )
#+end_quote

and I ask myself what happened between the second-last and the last line of
the function? I cannot reproduce this with a MWE, and the real function is too
convoluted to present it here, so I keep the problem description on an
abstract level. 

I'm actually only interested in the result string as a return value, the
message statement is just for logging. But why is the string produced by
'mapconcat' missing in the return value?

-- 
cheers,
Thorsten

Re: Return value not as expected in Emacs Lisp function

[Stefan Monnier]

> so the value of 'result' is just fine in the second-last line of the
> fun.

> But the return value is not what I would expect

Maybe there's something going on in the way you "get the return value".
IOW give us more details to reproduce the problem.


        Stefan

Re: Return value not as expected in Emacs Lisp function

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> so the value of 'result' is just fine in the second-last line of the
>> fun.
>
>> But the return value is not what I would expect
>
> Maybe there's something going on in the way you "get the return value".
> IOW give us more details to reproduce the problem.

While preparing to post the real function definition, I found the error:
a missing opening parenthesis in the (interactive...) part of the
function, in a branch of a (cond...) statement I never tested.

In total, the parens matched - but not all in the right places. 

Sorry for the noise.

-- 
cheers,
Thorsten

Re: Return value not as expected in Emacs Lisp function

[Pascal J. Bourguignon]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> and I ask myself what happened between the second-last and the last line of
> the function? I cannot reproduce this with a MWE, and the real function is too
> convoluted to present it here, so I keep the problem description on an
> abstract level. 

On an abstract leve, I can't debug a function if I don't have it's
code.  That's the reason d'être of the MWE, and by default the real code.


> I'm actually only interested in the result string as a return value, the
> message statement is just for logging. But why is the string produced by
> 'mapconcat' missing in the return value?

The real question is why you use mapconcat to produce a string
representation of a sexp?  Just use prin1-to-string!

(let ((list '((click NIL 1) (press NIL 1) (click NIL 4) (click NIL 1))))
  (prin1-to-string `(prog ,@list )))
--> "(prog (click NIL 1) (press NIL 1) (click NIL 4) (click NIL 1))" 

Notice:

- emacs lisp is a lisp-2, not a lst-1.

- NIL is true:
  
  (not (not 'NIL))       --> t
  (not 'NIL)             --> nil
  (if 'NIL 'true 'false) --> true


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.  
You know you've been lisping too long when you see a recent picture of George 
Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin

Re: Return value not as expected in Emacs Lisp function

[Thorsten Jolitz]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> and I ask myself what happened between the second-last and the last line of
>> the function? I cannot reproduce this with a MWE, and the real function is too
>> convoluted to present it here, so I keep the problem description on an
>> abstract level. 
>
> On an abstract leve, I can't debug a function if I don't have it's
> code.  That's the reason d'être of the MWE, and by default the real code.

I found the error, a misplaced paren. I could not reproduce the error in
a MWE - probably I did not copy the part with the misplaced paren to the
MWE.

>> I'm actually only interested in the result string as a return value, the
>> message statement is just for logging. But why is the string produced by
>> 'mapconcat' missing in the return value?
>
> The real question is why you use mapconcat to produce a string
> representation of a sexp?  Just use prin1-to-string!
>
> (let ((list '((click NIL 1) (press NIL 1) (click NIL 4) (click NIL 1))))
>   (prin1-to-string `(prog ,@list )))
> --> "(prog (click NIL 1) (press NIL 1) (click NIL 4) (click NIL 1))" 
>
> Notice:
>
> - emacs lisp is a lisp-2, not a lst-1.
>
> - NIL is true:
>   
>   (not (not 'NIL))       --> t
>   (not 'NIL)             --> nil
>   (if 'NIL 'true 'false) --> true


I should have said that this 

,-----------------------------------------------------------------
| "(prog (click NIL 1) (press NIL 1) (click NIL 4) (click NIL 1))"
`-----------------------------------------------------------------

is actually PicoLisp, a lisp-1 with NIL and T syntax (uppercase!). I
thought the 'prog in the beginning (PicoLisp's 'progn)  would make it
clear its not Elisp. At least C-h f doesn' show me a 'prog function in
Elisp. 

But thanks for your answer, I did not know `prin1-to-string', and finally
looked up the difference between lisp-1 and lisp-2. 

-- 
cheers,
Thorsten

Re: Return value not as expected in Emacs Lisp function

[Pascal J. Bourguignon]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> ,-----------------------------------------------------------------
> | "(prog (click NIL 1) (press NIL 1) (click NIL 4) (click NIL 1))"
> `-----------------------------------------------------------------
>
> is actually PicoLisp, a lisp-1 with NIL and T syntax (uppercase!). I
> thought the 'prog in the beginning (PicoLisp's 'progn)  would make it
> clear its not Elisp. At least C-h f doesn' show me a 'prog function in
> Elisp. 
>
> But thanks for your answer, I did not know `prin1-to-string', and finally
> looked up the difference between lisp-1 and lisp-2. 

Ok, that explains the 'lst.

Now, emacs has one good characteristic that helps in manipilating sexps
from other lisps:  it has no module or package system and it has case
sensitive symbols, with no lisp reader to upcase them automatically by
default.

Therefore, you can perfectly manipulate picolisp sexps as emacs lisp
sexps.  Unless you have to deal with reader macros or other strange
syntaxes, my advice would be to stick to sexps, this has big advantages
over strings.


As for the misplaced parenthesis problem, be sure to let emacs
auto-indent lisp (any) code for you, selectnig a region and typing C-M-\
(indent-region), or using paredit (strongly advised, to edit any kind of
sexps), typing M-q (paredit-reindent-defun) from time to time inside
sexps.

Then you will be shocked by any misplaced parenthesis, since it will
imply very strange indentation, like this:


(defun hostname ()
  (interactive "Hello"
               (cond ((boundp  'system-name) system-name)
                     ((fboundp 'system-name) (system-name)))
               (t (shell-command-to-string
                   "echo -n $( (hostname -f 2>/dev/null) || (hostname 2>/dev/null) )"))))

where it is obvious that there's a missing closing parenthesis for
interactive, and that the cond is closed too early (before the (t …)
branch.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.  
You know you've been lisping too long when you see a recent picture of George 
Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin

Re: Return value not as expected in Emacs Lisp function

[Thorsten Jolitz]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> ,-----------------------------------------------------------------
>> | "(prog (click NIL 1) (press NIL 1) (click NIL 4) (click NIL 1))"
>> `-----------------------------------------------------------------
>>
>> is actually PicoLisp, a lisp-1 with NIL and T syntax (uppercase!). I
>> thought the 'prog in the beginning (PicoLisp's 'progn)  would make it
>> clear its not Elisp. At least C-h f doesn' show me a 'prog function in
>> Elisp. 
>>
>> But thanks for your answer, I did not know `prin1-to-string', and finally
>> looked up the difference between lisp-1 and lisp-2. 
>
> Ok, that explains the 'lst.
>
> Now, emacs has one good characteristic that helps in manipilating sexps
> from other lisps:  it has no module or package system and it has case
> sensitive symbols, with no lisp reader to upcase them automatically by
> default.
>
> Therefore, you can perfectly manipulate picolisp sexps as emacs lisp
> sexps.  Unless you have to deal with reader macros or other strange
> syntaxes, my advice would be to stick to sexps, this has big advantages
> over strings.

But isn't the communication between the two lisps (picolisp and elisp)
always done with strings? It `comint-send-string' or
`process-send-string', no matter if that string contains a sexp or
something else. Of course, both lisps can then "read-from-string" the
sexps they recieve from the other program if the syntax matches, but
they are send and arrive as strings - right?

> As for the misplaced parenthesis problem, be sure to let emacs
> auto-indent lisp (any) code for you, selectnig a region and typing C-M-\
> (indent-region), or using paredit (strongly advised, to edit any kind of
> sexps), typing M-q (paredit-reindent-defun) from time to time inside
> sexps.
>
> Then you will be shocked by any misplaced parenthesis, since it will
> imply very strange indentation, like this:
>
>
> (defun hostname ()
>   (interactive "Hello"
>                (cond ((boundp  'system-name) system-name)
>                      ((fboundp 'system-name) (system-name)))
>                (t (shell-command-to-string
>                    "echo -n $( (hostname -f 2>/dev/null) || (hostname 2>/dev/null) )"))))
>
> where it is obvious that there's a missing closing parenthesis for
> interactive, and that the cond is closed too early (before the (t …)
> branch.

ok, thx for the tip. 

-- 
cheers,
Thorsten