Arc Forumnew | comments | leaders | submitlogin
Tell Arc community: we need an implementation of Arc in Common Lisp
4 points by highCs 479 days ago | 56 comments
Hi,

I've tried Common Lisp recently and it's the messiah really. It's way better than Scheme/Racket in my opinion.

Common Lisp is super fast (I think ccl may be faster than Racket, according to my humble tests), it has un-hygienic macros, it has real threads (at least in ccl if Im correct), the syntax is cleaner, you can easily make executables, etc. Common Lisp is great, it's hackable, it's perfect.

The only language that beat it in my opinion is Arc. But vanilla Arc on Racket sux: it's slow, it has no real threads, no executables, whenever you fall into Racket to add something, you have to deal with racket which is 'meh'. A C implementation of Arc can't be good unless guys that are serious about compilers work on it which wont happen.

Common Lisp is awesome. It's like Arc but slightly less good for the syntax and sugar. Maybe Scheme was awesome at some point in time but it's not the case anymore.

I really think Arc should be on Common Lisp. I think this is Arc only chance actually. Arc needs a great compiler, simple access to plenty of libraries and, if not implemented in C, a VM implemented in a truly great language.

Common Lisp is the best language out there right now in my opinion. It would definitely fit.



4 points by malisper 478 days ago | link

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.

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

[1] http://letoverlambda.com/index.cl/guest/chap5.html#sec_4

-----

4 points by akkartik 475 days ago | link

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

[2] http://www.arclanguage.org/item?id=18894

-----

3 points by malisper 474 days ago | link

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.

-----

1 point by akkartik 474 days ago | link

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

-----

3 points by malisper 474 days ago | link

What asdf version are you running?

-----

1 point by akkartik 473 days ago | link

Ah yes, I meant to ask: how would I answer that?

-----

3 points by malisper 473 days ago | link

(asdf:asdf-version)

-----

2 points by akkartik 473 days ago | link

3.0.3

-----

3 points by malisper 473 days ago | link

That's why you have been having issues. All you need to do is download a more recent version and load it in your .sbclrc file.

-----

4 points by akkartik 473 days ago | link

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?

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

Edit: I'd be happy to provide a temporary Ubuntu server on Linode or something for this work.

-----

3 points by malisper 473 days ago | link

> Is that really such a big difference?

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.

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.

-----

1 point by akkartik 472 days ago | link

That would be great, thanks.

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

O_O

-----

1 point by akkartik 472 days ago | link

Ah, I FINALLY managed to get Clamp loaded. Here are the steps I followed from my home directory on Ubuntu 14.04:

  $ 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
Now, from any directory:

  $ sbcl
  * (ql:quickload :clamp)
  * (in-package :clamp)
  * (use-syntax :clamp)
Now it's ready!

  * (map [+ _ 1] '(1 2 3))
  (2 3 4)
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:

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

-----

3 points by malisper 472 days ago | link

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.

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

[1] http://kvardek-du.kerno.org/2016/02/slime-macrostep.html

-----

1 point by akkartik 469 days ago | link

I'm trying to work through http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil... but I got this error when I tried to restart from any of the stack frames:

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

-----

1 point by akkartik 471 days ago | link

Ah, I figured out a way to run it with just:

  $ clamp
https://github.com/malisper/Clamp/pull/5

-----

1 point by akkartik 472 days ago | link

Yes, I'll certainly try to add Slime back now that I have the foundation working well together.

-----

1 point by akkartik 469 days ago | link

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.

-----

4 points by malisper 469 days ago | link

> I've gotten Slime working, but so far I'm still doing the same things I would do in an interactive session:

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

-----

3 points by zck 469 days ago | link

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

-----

1 point by akkartik 469 days ago | link

Ah, that hook was what I needed. Thanks! I'll check out all your tips.

-----

1 point by akkartik 472 days ago | link

Draft changes to Readme: https://github.com/malisper/Clamp/pull/3/commits/d4e89140b9

Everyone please try out the instructions and/or suggest improvements to the prose.

-----

2 points by highCs 475 days ago | link

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

-----

2 points by highCs 475 days ago | link

Put clamp inside quicklisp/local-projects/

Run your lisp wherever you want and then:

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

> Telling people how to get up and running

Second that. Some intructions in the README to get clamp up and running on linux would be a must. OSX and windows would be nice to have too.

-----

3 points by akkartik 475 days ago | link

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.

-----

2 points by highCs 475 days ago | link

I didnt installed clamp using quicklisp which wasnt able to find it. I put clamp myself in the local-projects folder.

I think ccl has an asdf thing and must be at the origin of the quicklisp folder look up. I hoped it was standard.

-----

1 point by akkartik 475 days ago | link

But you have quicklisp installed with ccl? That's why CCL looks in quicklisp/local-projects?

-----

1 point by akkartik 475 days ago | link

Hey, is CCL not open-source?

-----

2 points by highCs 475 days ago | link

It's even free buddy: http://ccl.clozure.com/

-----

1 point by akkartik 475 days ago | link

Ah, I got confused because the svn repo came with a prebuilt binary. But it has the sources too.

-----

3 points by highCs 478 days ago | link

Clamp seems perfect. It's beautiful. It's clean. It's amazing.

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.

-----

4 points by akkartik 478 days ago | link

Looking forward to seeing you take the lead on this!

-----

3 points by highCs 478 days ago | link

Okay :)

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.

