Also, in line with the whole "hacking on ar" thing, mind if I add in some Arubic-y things, at least the ones that are backwards compatible with pgArc? Like... message passing, for instance. Or keyword args (though that's not 100% backwards compatible, it's really close[1]).
---
* [1]: If somebody happens to use a symbol that starts with a colon, then keyword args could change the meaning of their program. But I wouldn't expect symbols prefixed with : to be very common.
Of course you can make and publish any changes you want, it's open source so you don't need my permission to do anything :-). Perhaps you're asking whether I'll merge your changes into my version? A goal of ar to make Arc more hackable, so ideally ar would be powerful enough that someone could implement e.g. keyword arguments as a library. Smaller changes will often be easier to digest, so saying "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.
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.
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.
