Arc Forumnew | comments | leaders | submitlogin
2 points by Darmani 5822 days ago | link | parent

Let's call these anonymous functions whose arguments are the unbound symbols within them in alphabetical order "ofn"'s.

The clearest way to implement ofns is to have a function on the outside of every block of code which does a tree-traversal, collecting all the symbols bound, and then, whenever it finds and ofn, just simply does (sort < (rem [mem _ bound-list] (get-list-of-symbols-used ofn-code)) to find the args list.

There are two major issues with this. The first is global variables -- it needs to determine which symbols will be bound in the global scope at runtime at compile time. Let's assume all global bindings will be done at the top layer or in a layer separated by nothing by calls to 'fn from the top (please, tell me you don't bind your globals in 'eval). (E.g.: (let a 1 (def b ...)) becomes ((fn (a) (= b (fn ...))) 1) and thus meets that criteria, but (def a (b) (= b 1)) becomes roughly (= a (fn (b) (= b 1))), and thus the call to (= b 1) has a call to = between it and the top, and thus will not be counted.) In a process very similar to the overall version, we can then go through the macro-expanded files, and find all the symbols bound by those = forms.

The second problem is nested ofn's (e.g.: [map [map [+ a b] c] d]). I'm still in search of a good solution. I've thought about finding the arity of each ofn (made impossible in the general case by higher-order functions like map which call functions with a variable amount of arguments); finding where each variable is used to determine its minimum scope, and having each symbol an argument of the ofn with that minimal scope; letting inner ofns each have one arg, determined by some alphabetical ordering, and letting the outer ofn have the rest. All those solutions fail some major elegance tests. Best way is probably to just ban nested ofns.

At first I would have said ofn's would be a great feature, but, if we can't have them nested, I can't be so sure -- it would be inelegant to have nested bracketed functions work differently that the outer one, or to have a different delimeter for ofns and normal square-bracketed functions.

Ironically, the difficulty in implementing this dynamic feature stems from the source code of dynamic languages being difficult to analyze.



2 points by shader 5822 days ago | link

It seems to me that, however we do it, it would probably be slow. Maybe, as the source is being read in, the compiler/interpreter could somehow flag each symbol as bound or unbound? Then you could have your ofns just inspect all of the symbols below them, and check whether they're bound or not.

About nested ofns, how would you expect them to work? That should be the real test of what method to use in determining which ofns bind which vars. Obviously they're bound in alphabetical order. How about having the outer ofn bind as many vars as it has args, and leaving the rest unbound for the next layer? This would make it impossible to tell which ofn would bind which var at compile time (unless you know the arity of the outer function based on it's environment), but it would (I think) make the most sense. It does leave room for confusing circumstances though ;)

What would happen if there weren't enough arguments to fill in all of the vars? Return a fn? Even more fun!

If the ofns bind inwards, you would need to do your example backwards: [map [map (+ d c) b] a]

You could however try and bind outwards, so the inner ofn binds first, but I don't see how that would be a good idea.

What do you think? Any better ideas? Any glaring flaws with my idea? (I don't know lisp or arc that well)

-----

1 point by Darmani 5821 days ago | link

Source-code traversals are O(n), and compile-speed is not that important below a certain point. And finding all the globals only needs to be done once.

At first I thought it was important to have this conventionalize-ofns function run inside every def and every mac, so that, if I wished to use ofns inside a macro-expansion, which symbols are arguments would not depend on the context. I then realized this would break for virtually any method of generating macro-expansions other than quasiquote, and that, since, under the curretn implementation, two pseudo-gensyms have the same alphabetical ordering as the order they were created in unless they're of different length, it would still be workable (just do a (w/uniq (a b c) ...) and I'll hardly notice the difference -- saves fewer characters overall, but I find it a little more readable; plus, these can be reused if the macro-expansion contains multiple ofns).

If we are to do ofns at runtime, they would be much more workable, but also more unpredictable. I've said once before that a runtime-list of all bound symbols would be desirable for other reasons, but, if I'm testing code in the REPL and set a to some value, I don't want half the functions I call breaking for some mysterious reason. Especially considering I haven't found a way to unbind variables.

-----

1 point by shader 5821 days ago | link

Well, I think that the ofns should probably be closures, at which point the binding of the variables only matters when they are defined, after that defining a out of context wouldn't overwrite the a in the ofn. If not, we could have the ofn replace each symbol with a gensym tagged with 1st, 2nd, 3rd, etc. Then it wouldn't matter what you did with the original name. The gensym replacement only happens, of course, if the var is unbound during definition.

Here's a question: how does anarki's [ _1 _2 _3 ] form work when nested?

-----