
Quilc: An optimizing quantum compiler written in Common Lisp - reikonomusha
https://github.com/rigetti/quilc
======
IronBacon
Looks like they also made public their quantum virtual machine a month ago, as
I was wondering how to play with a compiler without the HW to run a program...
^__^;

~~~
Y_Y
Maybe you could shoehorn it into running on IBM's Q platform. They let you run
circuits in real hardware and give you back the statistics on the
measurements.

[https://medium.com/qiskit/how-to-turn-on-your-quantum-
comput...](https://medium.com/qiskit/how-to-turn-on-your-quantum-computer-
fba0a4152d92)

~~~
dangirsh
Or Rigetti QCS, which already uses quilc:
[https://rigetti.com/qcs](https://rigetti.com/qcs)

~~~
4thaccount
I think there is a computerphile video on YouTube covering Rigetti and Lisp.

------
mruts
It’s interesting that they chose to use Common Lisp for their entire quantum
stack. Maybe it hit the sweet spot between expressiveness and performance?
Choosing a Lisp makes sense, but I’m not sure I would choose CL. The macro
system is primitive and the whole language stinks of a compromised design.
Also, at this point, the language feels old and somewhat archaic.

If performance isn’t a dealbreaker, Racket would be sensible choice. Though
personally, I think OCaml would be great for this sort of project. Native
code, syntax extensions with ppx, a bulletproof type system, and a highly
optimized compiler that produces blazing fast code.

~~~
4thaccount
I think a lot of the choices that went into common lisp were done for
practicality's sake although there is some archaic elements due to design by
committee and trying to put something together to unite the many different
lisp implementations at the time.

There's a lot to like about Racket, but Common Lisp is really fast, practical,
and is portable to many different implementations like SBCL, AllegroCL,
LispWorks...etc that are similar, but have different characteristics (one
compiles faster, one has better performance, the commercial ones have GUI
libraries...etc).

Given a choice, I would personally choose Common Lisp over Racket pretty much
any day (not that Racket isn't nice btw). Performance is one reason, but the
Chez Scheme migration should help out Racket a bit.

OCaml is neat too, but not really directly comparable to Common Lisp. Both are
solid languages, but I wouldn't put them in the same category. If I was
writing a compiler I would choose OCaml...crazy macros and code generation
everywhere...lisp :)

I'd like to see someone who really uses Common Lisp regularly like LispM
comment though.

~~~
lispm
> archaic elements due to design by committee

The 'archaic' elements are due to backwarts compatibility with Lisp. You get
that raw core of Lisp from the 60s: s-expressions, cons cells, LAMBDA, LIST,
CONS, CAR, CDR, APPEND, COND, EVAL, PRINT, PROG, READ, macros, dynamic
binding, ... all these (and more) are still in Common Lisp.

Common Lisp is an improved Lisp dialect, not a fully new language. A goal was
to relatively easily port some existing software which was written in the
years from 1958-1984 to Common Lisp. CL appeared in a documented form in 1984
with CLtL. Thus some code that ran in Common Lisp was a port of code written
starting in the 60s, like Macsyma. People did not want to throw away hundred
thousands lines of code and they wanted to use the newer language, because it
was available, slightly better than the old one and was supported on more
machine types.

This language was mostly developed by five people: Scott Fahlman, Guy Steele,
David Moon, Daniel Weinreb, and Richard P. Gabriel.

> and trying to put something together to unite the many different lisp
> implementations at the time

Common Lisp is specifically a successor to Maclisp, mostly based on Lisp
Machine Lisp (another Maclisp successor), by simplifying/generalizing LML.
It's even not directly compatible with LML. It's much less compatible with
other Lisp dialects of the time: Interlisp, Scheme, IBM's Lisp, Standard Lisp,
or even Scheme or Logo.

After the initial design of Common Lisp was done, an effort was started to
standardize the language: improve it and add a bunch of important features
like error handling and object-oriented programming.

Error handling was then based on the Symbolics 'New Error System' and the
object-system CLOS was a new design based on Flavors and LOOPs - two earlier
Lisp extensions.

The most committee like design was actually CLOS. But even that was driven by
only six people, lots of community support and a portable reference
implementation (PCL).

Arguably, CLOS is one of the greater designs in the Lisp language space.

The third part then are implementation extensions, which got especially
important, when the standards effort went out of steam/funding/interest...:
concurrency, unicode support, foreign-function interfaces, standard libs, ...

The design advantage Common Lisp has over Scheme is that it started as a
larger integrated language. This makes features know of each other and the
language is designed to use and support them.

Scheme has often this feeling of a very small core language, even a too small
core language, and a lot of stuff bolted on top. The result is that
'practical' implementations (practical here means implementations which are
used to write software and not so much as a teaching language/implementations)
often reach the size of Common Lisp and one of its implementations AND all of
them are diverging in some basic ways (Chez, Chicken, Racket, Guile, ...).

Take for example the object system. Since CLOS was added to Common Lisp no one
bothered to propose a replacement for it in Common Lisp. Thus every
implementation, small and large, is using it.

> but the Chez Scheme migration should help out Racket a bit

If I would want to use Scheme, I'd use Chez Scheme directly. It's a great
implementation of Scheme. In provides what many Common Lisp systems (incl.
SBCL) also offer: an optimizing native code AOT compiler. Chez already has
what Racket now gets: an improved implementation mostly written in itself.

~~~
4thaccount
As always, thanks for the well written and thoughtful reply.

>If I would want to use Scheme, I'd use Chez Scheme directly

I came to the same conclusion based off of a fast interpreter, AOT compiler,
ability to make executables...etc. I know I've looked at the CISCO GitHub page
for it before.

~~~
mruts
Gambit Scheme is also good (and fast). It’s used as the base of lambdanative,
a cross platform scheme framework mostly targeted at native mobile

[http://www.lambdanative.org](http://www.lambdanative.org)

~~~
lispm
Just use Embedded Common Lisp. Comes with a full Common Lisp incl. CLOS
implementation, compiles to C, uses the usual free IDE SLIME/GNU Emacs.
[https://common-lisp.net/project/ecl/main.html](https://common-
lisp.net/project/ecl/main.html)

~~~
4thaccount
How good is the quality?