-----

4 points by malisper 477 days ago | link

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.

-----

3 points by highCs 477 days ago | link

Nice. You made ('(1 2 3) 0) working? Or its only working when using ssyntax (ie array.0)?

-----

4 points by malisper 476 days ago | link

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.

-----

2 points by highCs 476 days ago | link

An idea would be to have an arc macro that compile arc code.

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

-----

2 points by akkartik 476 days ago | link

Interesting. I think Wart supported ssyntax at the toplevel.

-----

2 points by akkartik 475 days ago | link

Yup:

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

-----

1 point by highCs 475 days ago | link

Gonna have to take a closer look at wart.

-----

2 points by akkartik 475 days ago | link

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.

-----

3 points by highCs 478 days ago | link

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

EDIT: clamp looks awesome.

-----

1 point by highCs 478 days ago | link

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

-----

1 point by akkartik 478 days ago | link

Ah, yes I knew I was missing something more recent: http://www.arclanguage.org/item?id=18889

-----

4 points by zck 478 days ago | link

More Arc implementations would be cool, but I don't know if that's the thing preventing Arc from gaining popularity.

Of course, in that sentence I assume "gaining popularity" is the goal. I do think it's a very worthwhile goal, but it might not be yours. And that's fine.

-----

3 points by highCs 478 days ago | link

It's not about popularity. It's about that I, as a good programmer, doesnt use Arc because it sux for a couple of reasons, which defeat the purpose of the language. In my opinion, switching to CL would fix those issues and open up a bright future.

-----

3 points by zck 477 days ago | link

That's fair. Reading your post, it seems like you have four points:

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.

I guess my point is that switching to CL fixes some problems; some don't need a switch. And I worry about fragmentation.

-----

4 points by akkartik 477 days ago | link

Just as a counter-point, I'm utterly unconcerned about fragmentation. This community is small, and the Arc codebase is small, in the grand scheme of things. It's tractable for one person to hold it in his/her head. We all have different strengths and weaknesses. If somebody finds it easier to work with C++ (that's me), go do it. If Common Lisp is your forte, and you find it easier to port Arc to it than to build threads into Racket-Arc, go for it. Regardless of where you are, it's tractable (though not trivial; write lots of tests!) to share code across projects.

One lament that often comes up with programmers is why software can't be as stable as a house or a bridge or whatever. Well, the reason is that our forebears tried lots of different houses and bridges before we settled on the ones we see today. That was only able to happen because of large amounts of fragmentation, only we don't call it fragmentation because atoms are harder to copy than bits, we just call it "trying again". Since bits are easy to copy, software culture has internalized some amount of "peer-pressure copying" under the banner of "avoiding fragmentation". I think it's silly. Particularly in the context of a small-scale project where there's never going to be much demand for deploying at scale, we'll never be a massive target for black-hat folks (so quickly transmitting security fixes isn't a priority), etc. Even for a large-scale project like Android, I think the problems people attribute to "fragmentation" are symptoms of deeper issues, and not fragmenting just keeps us from better understanding the issues.

-----

3 points by zck 477 days ago | link

That's fair. I definitely have a bias away from creating architecture, which probably explains more of my reactions than I'm comfortable with. I normally prefer to make things work within an existing system.

But yeah, I do see that it's worthwhile to try random things; it just doesn't feel true to me. For some reason, waterfall design is what makes me more comfortable.

-----

3 points by highCs 477 days ago | link

I see what you mean. I entirely agree with you. Basically, I would not want too to advocate for a switch if it was for minor reasons (even for most medium ones) that can be fixed or with which one can live. That happens a lot with software, you have to live with some shit and that's ok. I think my point goes beyond however.

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.

[0] I've also had problems importing my symbols coming from a ffi to arc. Such a pain. It's already working with clamp though...

-----

4 points by akkartik 477 days ago | link

The only caveat I want to inject is to not blame Racket too strongly. Clamp showed me that I don't know enough CL to make a good Arc in it. By the same token, Pauan's https://github.com/arclanguage/arc-nu showed me how much better Arc-on-Racket can be. Racket is pretty mature, but the default Arc implementation hasn't moved much from the days of mzscheme.

-----

1 point by highCs 477 days ago | link

Sure, obviously Racket is a great language, specially for teaching. Though, I don't find it is in the same greatness category as C and python (and some others like Ruby, Rust and Go). Those are the hacker languages. I would like to see a lisp actually in this category.

-----

3 points by zck 476 days ago | link

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

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

I think I'd be happier about switching implementations if we could update the site that most people using the language use to communicate on! The instructions still say to get a specific old version of mzscheme!

-----

2 points by akkartik 476 days ago | link

Extremely valid point.

-----

3 points by akkartik 478 days ago | link

My Arc-inspired language started out in Common Lisp: https://github.com/akkartik/wart/tree/sbcl

Here's another project, albeit defunct: http://arclanguage.org/item?id=5396

-----

2 points by highCs 478 days ago | link

Wart looks interesting. I would need to know how much it differs from Arc and why. Ill read the unit tests maybe.

-----