Matthias Felleisen <matthias@...> writes:
.
>
> If this is about sequencing a bunch of functional manipulations, try this:
>
> #lang racket
>
> ;; this would be in a library
>
> (define-syntax let**
> (syntax-rules ()
> [(_ tmp body) body]
> [(_ tmp a b ... body) (let ([tmp a]) (let** tmp b ... body))]))
>
> ;;
> -----------------------------------------------------------------------------
>
> (define (fix str)
> (let** tmp str
> (regexp-replace* " / " tmp "_")
> (regexp-replace* " " tmp "_")
> (regexp-replace* "%" tmp "")
> (regexp-replace* "-" tmp "_")
> (string-upcase tmp)))
>
> (fix "this/is%a-test right?")
>
> I have found this useful and readable in circumstances where the above is a
> sequence of say image
> manipulations where even a for/fold isn't quite right.
>
Using this macro that Matthias shared I made a nice little "tuning tool".
I added the macro form let** to a library and then created a "companion
macro" let-debug** which was similar but which printed out the manipulating
procedure name.and wrapped the manipulating procedure with the "time" function
I.e.
(define-syntax let-debug**
(syntax-rules ()
[(_ tmp body) (begin (displayln 'body) (time body))]
[(_ tmp a b ... body) (let ([tmp (begin (displayln 'a) (time a))])
(let-debug** tmp b ... body))]))
So I write something like:
(let-debug** data image-data
(image->transformation1 data)
(transformation1->transformation2 data)
(transformation2->transformation3 data)
etc. etc.)
This then prints out each procedure name and the cpu, garbage collection and
actual time it uses. I can then see any inefficiencies and once I've fixed
these, instead of having to take out a bunch of "display" and "time" functions
I just have to change one word in my code " let-debug** " back to " let** "
to stop printing the debugging information and be back in production code.
Harry Spier
____________________
Racket Users list:
http://lists.racket-lang.org/users
