extracting serial repeats

extracting serial repeats

[Andreas Roehler]

Hi,

let's consider the following pseudo-code, assumed inefficient, because Functions 1..n  are identic.

Function-1
(Body-of-Function-1)
Follow-action-1 with Function-1
Follow-action-2 with Function-1

Function-2
(Body-of-Function-2)
Follow-action-1 with Function-2
Follow-action-2 with Function-2
...
Function-n
(Body-of-Function-n)
Follow-action-1 with Function-n
Follow-action-2 with Function-n

More efficient seems, having

Body-of-Functions

extracted into a subroutine

so we could write something like

(dolist (element (1..n))
   SUBROUTINE element
   Follow-action-1 with element
   Follow-action-2 with element

Question is: exists a known tool for the extraction resp. refactoring needed?

Thanks


Andreas

--
https://code.launchpad.net/s-x-emacs-werkstatt/
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/

Re: extracting serial repeats

[Anselm Helbig]

Hello Andreas!

At Sat, 23 Jan 2010 17:01:40 +0100,
Andreas Roehler wrote:
> 
> Hi,
> 
> let's consider the following pseudo-code, assumed inefficient, because Functions 1..n  are identic.
> 
> Function-1
> (Body-of-Function-1)
> Follow-action-1 with Function-1
> Follow-action-2 with Function-1
> 
> Function-2
> (Body-of-Function-2)
> Follow-action-1 with Function-2
> Follow-action-2 with Function-2
> ...
> Function-n
> (Body-of-Function-n)
> Follow-action-1 with Function-n
> Follow-action-2 with Function-n
> 
> More efficient seems, having
> 
> Body-of-Functions
> 
> extracted into a subroutine
> 
> so we could write something like
> 
> (dolist (element (1..n))
>    SUBROUTINE element
>    Follow-action-1 with element
>    Follow-action-2 with element
> 
> Question is: exists a known tool for the extraction resp. refactoring needed?

Sounds like a case for a macro:

  (defun foo-function (i)
    `(defun ,(intern (format "foo-function-%d" i)) (arg1 arg2)
       (message "this is the body of the function")))

  (defmacro define-foo-functions (n)
    `(progn 
       ,@(loop for i from 1 to n
               collect (foo-function i))))

The question is, however, why do you need functions with a number in
their name, shouldn't this be an argument to the function? 

HTH, 

Anselm


-- 
Anselm Helbig 
mailto:anselm.helbig+news2009@googlemail.com

Re: extracting serial repeats

[Andreas Röhler]

Anselm Helbig wrote:
> Hello Andreas!
>
> At Sat, 23 Jan 2010 17:01:40 +0100,
> Andreas Roehler wrote:
>   
>> Hi,
>>
>> let's consider the following pseudo-code, assumed inefficient, because Functions 1..n  are identic.
>>
>> Function-1
>> (Body-of-Function-1)
>> Follow-action-1 with Function-1
>> Follow-action-2 with Function-1
>>
>> Function-2
>> (Body-of-Function-2)
>> Follow-action-1 with Function-2
>> Follow-action-2 with Function-2
>> ...
>> Function-n
>> (Body-of-Function-n)
>> Follow-action-1 with Function-n
>> Follow-action-2 with Function-n
>>
>> More efficient seems, having
>>
>> Body-of-Functions
>>
>> extracted into a subroutine
>>
>> so we could write something like
>>
>> (dolist (element (1..n))
>>    SUBROUTINE element
>>    Follow-action-1 with element
>>    Follow-action-2 with element
>>
>> Question is: exists a known tool for the extraction resp. refactoring needed?
>>     
>
> Sounds like a case for a macro:
>
>   (defun foo-function (i)
>     `(defun ,(intern (format "foo-function-%d" i)) (arg1 arg2)
>        (message "this is the body of the function")))
>
>   (defmacro define-foo-functions (n)
>     `(progn 
>        ,@(loop for i from 1 to n
>                collect (foo-function i))))
>
> The question is, however, why do you need functions with a number in
> their name, shouldn't this be an argument to the function? 
>
> HTH, 
>
> Anselm
>
>
>   

Hi Anselm,

thanks a lot.

Seems I didn't describe the problem well: it's something like: "How to
avoid parallel implementing?".
Or let's say it that way:

Given a serial or serials of lambda-forms which take arguments of the
same kind processing it the same way,
but differ in function-names, they are referring to.

Instead of implementing the same forms repeatedly under different names,
we could re-use one.

Can do that by hand, sure. But as the issue shows up occasionaly, a tool
doing these extractions might be useful.

Andreas

Re: extracting serial repeats

[Anselm Helbig]

Hi Andreas!

> thanks a lot.
> 
> Seems I didn't describe the problem well: it's something like: "How to
> avoid parallel implementing?".
> Or let's say it that way:
> 
> Given a serial or serials of lambda-forms which take arguments of the
> same kind processing it the same way,
> but differ in function-names, they are referring to.
> 
> Instead of implementing the same forms repeatedly under different names,
> we could re-use one.

So you don't like the macro approach because it's still creating a lot
of functions internally? If you'd like to share the implementation,
the code could look like this:

  (defun foo (n a b c)
    (message "n: %d; a: %s; b: %s; c: %s" n a b c))

  (defun make-foo-function (n)
    (lexical-let ((lexical-n n))
      (lambda (a b c)
        (foo lexical-n a b c))))

  (dotimes (i 22)
    (fset (intern (format "foo-function-%d" i))
          (make-foo-function i)))

  (foo-function-21 1 2 3)

I there's anything unclear about this code or the defmacro-approach I
gave you before, just ask. 

> Can do that by hand, sure. But as the issue shows up occasionaly, a tool
> doing these extractions might be useful.

Maybe I didn't get the issue right: you've got repetetive code to
start with and want to have it refactored automatically? It's
certainly possible to have such functionality, on the other hand, you
don't have to write repetetive code in lisp in the first place, that's
what macros are for. And, as shown above, you can also use functional
programming techniques to the same end. 

All the best, 

Anselm


-- 
Anselm Helbig 
mailto:anselm.helbig+news2009@googlemail.com

Re: extracting serial repeats

[Andreas Röhler]

Anselm Helbig wrote:
> Hi Andreas!
>
>   
>> thanks a lot.
>>
>> Seems I didn't describe the problem well: it's something like: "How to
>> avoid parallel implementing?".
>> Or let's say it that way:
>>
>> Given a serial or serials of lambda-forms which take arguments of the
>> same kind processing it the same way,
>> but differ in function-names, they are referring to.
>>
>> Instead of implementing the same forms repeatedly under different names,
>> we could re-use one.
>>     
>
> So you don't like the macro approach because it's still creating a lot
> of functions internally? If you'd like to share the implementation,
> the code could look like this:
>
>   (defun foo (n a b c)
>     (message "n: %d; a: %s; b: %s; c: %s" n a b c))
>
>   (defun make-foo-function (n)
>     (lexical-let ((lexical-n n))
>       (lambda (a b c)
>         (foo lexical-n a b c))))
>
>   (dotimes (i 22)
>     (fset (intern (format "foo-function-%d" i))
>           (make-foo-function i)))
>
>   (foo-function-21 1 2 3)
>
> I there's anything unclear about this code or the defmacro-approach I
> gave you before, just ask. 
>
>   
>> Can do that by hand, sure. But as the issue shows up occasionaly, a tool
>> doing these extractions might be useful.
>>     
>
> Maybe I didn't get the issue right: you've got repetetive code to
> start with and want to have it refactored automatically?

yes
> It's
> certainly possible to have such functionality, on the other hand, you
> don't have to write repetetive code in lisp in the first place,

yes, rather avoid it. The scenario is: it just happened.
Precisely while writing some tests.

Wrote one form testing a patch,
another form testing another patch,
then remarked the parallels...

Thanks again

Andreas

>  that's
> what macros are for. And, as shown above, you can also use functional
> programming techniques to the same end. 
>
> All the best, 
>
> Anselm
>
>
>