Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Marcin Borkowski]

Hi list,

the subject says it all.  And please don't tell me that eval is evil;
that I know, in fact, I'm asking partly to gather some arguments;-).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Drew Adams]

> the subject says it all.  And please don't tell me that eval is evil;
> that I know, in fact, I'm asking partly to gather some arguments;-).

Dunno about edebug (I don't use it).  But you can invoke the debugger
by just inserting `(debug)' as the first arg to progn (or anywhere else):

  (eval '(progn (debug) ...))

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Michael Heerdegen]

Marcin Borkowski <mbork@mbork.pl> writes:

> the subject says it all.  And please don't tell me that eval is evil;
> that I know, in fact, I'm asking partly to gather some arguments;-).

I you hit C-u C-M-x over a form in a buffer that is not a definition, it
is evaluated with edebug.

If that's not what you mean, I don't understand the question.


Regards,

Michael.

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Marcin Borkowski]

On 2015-12-30, at 18:29, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> the subject says it all.  And please don't tell me that eval is evil;
>> that I know, in fact, I'm asking partly to gather some arguments;-).
>
> I you hit C-u C-M-x over a form in a buffer that is not a definition, it
> is evaluated with edebug.
>
> If that's not what you mean, I don't understand the question.

OK, so try C-u C-M-x with this form:

(eval
 '(progn
    (message "foo")
    (message "bar")))

and see how Edebug doesn't step into the progn.

I suspect that it's impossible to actually edebug the `progn' form here,
I just would like to make sure.

> Regards,
>
> Michael.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Drew Adams]

