Arc Forumnew | comments | leaders | submitlogin
1 point by almkglor 6138 days ago | link | parent

Hmm. Somehow I don't quite like the "scaffold" anamorphic variable, since it strikes me that it is accessible (indirectly) via (ename):

  (addtemscaff foo thingy
    `(= (,(ename) 'property) 'value))
edit: using (ename) would also allow us to dynamically change the entity itself:

  (addtemscaff foo thingy2
    `(def ,ename!-foo-function ()
        (prn (,ename 'property))))
end edit.

By eliminating the scaffold anamorphic we can then create a purely macro-based system without having to use eval, which personally makes me nervous.

  (mac addtemscaff (scaff name body)
    `(addtem ,scaff (scaff ,(++ scaff-maxid*) ,name)
             (fn (sname entity ename)
                 ,body)))

  (mac inst-entity (ename sname . entity)
    (inst-entity1 sname entity ename))

  (def inst-entity1 (sname entity ename)
    (let ordered-scaffs (sort (fn (a b) (< (cadr:car a) (cadr:car b))) (keep (fn ((k v)) (and (acons k) (is 'scaff (car k)))) tablist.scaffold))
      (each ((x y fname) v) ordered-scaffs
            (prn "scaffolding " ename ": " fname)
            (v
                     (fn ((o suff nil))
                         (sym:string sname suff))
                     entity
                     (fn ((o suff nil))
                         (sym:string ename suff))))))


1 point by drcode 6138 days ago | link

> Hmm. Somehow I don't quite like the "scaffold" anamorphic variable, since it strikes me that it is accessible (indirectly) via (ename)

It is true that you could access the scaffold template object by using sname (which stands for "scaffold name" as opposed to ename, which stands for "entity name")

This might make sense... I'll give it some thought...

> By eliminating the scaffold anamorphic we can then create a purely macro-based system without having to use eval, which personally makes me nervous.

This doesn't seem to be true... the reason the "eval" is needed is because calling the scaffold function ("v" in this case) just returns an sexp, which then still needs to be evaluated. I don't think the code sample you gave without the eval could be made to work. (That eval is basically the "magic" that lets you write a single scaffold for a "def" and have it become multiple defs, one for each entity (i.e. producteview, customerview, orderview, etc.)

The only way I can see to get rid of this final eval is to not have an inst-entity1 function and elevate all the logic to be part of the inst-entity macro. Then, the entire set of scaffold sexps could be unquote-spliced into the body of the macro- This is probably a good idea, but I haven't gotten to it yet. (I actually tried doing something like this once in scheme, but scheme "define" has limitations when not used at the toplevel- I believe they fixed this in R6RS because of complaints. Arc defs can be used without constraints at any level I think, so that specific problem wouldn't exist)

-----

1 point by almkglor 6138 days ago | link

Err, I am using inst-entity1 as a call within the inst-entity macro ^^, so the return value of inst-entity1 is evaluated.

So I guess it should really be more like:

  (cons 'do (w/collect:each ....
    (collect (v ...))))
Where w/collect is a macro similar to one I built some time ago. http://arclanguage.org/item?id=4390

-----

1 point by drcode 6138 days ago | link

Ah I see now...

It still doesn't look like it would work though, since a scaffold could have like 30 sexps and only the last one would be evaluated by your sample I think...

but if the "each" was changed to a "map" and a "do" was inside the macro I think it could be made to work that way- That's along the lines of what I was thinking

-----