Arc Forumnew | comments | leaders | submitlogin
1 point by aw 4985 days ago | link | parent

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.



1 point by Pauan 4985 days ago | link

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.

-----

1 point by aw 4985 days ago | link

> "[...] 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.

-----

1 point by Pauan 4985 days ago | link

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.

-----

1 point by aw 4985 days ago | link

This is a goal of ar: I don't know if it's actually possible or not, but ideally you should be able to implement Arubic as a library on top of ar :-)

-----