> OK, so try C-u C-M-x with this form:
> (eval '(progn (message "foo") (message "bar")))
> and see how Edebug doesn't step into the progn.
> 
> I suspect that it's impossible to actually edebug the `progn' form here,
> I just would like to make sure.

Well, as I said earlier, you can at least do this:

(progn
  (debug)
  (eval '(progn (message "foo") (message "bar"))))

or this:

(eval '(progn (debug) (message "foo") (message "bar")))

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Marcin Borkowski]

On 2016-01-04, at 23:58, Drew Adams <drew.adams@oracle.com> wrote:

>> OK, so try C-u C-M-x with this form:
>> (eval '(progn (message "foo") (message "bar")))
>> and see how Edebug doesn't step into the progn.
>> 
>> I suspect that it's impossible to actually edebug the `progn' form here,
>> I just would like to make sure.
>
> Well, as I said earlier, you can at least do this:
>
> (progn
>   (debug)
>   (eval '(progn (message "foo") (message "bar"))))
>
> or this:
>
> (eval '(progn (debug) (message "foo") (message "bar")))

True, though not as convenient as edebug.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Michael Heerdegen]

Marcin Borkowski <mbork@mbork.pl> writes:

> (eval
>  '(progn
>     (message "foo")
>     (message "bar")))
>
> and see how Edebug doesn't step into the progn.

That's expected, the argument to eval can be anything, in particular,
something that is not written down in some buffer.  In the above case,
you call eval on a constant, and edebug can't know where this constant
comes from.

Paste the progn form somewhere and hit C-u C-M-x if you want to use
edebug.


Michael.

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Marcin Borkowski]

On 2016-01-05, at 00:26, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> (eval
>>  '(progn
>>     (message "foo")
>>     (message "bar")))
>>
>> and see how Edebug doesn't step into the progn.
>
> That's expected, the argument to eval can be anything, in particular,
> something that is not written down in some buffer.  In the above case,
> you call eval on a constant, and edebug can't know where this constant
> comes from.
>
> Paste the progn form somewhere and hit C-u C-M-x if you want to use
> edebug.

I guess you misunderstood me.  It's not that I have this in actual code,
or that I really want to edebug _this_ progn.  I have (more or less)
this in actual code:

(defun conditional-save-excursion-1-function (arg form)
  "If ARG is non-nil, eval FORM inside a `save-excursion'."
  (if arg
      (save-excursion
        (eval form))
    (eval form)))

I was curious whether it is possible to step with edebug through
`form'.

Also, this is not "actual code" in a sense that I want to actually use
it anywhere.  Disclosure: it comes from the draft of my Emacs book,
chapter on macros, where I try to explain why a macro is better than
a function in such a case.  One of the reasons is that you can't use
edebug if you use a function and not a macro like this:

(defmacro conditional-save-excursion-1 (arg form)
  "If ARG is non-nil, wrap FORM in `save-excursion'."
  (declare (indent 1) (debug t))
  (if arg
      `(save-excursion ,form)
    form))

(BTW, this macro is inspired by a real use-case.)

My question was because I do not want to write it in the book if I'm not
100% sure I'm right, and I wasn't sure.  (Though it seems that I was
right after all - Stefan's trick with replacing the backquote with its
edebug-compliant variant doesn't count, I guess;-).)

> Michael.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Michael Heerdegen]

Hi Marcin,

ok, what you wrote in the last message makes all sense.  I don't think
you missed something.


Regards,

Michael.

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Marcin Borkowski]

On 2016-01-05, at 21:00, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Hi Marcin,
>
> ok, what you wrote in the last message makes all sense.  I don't think
> you missed something.

Thanks!

> Regards,
>
> Michael.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Stefan Monnier]

> OK, so try C-u C-M-x with this form:

> (eval
>  '(progn
>     (message "foo")
>     (message "bar")))

Of course, this is a silly use of `eval' and for more real uses this
problem typically doesn't happen.  This said, you can try

   (eval (edebug-\` (progn (message "foo") (message "bar"))))

Where edebug-\` is an alias for the normal backquote which tells Edebug
that the quoted data is actually dynamically-generated code, so Edebug
can try to "do the right thing".


        Stefan

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Marcin Borkowski]

On 2016-01-05, at 05:41, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> OK, so try C-u C-M-x with this form:
>
>> (eval
>>  '(progn
>>     (message "foo")
>>     (message "bar")))
>
> Of course, this is a silly use of `eval' and for more real uses this

Of course it's silly, it wasn't meant to be anything else.

> problem typically doesn't happen.  This said, you can try
>
>    (eval (edebug-\` (progn (message "foo") (message "bar"))))
>
> Where edebug-\` is an alias for the normal backquote which tells Edebug
> that the quoted data is actually dynamically-generated code, so Edebug
> can try to "do the right thing".

Ha, that's interesting.  Do I get it correctly that the "normal
backquote" is the symbol \`, which is an alias for the `backquote'
macro?

>         Stefan

Thanks,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Stefan Monnier]

> Ha, that's interesting.  Do I get it correctly that the "normal
> backquote" is the symbol \`,

That's right.

> which is an alias for the `backquote' macro?

Pretty much, yes,


        Stefan

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Thorsten Jolitz]

Marcin Borkowski <mbork@mbork.pl> writes:

Hi,

> And please don't tell me that eval is evil;
> that I know, in fact, I'm asking partly to gather some arguments;-).

Isn't "code = data" the core principle of Lisp, and eval the basic way
to use data as code? 

Probably bad and slow for some Lisps with compiler, but for interpreted
Lisps (as long as users can't abuse it)?

-- 
cheers,
Thorsten

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Stefan Monnier]

> Probably bad and slow for some Lisps with compiler, but for interpreted
> Lisps (as long as users can't abuse it)?

The reason eval is evil has nothing to do with performance: it's
a software engineering issue.  It's kind of like using nconc instead of
append, except magnified many times.


        Stefan

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Thorsten Jolitz]

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

>> Probably bad and slow for some Lisps with compiler, but for interpreted
>> Lisps (as long as users can't abuse it)?
>
> The reason eval is evil has nothing to do with performance: it's
> a software engineering issue.  It's kind of like using nconc instead of
> append, except magnified many times.

I must admit I still don't get it.

The arguments I find here (e.g.):

,----
| "clojure - Why exactly is eval evil? - Stack Overflow"
| http://www.google.de/search?ie=UTF-8&oe=UTF-8&q=whats+wrong+with+eval+in+lisp&gws_rd=cr&ei=d5yGVrSkIIfcPNSOhIAD
`----

almost all relate to compiler issues (except security and readability)

,----
| So, the answers so far are:                      
|                                                           
|   * Not validating input from users and sending to eval is
|     evil                                                  
|   * Using eval I may end up with interpreted code instead 
|     of compiled                                           
|   * Eval could make code unreadable (although I think one 
|     can write unreadable code without any "powerful"      
|     features, so this is not much of an issue)            
|   * Beginners may be confused mixing compile-time and     
|     evaluation-time when mixing eval and macros (but I    
|     think it's not an issue once you get a firm grasp of  
|     how your language works -- be it Lisp or other)       
`----

In another related post

,----
| http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html
`----

again the compiler argument seems to be the most reasonable:

" [...] a program that uses eval.  It can't be compiled and optimized as well
as the earlier paragraph, and the language context in which it is run
may change the result."


But in an interpreted Lisp without a Compiler, moving around lists as
data and 'eval' them at some point still appears like a great feature to
make programs short and readable to me.

--      
cheers, 
Thorsten

Re: Is there a way to instrument for edebug a form (say, a progn) given to `eval'?

[Stefan Monnier]

> "[...] a program that uses eval.  It can't be compiled and optimized as well
> as the earlier paragraph, and the language context in which it is run
> may change the result."

The reason why it can't be compiled/optimized is that it's very
difficult to analyze/understand precisely what can happen.

And this difficulty doesn't only apply to automated tools like
compilers/optimizers but also to humans.  Basically, when execution gets
to "eval" *anything* can happen.  So modifying code that uses "eval"
without affecting its behavior is terribly difficult.

So it makes for code that's difficult to maintain.  There are cases
where "eval" is just what you need, of course, but you should keep in
mind that it's too powerful to use it in cases where something else
would work as well.


        Stefan