Arc Forumnew | comments | leaders | submitlogin
1 point by shader 3212 days ago | link | parent

One of the other ideas I've had for the auto-doc feature of arc is a modification to the help op on the web server that instead of just looking at names between [[ ]] a) prints the source if in verbose mode and b) if so searches the source tree of the fn or mac for all symbols bound to fns or macs and makes them links. That would provide a pretty cool code explorer tool that would (almost) rival arc-fn

So I have a few questions:

1) What is the best way to search a source tree.

2) Currently src works by having a hook in def save the source to the table just like help, but that means that only things defined by def and mac actually have source entries. What about all of the xdefed functions? Should I add a hook to xdef as well? We could add docstring support to xdef too I suppose.

3) Since src saves the source after read, it has all of the reader macros already expanded, such as backquote and br-fns. Is there a way to get around that so that the source is more readable?



1 point by shader 3211 days ago | link

Is it possible to condense the form (quasiquote l), (unquote l), (quote l) and (make-br-fn l) into their respective string based syntaxes? How would you go about doing this?

What is the arc method for mapping a function across a tree?

-----

2 points by absz 3211 days ago | link

You could try doing something like

  (def syntaxify (xs)
      (map
        [if (acons _)
          (case (car _)
            quote            (string "'"  (stringify:cdr _))
            quasiquote       (string "`"  (stringify:cdr _))
            unquote          (string ","  (stringify:cdr _))
            unquote-splicing (string ",@" (stringify:cdr _))
            make-br-fn       (string "["  (stringify:cdr _) "]")
                             (syntaxify _))
          (stringify _)]
        xs))
where stringify is some function that does sensible stringification. I don't know precisely how you're doing this, though, so that might not work.

-----

1 point by shader 3211 days ago | link

>I don't know precisely how you're doing this, though, so that might not work.

All my source table does is

  (sref source* '(def ,name ,parms ,@body) ',name)
for def and

  (sref source* '(mac ,name ,parms ,@body) ',name)
for mac.

Since name, parms, and body are read by the reader, reader macros have already been expanded. I'm looking for a way to print the source in a more readable fashion.

Your functions looks pretty close to what I want. Maybe stringify could just be syntaxify, and make it recursive? I don't know if tail recursion is possible because of make-br-fn, but the rest of it looks pretty simple.

If the current object is a cons, but not one of the above, return "(" (syntaxify:cdr _) ")", and if it's an atom return (string _).

I'll do some more thinking on it, but it looks like you're on the right track.

-----

1 point by absz 3211 days ago | link

That would work, except that

  (do
    (zap [cons 'head _] xs)
    (prn xs))
would come out as something like

  (do(zap[cons'head_]xs)(prnxs))
and I'm not sure how to deal with that, even if we add spaces.

-----

1 point by shader 3211 days ago | link

Adding spaces shouldn't be too hard; are you saying that we don't know how to handle indentation and newlines? I don't think that should be too hard. Looking at ppr and friends in string.arc should give us a clue as to that.

Is it possible to create a list in which the syntax is not expanded? I.e. preserve our syntaxification, after we've completed it? So that ', `, , ,@ [] become part of their symbols? That would probably be helpful, because then we could just use the built in ppr function, and not have to worry about formatting.

-----