However, I'm not 100% sure why you're using global variables in inst-entity1 in the first place - is there some special reason?
3. docstrings would be nice ^^.
4. The actual code seems to use addtemscaff (not addscaff) and rname (not ename). Or am I looking at the wrong code?
Edit:
5. You seem to be storing the code added by addtemscaff as lists of expressions. Why not store them in a function? That way we can capture variables into an environment instead of forcing the user to always use globals.
6. The (each v tablist.scaffold ...) could probably be transformed to (ontable k v scaffold ...)
> 1. scaffold.arc / inst-entity1 uses global variables. Is this deliberate? Why?
The arc eval doesn't seem to support local environments or passing of environments, so this is the only way to pass in anaphoric variables I could find on my first pass. This function could probably be rewritten without eval and with proper scoped anaphoric variables, but given what is happening in the code this requires serious macro-fu. I do sort of know what I'm doing here- The evals and global vars don't make me feel good either... I will clean this up eventually, but won't complain if someone else figures out how to do it first :)
> 2. Personally I would recommend using the following interface to inst-entity1:
> 5. You seem to be storing the code added by addtemscaff as lists of expressions. Why not store them in a function? That way we can capture variables into an environment instead of forcing the user to always use globals.
I am planning on adding a command for debugging scaffolds, where the instances of the scaffold are instantiated and pretty-printed to make writing scaffolds less uber-meta. Having functions would prevent this- But you are right that using functions might be the Right Thing. I'll give it some thought.
> 6. The (each v tablist.scaffold ...) could probably be transformed to (ontable k v scaffold ...)
Yes I think you're right. This is definetely "release early, release often" type code, so there's lots of room for improvement.
> a command for debugging scaffolds, where the instances of the scaffold are instantiated and pretty-printed ... Having functions would prevent this
Looks like we should really be solving the correct problem: make function code pretty-printable ^^. Yes, I think I'll solve this using attachments again... ^^ Go attachments! http://arclanguage.com/item?id=3698
Edit: Which reminds me, I haven't actully grokked this scaffolding thing at all yet. I'll be home in maybe 3-4 hours, hopefully I can get the weekend for this, unless I do something stupid, like track down where the girl I'm trying to see is hiding ^^.
