This arc seems faster than rainbow in start-up, but slower in execution.
On MacBook Air 2019, for N-queens puzzle (N = 9 and 11),
$ time java -jar arc.jar ~/tmp/arc-in-java-0.2.0/9queens.arc
352
real 0m1.634s
user 0m3.056s
sys 0m0.159s
$ time java -jar arc.jar ~/tmp/11queens.arc
2680
real 0m27.865s
user 0m29.582s
sys 0m0.242s
and
$ time java -jar rainbow.jar -q -f ~/tmp/arc-in-java-0.2.0/9queens.arc
*** redefining no
*** redefining map1
*** redefining pr
*** redefining list
352
real 0m2.279s
user 0m6.492s
sys 0m0.246s
$ time java -jar rainbow.jar -q -f ~/tmp/11queens.arc
*** redefining no
*** redefining map1
*** redefining pr
*** redefining list
2680
real 0m9.812s
user 0m14.462s
sys 0m0.360s
where
$ java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)
As for the code size, this arc's arc folder has 4,626 lines of Java 11
while rainbow's src/java/rainbow folder has 14,520 lines
(72,190 lines including auto-generated ones) of Java 5.
In short, this arc is a small-scale implementation of Arc.
It's great to see you again! Sometimes I've wondered about the status of Semi-Arc. Looks like you've been working on a number of other Lisp implementations in the meantime! Pretty exciting. Thanks for sharing this update with us.
As someone who ported Rainbow line by line to JavaScript, I have to say, the size of the codebase can be quite daunting. A smaller implementation sounds a lot easier to work on.
case ContOp.ApplyFun: // exp2 is a function.
[exp, env] = applyFunction(exp2, args, k, env);
if (exp instanceof Promise)
exp = await exp;
break;
This means the web page is still interactive during the evaluation effectively.
Here is an example: https://nukata.github.io/little-scheme-in-typescript/example.
Click the "Load" button twice and you will see two "yin-yang puzzle" threads run on the page.
Click the "Stop at Writing" button twice to stop them.
$ java -jar semi_arc.jar
arc> (let ((o x 2)) nil x)
2
arc> (let (a (o b 2)) '(1) b)
2
arc> (let default 2 ((fn ((o x default)) x)))
2
arc> (let default 2 (let ((o x default)) nil x))
2
arc> (let default 2 (let (a (o b default)) '(1) b))
2
arc> (let (x y) '(a b c) y)
*** 2 args expected for #<fn:2::(#((a b c)))>: (a b c)
0: (#<done> #<fn:2::(#((a b c)))> a b c)
arc> (let (x y z nothing) '(a b c) nothing)
*** 4 args expected for #<fn:4::(#((a b c)))>: (a b c)
0: (#<done> #<fn:4::(#((a b c)))> a b c)
arc>
I upvoted you 'cause Semi-Arc's doing what you want it to do (which is what really matters), but I'd like to mention that I actually kinda appreciate the way Arc accepts mismatched destructuring lengths.
I've seen other people's code use a (let (a b c) nil ...) idiom as a shortcut for (with (a nil b nil c nil) ...). As for me, I like being able to design multiple types so that they can be used in an ad-hoc polymorphic way like this:
Both these techniques could still be used in an Arc implementation with a stricter treatment of destructuring: The first could be done by defining a 'w/nil macro, and the second could be expressed as (let (x y . rest) rep.point ...). In your favor, the strict treatment makes it easier to write functions that do complain if the length is incorrect, encouraging fail-fast code. However, as far as portability is concerned, the "N args expected" errors are a quirk of Semi-Arc.
I'm going to try out Semi-Arc right now. ^_^ I'm sure I'll have some error reports for you in a moment. Hopefully not too many! :-p
Nice. Have you played around with multiple arc implementations in the process of making semi-arc? I'd love to read about your experience writing semi-arc, and the design decisions you made. (email in profile if you want to chat further)
No, I have not played the original Arc yet and had hardly known both implementations in Java until recently. My version 1 implementation was a little Lisp written in ISO Standard Pascal:
Little Lambda Lisp in Standard Pascal
http://www.oki-osk.jp/esc/llsp/v1.html
You find the notable(?) feature of Semi-Arc, macro expansion without free symbol capture, even in the version 2 of it:
Little Lambda Lisp 2 in Standard Pascal
http://www.oki-osk.jp/esc/llsp/v2.html
I had translated it to Ruby, Python, C# and Java. Recently I noticed that its design is near to the core of Arc. I made it up so that it may look Arc:-). The result is Semi-Arc.
As for argument destructuring, I implemented it in a simple, general and recursive (but not so efficient) way. Track the variable 'nestedArgs' in the method 'compile(Cell j, Cell env)' in the source:
