We just have a formal definition for + that we don't have right now. (As a side note, this is close to the actual implementation of the '+ defined in ac.scm). How can we know it works for strings, lists ? Does it works on chars or not ?
The goal is not to get rid of, say, -, * and / and implement them in Arc. Their signification is obvious and no one would need to see how they are implemented. This is not a math class. But this is not true of +, because by opening the black box it is, we have :
- the possibility for alternative implementations of the arc compiler, as most of the language is defined in itself. Imagine I want to work on a Forth implementation to put Arc code into fridges or TVs ; or pg thinks it's time to move on a C implementation to have a super-fast Arc. The smaller these axioms, the easier it is to get compatible compilers or to avoid bugs from one version to another.
- the possibility to say "I now want to use + for hash tables, let's add it, how is that implemented ?",
- the possibility to say "I don't need + to work for strings or chars or anything, I just want numeric addition because I'm crunching numbers ; +int is the function in need".
Incidentally, if I want to write +int, the only way to do so currently is to do (def +int a b (- a (- b))), and we both agree to say that it's a bad idea.
Well, that's actually what kept me from Ruby and made me stick with Python for a while. I needed a little speed. Not that much, but Ruby was just below the barrier.
Yes,but no. Once you get in the code of ac.scm, you see that the code is great (really easy to understand everything) but that it can really be optimized in trivial ways.
We already talked about arc<. The original code was : if all the elements are numbers, apply numeric + to the args. If all are strings, apply string-append. If all are lists, apply append. Else, apply numeric + (again). The optimization is obvious there, and I don't think it can be called premature.
There was another one that was fixed by pg in Arc2 (for those interested, it deals with ar-funcall).
I know I wasn't clear. I don't want Arc as fast as light right now. What really bugs be is the fact that I have to wait 3 seconds before I get the prompt. When arc.arc and libs.arc are loaded. That's what I would like to see optimized, as soon as possible.
I was wondering, about the delay during the initial interpretation of (load "arc.arc") and (load "libs.arc") everytime arc is invoked : is that possible to load (and eval) these files once in mzscheme and then save the whole memory in an executable, à la SBCL (maybe other CLs, too) ? I couldn't find it in mzc's doc or in mzscheme's functions, at least in the older versions. That will not solve the problems after loading, I guess, but this one is quite boring (I find).
Obviously, the code of Arc2 in ac.scm has been rewritten in some places, leading to optimisations in some cases but to slowdowns in other places. For example, (fib 10) is about 5 times (!) slower, but (fib 35) is about 30% faster. Maybe there are still easy optimisations possible.
btw, pg's code has been replaced by the older's code on the git, I'll fix that later on.
"when we see people using "lst" in code they mention on comp.lang.lisp, we unleash the hounds who chase them over the fence to comp.lang.scheme where they belong" : be careful, it's not necessarily a schemer, it might also be pg, writing a function where both l and ls are already bound...
Excellent point, it might just be an Arc welder trying to save a char -- well, we checked with the hounds and they say a CL-style defmacro and (is nil #f) -> t don't mask the Lisp-1 scent, but they loved On Lisp and Ansi Common Lisp and ViaWeb being done in CL so pg is welcome any time.
Looks like my code when it's a three-liner and it really is a bit much to be coding (in my Algebra program):
(loop for denominator in denominators...
You are right (guessing at the implicit): "list" is a terrible name for a variable unless someone really is writing a general purpose list manipulation function, but we do see "lst" quite a bit over on c.l.lisp.
btw, the real question is whether you see "list" as a variable name in the Scheme source.
From what I've read, pg uses vi, so I expect he's developed a filetype for Arc. I was actually a heavy vim user for a couple years, but recently switched to Emacs in part because of the Lisp support. I was back to my vim productivity level in about 3 days, so maybe you could give it a shot :)
I have to be coding pretty fast and furious in CL but it has happened a few times over the years. Nice warning or error (I forget) from the compiler, tho.
Is that because Scheme doesn't allow you to use a data item as the first item in a form? Or does it have some other mechanism currently lacking in Arc to help with this problem?
The reason (tab 'foo) doesn't work in arc is that ac (in ac.scm) effectively has a special list of macros, and when it compiles (tab 'foo), it looks up tab in the special list. What is really should do in a lisp-1 is look up tab in the same list that all the other variables are in, which is the list that (let tab (table) ...) will modify. (Yes, I know I'm simplifying. No, it doesn't matter in this case, unless you can think of a reason that it does.)
Also, there's only one list like this, and it has global scope, so you can't have local macros or anonymous macros.
Ok, so if it worked that way, then (tab 'foo) would work, but you would have shadowed the tab macro, and thus lost the ability to use it, which doesn't sound like a problem if you didn't know tab was a macro to begin with.
Anyone know if this is how Arc will work, or if the current behavior is by intent?
the problem that other people have stated is that because arc's macros are unhygienic, allowing local variables to shadow macros causes some pretty serious problems.
