Yeah, I was asking more along the lines of "merging into official ar"; obviously I can do whatever I want in my personal fork. Or with Arubic.
---
"[...] ideally ar would be powerful enough that someone could implement e.g. keyword arguments as a library."
Would be awesome if we could figure out a way to do that.
---
""I could implement keyword arguments if only ar had X" is more likely to win me over to thinking about the best way to add X to ar."
I'll give some thought about the precise requirements for keyword args. Message passing too.
---
"With respect to backwards compatibility... since ar is supposed to be hackable, one of the ways it should be hackable is to get it to produce a runtime that is mostly compatible with Arc 3.1. But on the other hand, if someone wants to implement a language which is completely incompatible with Arc 3.1, they should be able to do that as well."
Yes, but if the changes need to be done in the core (and not as a library on top of the core), then backwards compatibility does become an issue, since you've already stated you're trying to be mostly-compatible with pgArc. Ideally, any backwards incompatible changes will be done to make ar as hackable as possible, lessening the need to change the core in the future.
> "[...] ideally ar would be powerful enough that someone could implement e.g. keyword arguments as a library."
Would be awesome if we could figure out a way to do that.
The compiler is reflected into Arc so if all you need to do is make compiler changes you can do that by modifying "ac" or the functions it calls such as "ac-call". If the feature also needs to make runtime changes then we might need to add some hooks to the runtime to enable that.
Hm... interesting. In that case, I might be able to implement Arubic as a bunch of extends and maybe some supporting functions... then Arubic would basically be a thin skin over ar. I'll look into it.
