Kens is rather dishonnest there. There have been improvements in Arc's performances (including a few experimental ones with the 'compile keyword I added a few times ago) and accessing libraries is rather easy through mzscheme or the experimental FFI (it has to be improved, sure, but it's not that hard if someone wants to). The curently-developed arc2c should solve a good part of these problems, too.
Besides, Arc is too young to have lots of libraries programed in itself, but they're coming. What if, in 1991 (the year Python was released) someone said "Python is bad for exploratory programing : it does not have libraries" ?
You're right: Arc is just too young to have a huge (or even a medium sized) collection of libraries, because it takes a lot of time to write libraries to fetch web pages (BTW, look at http-get on Anarki), manipulate images and so on. We should talk about Arc in terms of what it will be able to become, not in terms of what it is today. In this view, the only real problem is the lack of a module system to support the construction of libraries.
He makes an important distinction in two kinds of exploratory programming, and just sort of is unlucky that he needs the second kind (whereas I'm happy, as I need the first kind)
I think there are two different kinds of exploratory
programming. The first I'll call the "Lisp model", where
you are building a system from scratch, without external
dependencies. The second, which I believe is much more
common, is the "Perl/Python model", where you are
interacting with existing systems and building on previous
work.
> accessing libraries is rather easy through mzscheme or the experimental FFI (it has to be improved, sure, but it's not that hard if someone wants to)
Actually, you could probably do that (if you really want to) by overriding the 'annotate function and using a 'locked* list, so that you can only annotate an object with a type name that is not already in the locked* list :
(redef annotate (type obj)
(if (mem type locked*)
(err "This type is locked")
(old type obj)))
Here, 'old is a "keyword" of 'redef that calls the old version of 'annotate (the unprotected one, that cannot be accessed from outside anymore).
And how do you unlock it for the constructors that are supposed to do the proper locking?
Hmm.
(let real-annotate annotate
(def theorem (f)
(if (check-f-is-valid-theorem f)
(real-annotate 'theorem f)
(err "Not a valid theorem")))
(= annotate
(fn (type obj)
(if (is type 'theorem)
(err "Spank! Spank! Under the boots of your master!!")
(real-annotate tpye obj)))))
It does have the drawback that you can't, say, reload the file, but hey, you did say you didn't want anyone else to create theorems except by that method, so even redefining that method won't work!
That's a good idea, and I think that will eventually be how it will work. But I think it's too early for that : obviously, he wants to completely design & implement the core functions (alone) before working (and let other work) on libraries.
Maybe you should send him an e-mail and ask him explicitly. He doesn't seem to come here these days anyway... I hope that's not because he's horrified by what we did to his baby :)
I'd rather see some ssyntax here, e.g. expanding 1..5 to (range 1 5). Well, that's a matter of taste, but I don't really like the (1 5) approach, and the ssyntax version looks more usual and more explicit (it looks like what you find in others languages).
Anyway, for your solution, you have to hack ar-apply or ar-funcall if I remember well. That's where ac.scm is dispatching between real functions and collection accesses.
Anyway, on Anarki 'defcall should do it :
(defcall int (a b) (range a b))
(1 5)
==> (1 2 3 4 5)
As an aside, this appears to be popular, it might be possible to add this to the ssyntax extension.
As an aside, I suspect that much of the slowdown from the new ssyntax/ssexpand comes from scheme-side 'ac emitting a lot of 'ar-eval calls, but I'm not sure, since I haven't studied 'ac output much yet.
I will do so soon, and hopefully when I get a chance to study ssyntax.arc a little more, I will add a-ssyntax-bottom.
What might be nice would be to have numerical precedence levels (reals, not integers), so that you could add an operator later with the right precedence without redefining everything.
yep, that's it. I never used the ssyntax-definer, so I forgot it was existing. Sorry, but it's a little late here, so I can hardly even understand myself :)
defcall is pretty simple to use. The syntax is the same as that of def, except instead of a function name, you provide the type of the object. The function receives both the objects and its "arguments". E.g.
arc> (defcall sym (self n)
(repeat n (prn self))
#<procedure>
arc> ('a 3)
a
a
a
nil
.
Well, I find it ugly and hard to type (that's about 20 characters, instead of about 10), but that's a question of point of view, and at least you can do that.
There was also an experimental version of infix notation for numerical operations on Anarki a few time ago. You could do :
(a + b + c)
However, the implementation was very slow, so I think it is not used by many of us those days.
> However, the implementation was very slow, so I think it is not used by many of us those days.
I'd like to find a way to improve the speed of the current infix implementation, but I'm not sure it can be done without using macros, which would require some sort of type inferencing or static type declarations.
