[racket] multi-replace function

On Mon, Dec 6, 2010 at 10:21 PM, prad <prad at towardsfreedom.com> wrote:

> i'm trying create a multi-replace function in racket where you can
> substitute for patterns in a string with items in a list:
>
> (mult-repl "~A"
>           "this ~A string will experience ~A substitution"
>           (list "wonderful" "massive"))
> -> "this wonderful string will experience massive substitution"
>

Since it looks like what you are doing is just positional (instead of named)
substitutions, format is good enough for the purpose:

(format "this ~a string will experience ~a substitution" "wonderful"
"massive")

See
http://docs.racket-lang.org/reference/Writing.html#(def._((quote._~23~25kernel)._format))for
more details.


however, the results are quite inconclusive. they jump around for all

of them between 113-300 cpu time, mostly being around 170.
> A. is that because i don't have a sufficiently substantial process
> running?
>

Without seeing the test code it will be know what you are doing to profile
and hence are to comment.


> B. should any of the above be significantly faster than another?
>

The only way to know for sure how fast a code runs is to profile them, but
it looks like you are using the same primitives (string-append,
regexp-split, etc) so they do not look too different.


> speed aside, it seems to me that #2 is the easiest to program and
> understand.
> C. so are regex a good thing to use in these situations anyway
> because it's not like there's anything that's going to be thrown at
> them that will stress the system out ... or is that a bad attitude?
>

Speed is not the most important criteria in programming these days, as long
as it's perceived to be fast enough.  Often times, a performant system
automatically emerges with good design.  And even if it needs some tuning, a
well designed system is more easily profiled and improved.  And over time,
obscurely written code will be hard to understand if you ever come back to
it months or years later, so it is very important to write legible and
understandable code.  Good design and understandable code will pay dividends
even if it might not be the fastest code.

HTH.  Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20101206/d0543733/attachment.html>