[0] https://github.com/malisper/Clamp

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 one primary thing I care about in the beginning: what are the precise concrete 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.

[1] http://www.arclanguage.org/item?id=18895

  $ 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 didn't think this was a problem since https://common-lisp.net/project/asdf/#downloads suggested just using the version that comes with my CL. Should I upgrade my sbcl as well?

Everytime I consider installing asdf manually I'm stymied by that last link. It provides an asdf.lisp but doesn't say what to do with it. Do I just load it? I just tried that without luck. I also tried various incantations from these tabs I have open: https://www.common-lisp.net/project/asdf-install/tutorial/in...; https://www.common-lisp.net/project/asdf-install/tutorial/se....

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.)

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.

> https://common-lisp.net/project/asdf/#downloads suggested just using the version that comes with my CL. Should I upgrade my sbcl as well?

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

Those are for asdf-install which IS NOT asdf: http://www.cliki.net/asdf-install

asdf-install was the previous version of Quicklisp, but you should now be using Quicklisp instead.

> Those are for asdf-install which IS NOT asdf: http://www.cliki.net/asdf-install

  $ sudo apt-get install sbcl
  $ wget https://beta.quicklisp.org/quicklisp.lisp  # following instructions at https://quicklisp.org
  $ sbcl --load quicklisp.lisp
  * (quicklisp-quickstart:install)
  * (ql:add-to-init-file)
  * (quit)
  $ cd quicklisp/local-projects
  $ git clone https://github.com/malisper/Clamp

  $ sbcl
  * (ql:quickload :clamp)
  * (in-package :clamp)
  * (use-syntax :clamp)

  * (map [+ _ 1] '(1 2 3))
  (2 3 4)

  $ cat quicklisp/local-projects/Clamp/init.lisp
  (ql:quickload :clamp)
  (in-package :clamp)
  (use-syntax :clamp)
  $ sbcl --load quicklisp/local-projects/Clamp/init.lisp
  ; Loading "clamp"
  * (map [+ _ 1] '(1 2 3))
  The variable [+ is unbound.

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.

[0] http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil...

  Cannot restart frame: #<SB-DI::COMPILED-FRAME EVAL>

  $ clamp

  $ emacs
  M-x slime RET
  # in the slime buffer
  * (ql:quickload :clamp)
  * (in-package :clamp)
  * (use-syntax :clamp)

Yes, that's what I typically do. If you wanted to, you could add those instructions to your .sbclrc, and that should load Clamp on start up.

> 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.

You need to have slime-mode enable in the buffer you are editing. You can add the following code to your .emacs:

    (require 'slime)
    (add-hook 'lisp-mode-hook (lambda () (slime-mode t)))

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...).

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'?

Run your lisp wherever you want and then:

  (asdf:load-system :clamp)
  (defpackage #:mypkg (:use clamp))
  (in-package #:mypkg)

> Telling people how to get up and running

  $ 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]
  *

  (arc :l "myprogram.arc")
  (arc :e (f:g 3.14))

  $ git clone https://github.com/akkartik/wart
  $ cd wart
  $ git checkout sbcl
  $ ./wart
  wart> car.nil
  nil

1. Arc is slow. 2. Arc doesn't have threads. 3. You can't make an executable out of Arc. 4. If you're dealing with extending the low layers of Arc, you need to use Racket.

We don't need to switch to CL to solve #1 and #2 -- you can make Racket-Arc faster and add threads there. I'm not sure if switching is required for #3, but #4 is definitely only solved by switching languages.

I think I prioritize popularity more than other people; perhaps because I want libraries, and other people can write more libraries than I can. For example, see my long-coming rewrite of unit-test.arc, which is going to be out any season now.

I also have a possibly unwarranted hope that there will be a new official version of arc, or pg/rtm/kogir/sctb will hang out here more.

For understanding why, let's discuss one aspect of software. There is something cool about software that actually many organisation miss I think. Software is pretty predictable. Just use your stats. So, if your development team was going at that velocity this month on that system, chances are they are going to move forward with the same velocity or so the next month. If you've had 15 new bugs this week on your system, chances are you gonna have at least 10 new bugs next week. If you had important successes with your system, chances are you gonna continue to be successful with your system again.

In other words, if your team is slow this month, they won't be fast next month. Nah, they wont. If you had bugs last week but think you've made big fixes, well you gonna be disappointed this week when you will understand that you've not fixed the mother of all bugs because there is no such thing. Your codebase has that property, it has that bug stats. It can go down, but using a continuous and low varying function.

If you adopt Arc and got 5 technical problems in 2 weeks all more or less related to Racket [0], chances are, that's my point, that you gonna have technical problems all along. So what I'm trying to do here by my call is not to fix a couple of issues. What I'm trying to do is to change the stats themselves. Arc must be smooth. If it's not smooth, hackers wont use it. Right now, Arc is unusable because, as you use it, you understand that statistically, Racket gonna pose problems. So you quit.

Note that I'm not advocating fragmentation. I'm advocating to, if reviews and discussions tell it's right, deprecate the Racket version for a CL one.

I've very quickly tried the Clamp implementation yesterday, and already, I've felt the difference. The ffi, check. As fast as C, check. Threads, check. Not repl problem in sublime, check. Easy import from CL, check. Executable, check (I've made one with clamp, it just worked). (Chances are, Im gonna continue to check at this rate.)

I think that makes my point more clear. Before any consideration, we must have a real good implementation hackers would use, as a foundation on which to build on. I can be wrong though. I may be making a judgement mistake of course.

> Right now, Arc is unusable because, as you use it, you understand that statistically, Racket gonna pose problems. So you quit.

I've had the complete opposite experience -- none of my problems with Arc are Racket-related. The things you have listed seem to fall into two categories: you prefer Common Lisp, or things that have been done in Clamp.