Arc Forumnew | comments | leaders | submitlogin
1 point by Pauan 5107 days ago | link | parent

"Ah, I don't think this is a Racket problem."

Fair enough. I had somewhat assumed that the problem was Racket, because Arubic handles it just fine. My mistake.

That actually looks like a pretty good command line parser. Thanks for the links!

P.S. Once ar gets into a somewhat more complete state, you may want to consider making shell scripts work good with it. For instance, if I'm in the directory /foo and I run a script that's in /usr/bin and the script uses (load "lib/bar.arc"), I would expect it to load /usr/bin/lib/bar.arc, not /foo/lib/bar.arc.

I made this work in my copy of pgArc, but it'd be nice to have it be more standardized. Obviously it should be possible to load relative to the current directory as well, if your script wants to.

Mind if I go in and start hacking on ar? :P If I decide to make an Arc compiler in Arc, I'd probably base it on ar.

---

"The advantage of an axiomatic approach is once you have them implemented, the rest of the system will run on top of them... but the powerful axioms may be hard to implement."

That is true. I do like the axiomatic approach, but I think Arc can improve and become even more axiomatic, which is one of my goals with Arubic.



1 point by aw 5107 days ago | link

Mind if I go in and start hacking on ar

Please do! (that's why I put it on github :)

By the way, the hackinator (https://github.com/awwx/hack) does generate an Arc program that can be run from the shell from any directory (for example https://github.com/awwx/hackbin/blob/master/hack works this way). I just haven't gotten around to getting it into ar yet.

Oh, and just so you know the above example produced by the hackinator incorrectly uses aload to load Arc files after arc.arc has been loaded instead of using Arc's load; this a known issue I've listed in the to-do list in the README.

-----