Andrew Nikitin wrote:
>  I am not sure the problem can be handled by tacit expressions better 
>  than with explicit expressions.  

I had come to the same conclusion, but I wanted validation (because I find 
explicit loops distasteful).

>  In J as it is there is no information flow between
>  body and predicate, but for this problem there is a significant sharing
>  of information. predicate is true when a non-terminal rule was applied
>  and body is the application of this rule.

Yep; I think you captured the essence of the problem perfectly; this'll help me 
identify similar situations later*.  I had a small
twinge when I realized that at least for rule-reapplication, the test of 
whether to "start over" is exactly if the target has
remained unchanged, and so I thought there might be a clean way to use  ^:_  to 
detect this stabilization.  But you're right, even
if  ^:_  worked for that situation, it wouldn't work for early termination.

>  Also, I believe, if you are demanding "tacit" solution, you should also use 
> only tacitly defined utilities. 

Yep; you can see an example of a completely tacit solution at [2].  Well, 
actually it's not completely tacit because it uses rxmatch
and rxcut.  But that doesn't bother me; I view and used standard utilities and 
Addons as black boxes.  It's not my concern if
they're tacit or explicit; I only worry about my own code [3].  And the tacit 
version I wrote does implement its own tacit replace
function (for reasons discussed below).

>  stringreplace (which seems to be the cornerstone of the algorithm) 

Ah, no, stringreplace was only used in the initial, quick-and-dirty hack.  
Actually, stringreplace itself is what motivated me to
rewrite the solution entirely; not because stringreplace is explicit (as I 
said, I consider it a black box), but because it does
exactly the wrong thing in this context.  Not only does it apply all the 
substitutions at every pass, but it actually makes all
possible replacements for each substitution.  I actually think that's the 
proper and natural way to implement a term rewriter, but
was perturbed to discover that Markov algorithms specifically and intentionally 
deny this implementation.  

It was exactly this part of the specification that motivated my message.  
Anyway, you can ignore the "stringreplace" formulation and
focus your attention on the explicit and tacit formulations at [3].

>  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?

-Dan

[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?
[2]  http://rosettacode.org/wiki/Talk:Markov_Algorithm#explicit_vs_tacit 
[3]  But using standard utilities does prevent me from creating fully fixed 
tacit code that happens to use standard utilities.  I
used to use my "fix local" utility to get around this limitation, but since 
Roger changed (broke!) 15!:6, that doesn't work anymore,
and I haven't gotten around to rewriting it.

PS:  For anyone who read the original message and wanted some test data:

           m1 =. noun define
                # This rules file is extracted from Wikipedia:
                # http://en.wikipedia.org/wiki/Markov_Algorithm
                A -> apple
                B -> bag
                S -> shop
                T -> the
                the shop -> my brother
                a never used -> .terminating rule
        )
         
           m1 markov 'I bought a B of As from T S.' 
        I bought a bag of apples from my brother.



----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to