>> Anyway, here is my submission (sans parsing)
> I haven't read your code yet, but I will. Meanwhile, could you
> provide a high-level comparison of your explicit implementation with
> the one in my original message?
It pretty much does the same thing, but, arguably, in a fancier way.
x is ruleset, y is target string
ruleset is n by 3 matrix of boxed pattern, replacement and termination
flag in that order.
ri cycles through rule indexs selecting current rule in r. p takes
pattern from this rule and z marks the beginnings of this pattern in
target string. Then ri is incremented, but if pattern matches (z has 1
in it), then (here comes fancy part) pattern is replaced with a target
(and here fancy part ends) and ri is reset to 0 or _ (depending on 3rd
component in rule r, which is "terminating" flag)
mapply=: 4 : 0
ri=.0
while. ri<#x do.
z=.y E.~ p=.>{.r=.ri{x
ri=.1+ri
if. +./z do.
y=.((> 1 { r) , (#p) }. ])&.((z i. 1)&|.) y
ri=._*>{:r
end.
end.
y
)
> [1] Maybe we should capture such situations in a "When to be
> explicit" essay. What other situations call for explicit code?
> State, side effects, object management ... anything else?
If you ask me, the answer should be "always" or "almost always".
Tacit has its charm and its place, but you can just do more things
simpler if you allow explicit constructs, especially temp variables.
Also, if you are looking for real challenge, instead of "explicit vs
tacit" try "boxed vs flat". Take some function that relies on boxing
internally and rewrite it using only flat arrays.
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
