Re: How to cast an imperative loop into a readable recursive function ?

[Katalin Sinkov <lispstylist@gmail.com>]

On Dec 2, 9:35 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Katalin Sinkov <lispstyl...@gmail.com> writes:
> > Take a look at my lisp code. it can be modified simply to run it and
> > it runs in an emacs "ide".
>
> No it does not.  
>
> First, it's lacking a parenthesis.
>
> You should get paredit.el, and activate the paredit-mode to edit lisp
> sources.  See how lisp code is indented, and let emacs and paredit
> indent it for you, and place the parentheses for you.  This will produce
> lisp code that is more readable, and you will be able to copy-and-paste
> sexps "structurally", with much less risk of losing parentheses.
>
> Then, if we add the obvious missing parenthesis, and try to evaluate
> your code:
>
>     (let ((char_skips (- n  s) ))
>       (while (not (= char_skips 0))
>         (progn
>           (if (<= char_skips (+ l -1) )
>               (progn
>                 (forward-char char_skips)
>                 (setq char_skips 0))
>               (progn
>                 (forward-char l)
>
>                 (forward-search-regexp "(s=###l=###)" nil nil nil) ; put in an if
>                 ;; and else block to test if FAIL
>                 (setq s (match-string 0))
>                 (setq l (match-string 0))
>
>                 (setq char_skips (- n s) ))))))
>
> we get the following error:
>
>     Debugger entered--Lisp error: (void-variable n)
>       (- n s)
>       (let ((char_skips ...)) (while (not ...) (progn ...)))
>       eval((let ((char_skips ...)) (while (not ...) (progn ...))))
>       eval-last-sexp-1(nil)
>       eval-last-sexp(nil)
>       call-interactively(eval-last-sexp nil nil)
>
> If you want us to help, please provide working stand alone code, with
> test data.
>
> (By the way, my emacs "23.2.1" doesn't have a forward-search-regexp
> function).

search-forward-regexp

more later tomorrow

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