hmm! I'm going to have to look into why inline isn't working for macros in ar. In ar macros are implemented by vectors (same as Arc 3.1), and vectors aren't deep copied... so I'm wondering how the code is managing to create a new vector that would then not be eqv? to the original macro vector...?
By the way, ar is pretty awesome. It's so simple.
Why thank you :) The simplicity has been a lot of work, but was quite necessary... at least for me. Someone smarter than I am, or someone who understands the Arc 3.1 compiler better than I do, likely could have gone ahead and just implemented Arc lists with Racket mpairs directly in the Arc 3.1 compiler, but I got lost when I tried it.
> In ar macros are implemented by vectors (same as Arc 3.1)
I did not know this. Are functions implemented by vectors too, or does it have to do with macros being annotated functions (i.e. that annotate is implemented as some sort of vector-wrapper)?
annotate is implemented as some sort of vector-wrapper
That's the truth. The result of (annotate 'foo 'bar) is #(tagged foo bar), where #(...) is the external representation of a Racket vector. Note that 'tagged here is just a symbol like 'foo or 'bar.
I wonder if Arc could instead use a custom Racket type so that we don't have quirky abstraction leaks when using Racket vectors. I never actually find myself wanting to use vectors, and if I did, I'd just [annotate 'vector _] them, but still. :-p
I did an experiment where annotate produced a list, of the form ('tagged x type1 type2 ...), making the tagged lists transparent objects to the arc system. In doing so, I extended the type system to include the original type of the object in the list and support more than one type, allowing a simple form of inheritance through coercion. I.e. if you annotated a list as type 'foo, until you defined an actual coercion method for converting 'foo to a cons it would be treated as a normal list, and you wouldn't lose any ability to work with it using existing operations.
The thing that annoys me the most about arc's current type system is that if you tag something, it becomes an unusable vector according to all existing arc code, so you need to re-implement or extend any function that you actually want to support the new type.
I think he made the additional change of delegating all functional calls to the "parent" type when they didn't explicitly handle the type at hand. This makes a lot of sense. If you have a list that's tagged 'foo, it should behave exactly like a normal list does until you've specified some diverging behavior for type 'foo.
Do you still have the code for your experiment, shader?
Like I said, it hardly matters to me 'cause of the [annotate 'vector _] workaround.
More worthwhile would be having custom 'iso hashing and stuff like that. ^_^ That's something that would probably benefit from a dedicated Racket type for tagged values, but that's not necessarily the only way to go about it. I'm still trying to figure out how to go about it for Penknife....
