load-w/rename

Load an Arc source code file with renames

load-rename1.patch

diff --git a/arc.arc b/arc.arc
index 3ae2830..63d2013 100644
--- a/arc.arc
+++ b/arc.arc
@@ -993,6 +993,14 @@
       (cons (tree-subst old new (car tree))
             (tree-subst old new (cdr tree)))))
 
+(def tree-substs (substs tree)
+  (aif (alref substs tree)
+        it
+       (atom tree)
+        tree
+        (cons (tree-substs substs (car tree))
+              (tree-substs substs (cdr tree)))))
+
 (def ontree (f tree)
   (f tree)
   (unless (atom tree)
@@ -1406,11 +1414,14 @@
        (pr ,@(parse-format str))))
 )
 
-(def load (file)
+(def load (file (o transform idfn))
   (w/infile f file
     (w/uniq eof
       (whiler e (read f eof) eof
-        (eval e)))))
+        (eval (transform e))))))
+
+(def load-w/rename (file substs)
+  (load file (fn (e) (tree-substs substs e))))
 
 (def positive (x)
   (and (number x) (> x 0)))

description

thaddeus wanted to use my JSON library, but it defined a function called “alt” which conflicted with another library he was using that had a function with the same name.

Conventionally, libraries are supposed to carefully hide away their internals to avoid just this kind of conflict. There’s a couple of problems with this approach though:

• The library author doesn’t know how the library is going to be used, so the effort made to avoid conflicts is speculative: time may be spent hiding a function which as it turns out never would have caused a conflict in the future, or if the function hadn’t been hidden away it might have turned out to be useful to other code in ways that the library author hadn’t thought of.
• Even after going to the extra work and attendent code complication of hiding library internals, the library may still be making names visible which conflict with some future use of the library.

Thus the problem with the conventional approach is that the library author is being asked to take responsibility for avoiding conflicts at the time the library is written, when it is impossible to know what actually needs to be done to avoid conflicts because the actual conflicts can’t be known until the library is used with other software.

Whether or not the library author has attempted to avoid conflicts by hiding library internals, if a conflict does occur then it falls upon the programmer using the library to resolve the conflict.

One approach to resolve the conflict is to simply rename the offending function or macro in the library, giving it a name that doesn't conflict with the other code being used.

Naturally if there’s some renaming that needs to be done, we’d prefer to let the computer do it for us rather than tediously having to go through the library source code doing the renaming by hand.

 (load-w/rename "json.arc" '((alt json-alt)))

get this hack

wget http://ycombinator.com/arc/arc3.tar
tar xf arc3.tar
cd arc3
wget -O - http://hacks.catdancer.ws/load-rename1.patch | patch

comment

license

public domain