| Hi Paul, Thanks so much for making Arc available. Along with many others, I have been waiting for this for years. I already prefer Arc over Scheme, even just for its sane booleans. However (and I'm sure you're aware of this), you have a long, very steep climb ahead of you if you want to approach Common Lisp in terms of specification and implementation. Some concerns: * I think your let/with will make certain important special cases longer and more cumbersome. Compare: CL> (let (a b c)
...)
vs arc> (with (a nil b nil c nil)
...)
Or, even worse: CL> `(let ,vars
...)
vs arc> `(with ,(apply + (map [list _ nil] vars))
...)
A possible solution is to have another form, say cl-let. Or (my preference) use CL's let and drop your let/with.* It seems there is no way to create dynamic bindings. Is this true? All variables seem to be lexical: arc> (= tp 'global)
global
arc> (= tp2 (let tp 'local
(fn () tp)))
#<procedure: tp2>
arc> (tp2)
local
Will this valuable feature (dynamic scope) ever be available? If not, is there any reason to append s to global variable names, or is this now an onion? Common Lisp does-this* to remind programmers that the symbol is intended to be used to establish dynamic instead of lexical bindings. All Arc bindings seem to be lexical so I don't see what useful information the earmuffs (I guess half-earmuffs) convey.* Efficiency. I'm particularly concerned about the efficiency of the combination of generalised variables and Arc's function-position access of sequences, etc. Take this example: arc> (def set-0th-element-in-this-vector (q)
(= (q 0) 9876)) ; If only I could tell
; Arc to assume q is
; a vector. It could
; even open-code it.
vs CL> (defun set-an-element-in-a-vector (q)
(setf (aref q 0) 9876))
From what I can tell, there is no way to avoid type dispatching. This function needs to consider that q can be a hashtable, vector, string, whatever. Of course, lisp does type dispatching all over the place, but assignment seems to me to be a particularly important area to optimise. It isn't clear to me how much type inference will help here either.* On that note, where are declarations?! * Where is macrolet?! * Documentation. As Kenny said in another post, many of the macros are opaquely terse. The only way to currently find out what they do is to read the uncommented code. Docstrings? Describe? * If you have to have call/cc, please ensure it is possible to implement a non-broken unwind-protect: http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-frame.html * Where are CL's , ++, /, etc REPL variables? Obviously in a lisp-1 like Arc they will need to be renamed, but I use them all the time and would use them even if they had longish names. Or you could make Arc a lisp-2 -- see next. Things I very strongly disagree with: Lisp-1. IMO, lisp isn't best suited to a functional style. This is one of the many lies that Schemers (and apparently Arcers) tell themselves. Make Arc a lisp-2. * Renaming setf to =. It's just confusing. I suggest ! (roots in Forth and Scheme) or possibly $ (looks like an "S", short for setf). * No format or loop. These are very useful DSLs missing from Arc. * Arc compiles to Scheme. It should compile to Common Lisp. Things I very strongly agree with: * Arc's if. * Designing with brevity in mind. I like most of the renaming. * Dropping CL pathnames. Unix won. Overall, except for the points above, I think the design is very sensible and well considered. Maybe in a hundred years or so I'll switch from Common Lisp. :) I for one welcome another lisp. Thank you for sharing your ideas with us and don't let the critics mash you up. Making snippy, contentless comments is easy, coding isn't. Best wishes to you and to Arc, Doug Hoyte
http://hcsw.org | 
