This seems more suitable for an imperative style of programming, whereas Arc tends to prefer functional style (no side effects), but it's just a matter of personal taste.
Making a fixnum a pointer to a allocated memory containing the value is terribly slow.
The infinite loop could be caused by two objects that references each other, e.g. a references b and b references a, so the GC keeps going from a to b and from b to a. To solve the problem, if this is the problem, if an object has been already marked, don't follow it.
Attaching too much information to an object leads to serious problems. Think about fixnums: they're usually implemented using 2 bits out of 32 as a type tag. This way you don't have to allocate them on the heap. If you attach an extra information you have to put everything on the heap (very slow for fixnums).
As of collections-in-function-position instead of returningm for example, and hash-table one could return a fuction that acts as an interface towards the real hash-table.
> Attaching too much information to an object leads to serious problems. Think about fixnums: they're usually implemented using 2 bits out of 32 as a type tag. This way you don't have to allocate them on the heap. If you attach an extra information you have to put everything on the heap (very slow for fixnums).
Then let's not attach both types to the same object. pg's implementation creates a new object and attaches the type to that object, leaving the original representation object (type id and all) untouched. Basically we have an annotation type which just contains the attached type and the original object, leaving the type id bits untouched.
> This doesn't handle setting values, but I think that a few macros could solve the problem.
Yes. I implemented fixnums with the last bit as a tag-bit. If it's 0, everything else is a fixnum. If not, well, it's something else... Maybe nil, t or a reference to something else.
Your idea for callable collections seems quite good, too. But I'm not there yet.
Some compilers are not metacircular, so you could skip the first part and pass directly to the second. The difficulty depends on the knowledge of the compiler you want to modify. Anyway, this seems a rather difficult task.
I think I'll just say that CL-Arc is only compatible with the subset of CL implementation that do tail recursion. (Which happens to be all the implementations I would consider using anyways.)
CL reader is highly extendable and you can tell it to be case sensitive: (setf (readtable-case readtable) 'sensitive), if I remember correctly. It's possible, I think, to use it to read Arc code.
But assuming it works in some form or other, it should remove most of the need to write a custom reader. Though there is still the issue of (for example) complex number syntax, etc.
It's in the standard (CLTL2). You can fix everything, because you can tell the reader to use your own functions on particulars characters, as an example this is a piece of code that lets you use Arc [... _ ...] syntax in Common Lisp:
You could add to the proposal various useful libraries, such as libraries to use HTTP, FTP, SMTP, etc. protocols, bindings to access databases, graphic libraries, etc. You just have to choose.
