This would need help from macros: since a macro can output an arbitrary form, it would be up to the macro to identify what exactly in the input to the macro it was constructing a function from.

Which isn't to say all macros would have to do this... it could be an option, that when you wrote a macro you could go to some extra effort to help out with source location tracking if it was important, but you wouldn't need to if it wasn't.

My current attempt at adding source location tracking to Arc macros is too ugly for words; however, at the moment, I'm happy to be able to get it to work at all. Hopefully some patterns will become apparent which can be turned into macro utilities or some such which will make it less terrible.

Before I got to that point though I ran into a roadblock... in what may be a Racket bug, Racket's `write` is hanging when I try to print the Arc forms being transformed by the macros for debugging. These forms in this case is a weird mixture of Racket syntax objects providing source location information wrapping Racket mutable pairs implementing Arc lists.

I haven't spent any time looking into this bug, or even figuring out if it really is a bug, because using Racket syntax objects as the implementation for labeling Arc forms with source location information isn't where we want to end up anyway. It was a convenient way to get started with because where we take the output of the Arc compiler and feed it to Racket's eval, we do at that point want to take the Arc representation of source location information and turn it into a Racket syntax object so that the Racket compiler knows what to do with it. But there's no need for the representation of source location information inside of Arc to be implemented with Racket syntax objects, and it would be less confusing if it wasn't. Even aside from the possible Racket `write` bug.

So I'll be backtracking to redo the implementation of how Arc forms are labeled with source location information before moving forward again with the source location tracking experiment.

Meanwhile I have some minor updates and bug fixes for the 0.0.2 release:

- Embarrassingly, "amacx foo.arc" was loading "foo.arc" from the Amacx installation directory instead the user's current directory.

- We can now boot using Racket namespaces as the container for top level variables; and this is now the default. This brings the time to load arc.arc down from 9 seconds to 4 seconds, still miserably slow but at least not as slow as it was before.

- Merged ssyntax into the compiler; having it implemented as a compiler extension was a clever idea but it was too hard to support cross compilation that way. Maybe some day.

https://github.com/awwx/amacx