I implemented most of Arc in Common Lisp[0]. It supports destructuring in def/mac, ssyntax through symbol-macrolet/macrolet[1], and the bracket lambda syntax through reader macros. IIRC the only real Arc feature it doesn't have is ccc (call-with-current-continuation) which is kind of supplied through the cl-cont library.
malisper, I've told you before about my troubles building Clamp[1], and I haven't learned anything new in the interim. Everytime I try to do anything with asdf I just feel stupid. Including a reference to http://common-lisp.net/project/asdf/asdf/Quick-start-summary... in your Readme[2] is not nearly enough. Could you describe, just for your own system:
a) what version of asdf (and sbcl and OS and processor...) you have tried and seen it working on,
b) which directory you put Clamp in when you clone it,
c) which directory you run sbcl from, and
d) what commands you use to load clamp after starting sbcl?
It would only take a few sentences/minutes, and it'll help immeasurably to get people unfamiliar with Common Lisp started with Clamp. Telling people how to get up and running (without needing to understand the dependencies you rely on) is the bare minimum prerequisite necessary to contemplate replacing Arc-on-Racket with Clamp-on-Common-Lisp.
It seems not a month passes without some new project I would find most interesting to try out, except it doesn't have a Readme, or it has a Readme with tons of prose except for the oneprimary thing I care about in the beginning: what are the preciseconcrete commands that have been known to have it do something, at least on some one computer? It's a super easy way to stand out among the crowd, and it only takes a few sentences compared to the thousands of lines of code you've already written.
You should only need Clamp to be in ~/common-lisp, and asdf >3.1.2. With that everything else should take care of itself. I think, but I'm not sure, that you can install the latest version of asdf through Quicklisp.
If you want the particular details, I am running sbcl 1.2.11 on Ubuntu 14.04 with Clamp in ~/common-lisp and asdf version 3.1.3. To load Clamp, after using 'M-x Slime' in Emacs to start Slime, I type '(require :clamp)' or '(require :clamp-experimental)' to load it.
Still no luck, sorry. I'm on Ubuntu 14.04 as well, and I'm running sbcl 1.1.14.debian. I did the following:
$ sudo apt-get install emacs
$ emacs --version
GNU Emacs 24.3.1
$ cat .emacs
; from http://melpa.org/#/getting-started
(require 'package) ;; You might already have this line
(add-to-list 'package-archives
'("melpa" . "https://melpa.org/packages/"))
(when (< emacs-major-version 24)
;; For important compatibility libraries like cl-lib
(add-to-list 'package-archives '("gnu" . "http://elpa.gnu.org/packages/")))
(package-initialize) ;; You might already have this line
; from https://www.common-lisp.net/project/slime/doc/html/Installation.html
(setq inferior-lisp-program "/usr/bin/sbcl")
$ pwd
/home/akkartik
$ ls common-lisp
Clamp/
$ emacs
M-x package-install RET slime RET
# some errors
M-x slime
# seemed to work
* (require :clamp)
Don't know how to REQUIRE CLAMP.
[Condition of type SB-INT:EXTENSION-FAILURE]
I think I might be missing some step in between that you implicitly have..
Interesting! This is precisely what you need to record in the Readme!! "You need asdf 3.1 or higher." I assume you mean 3.1, right? According to http://www.cliki.net/ASDF the current version is 3.1. Is that really such a big difference?
Common Lisp's crap documentation is culturally recursively turtles all the way down, just like all the good things about it.. :/ This is why I'm rooting for you to break out of this cycle of suck and improve things. Would you consider starting with a pristine Ubuntu 14.04 without sbcl or anything on it, and saving all the commands you type in until you get to a working Clamp? That would be wonderful to include in the Readme.
Another option might be to eschew asdf since the default versions on the most common Ubuntu release interact so poorly. Just dump all notion of dependencies and directly include all the code you need in the appropriate relative paths. Give me a single "sbcl --load" command to rule them all, just like Arc 3.1's classic "racket -f as.scm".
(It's not just Common Lisp, by the way. I have yet to meet a language-specific package manager that didn't suck. Pip, RubyGems, CPAN, it's all utter garbage. NPM hasn't started to suck yet, but I'm constantly looking for signs of incipient over-complexification.)
Edit: I'd be happy to provide a temporary Ubuntu server on Linode or something for this work.
No. It's just that asdf >=3.1.2 will check the ~/common-lisp directory by default. Prior to 3.1.2, you had to manually specify the directories you wanted asdf to check.
It looks like the version of sbcl you are using is old enough that the asdf version it comes with is older than 3.1.2. From that link, there is https://common-lisp.net/project/asdf/asdf.lisp Copy paste that into a file and add `(load "/foo/bar/asdf.lisp")` to your .sbclrc. I believe that Quicklisp comes with a more recent version of asdf, so you can also try setting that up and seeing if that configures asdf properly.
> I also tried various incantations from these tabs I have open
asdf-install was the previous version of Quicklisp, but you should now be using Quicklisp instead.
I should spend the time to make Clamp a Quicklisp package so that you would be able to install it with just `(ql:quickload :clamp)` instead of needing to deal with asdf.
Woohoo! I'll send you a pull request. Is there some way we can provide an "Arc repl" that's already in the right package and uses the right syntax? I tried this, but it didn't work:
Reader macros work on a per file basis so I don't think there is a way to set the proper syntax from a separate file.
You might want to consider trying to setup Slime, as it provides some really amazing Smalltalk-esque features. I detailed most of them in my blog series, Debugging Lisp[0]. Some of the ones I covered in the post are: recompilation of code at runtime, restarting of a stack frame at runtime, an object inspector, interactive restarts (restarts are a better form of try/catch), various forms of function lookup (e.g. list all functions who call function X). I haven't yet covered it, but I eventually want to, is slime-macrostep[1]. It lets you interactively expand parts of a macro step by step.
I've gotten Slime working, but so far I'm still doing the same things I would do in an interactive session:
$ emacs
M-x slime RET
# in the slime buffer
* (ql:quickload :clamp)
* (in-package :clamp)
* (use-syntax :clamp)
Is that what do you typically do?
Also, when I try to C-x C-e an arc expression in some random buffer after the above steps, it doesn't seem to remember the above commands anymore. The only thing that works is running commands at the repl.
and then whenever you open a file that ends in .lisp, it will enable slime-mode.
If you are going to get into programming Lisp with Emacs, you should look into Evil (vim bindings for Emacs), paredit (smart paren editing), ac-slime (autocomplete for slime), show-paren-mode (shows matching parens), and undo-tree (a better version of undo/redo). Although I've never used it, you might want to look at Spacemacs which is supposed to supply sane defaults for Emacs.
>If you are going to get into programming Lisp with Emacs, you should look into Evil (vim bindings for Emacs), paredit (smart paren editing), ac-slime (autocomplete for slime), show-paren-mode (shows matching parens), and undo-tree (a better version of undo/redo).
Yes, customizing Emacs is really useful for making it better to use. To help with that, here are some of my config's settings for things you've mentioned. My show-paren-mode settings are here (https://bitbucket.org/zck/.emacs.d/src/default/init.el?filev...).
Instead of paredit, I use smartparens. They do similar things, but when I looked at the two, I thought smartparens was better, although I can't remember why right now. My config is here (https://bitbucket.org/zck/.emacs.d/src/default/init.el?filev...).
I should similarly check out the other things you've mentioned (except Evil, 'cause I don't like modal editing).
> replacing Arc-on-Racket with Clamp-on-Common-Lisp
We need a compiler for that btw (ie. the arc macro Im talking about nearby?) because 1) language designers need a compiler and 2) right now, it is missing parts of Arc; specifically:
('(1 2 3) 0)
(mylist 0)
("Yoopi" 0)
(+ "Hello" " World")
top level ssyntax
What case are missing for destructuring?
What am I forgetting? Do we have 'for'?
Doesn't work with sbcl, I'll try it with ccl later today:
$ uname -a
Linux akkartik 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 i686 i686 GNU/Linux
$ pwd
/home/akkartik
$ sbcl --version
SBCL 1.1.14.debian
$ ls quicklisp/local-projects
Clamp/ system-index.txt
$ rlwrap sbcl
This is SBCL 1.1.14.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (require :asdf)
("ASDF")
* (asdf:load-system :clamp)
debugger invoked on a ASDF/FIND-SYSTEM:MISSING-COMPONENT in thread
#<THREAD "main thread" RUNNING {ABFC8D1}>:
Component :CLAMP not found
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
((:METHOD ASDF/OPERATE:OPERATE (SYMBOL T)) ASDF/LISP-ACTION:LOAD-OP :CLAMP) [fast-method]
0]
*
Oh, are you using it with Quicklisp? I also tried installing quicklisp as well, but it didn't change the error.
I think we should evaluate if the Arc community want to switch to clamp as a main implementation (it's ok, we can take our time..). I gonna use it this week end to see if I find any problem.
Just made a quick test on my pet project using :clamp (not clamp experimental) and since most CL is exported, it's pretty compatible and works without much effort. So far so good. I'm gonna test the experimental part this week end.
I did find a better way to export everything. By using defpackage-plus, you can define a package definition clause that imports and exports every symbol that doesn't have a naming conflict with the current package. Exporting all of the symbols in :cl becomes just using this clause on :cl.
That's only ssyntax. a.b is rewritten as (get a b) where get is a generic function. You may be able to use set-funcallable-instance-function to get something closer to what arc supplies. Also there are a lot of edge cases with the ssyntax since you have to be within a w/ssyntax block. There is one included in def, so you can use ssyntax in function definitions, but you can't use it at the toplevel.
I wouldn't spend too much time on it. malisper truly has the right idiomatic approach with packages. I was mostly just flailing around with the little bit of Common Lisp I understand.
I've not dive into it but I actually like a lot the idea of Arc being implemented as macros into CL. Ill take some time to review this implementation I think (at least for myself :P).
I recommend the community to audit this implementation and to switch to it as a primary impl if it's any decent. Every link should be redirected to it. I can say quite confidently that CL is the best lisp out there today and the way to go forward as the other lisp dialects both sux and are stucked (even clojure; I've made a 5K+ LOC program with clojure and got tons of technical problems as the codebase got bigger).