[HN Gopher] Show HN: A Common Lisp implementation in development...
___________________________________________________________________
Show HN: A Common Lisp implementation in development, supports ASDF
Implementation of the standard is still not complete, but
breakpoints and stepping work quite well! It also has some support
for watchpoints, that no implementation has. Now it ships with
ASDF and is capable of loading systems! Let me know if you like
it. Support on Patreon or Liberapay is much appreciated
Author : andreamonaco
Score : 68 points
Date : 2025-04-27 12:24 UTC (10 hours ago)
(HTM) web link (savannah.nongnu.org)
(TXT) w3m dump (savannah.nongnu.org)
| WalterGR wrote:
| > a debugger with stepping, a feature that most free CL
| implementations lack.
|
| I think most free CL implementations have a stepper. Which ones
| do not?
| andreamonaco wrote:
| I tried stepping in various free implementations, but I
| couldn't really follow the source forms and execute them one by
| one. Also, I couldn't find much information online. Maybe your
| experience is different?
| WalterGR wrote:
| I haven't used CL recently so I can't speak from experience.
| But it looks like:
|
| CMU CL, SBCL, and LispWorks have steppers.
|
| Clozure does not. (Edit: an answer on
| https://stackoverflow.com/questions/37754935/what-are-
| effici... suggests it does...)
|
| As I understand it, those are the big 4.
|
| Clisp, ABCL, and Allegro also appear to have steppers.
|
| Always cool to see a new implementation, though!
| klibertp wrote:
| In most of those implementations (certainly in SBCL) it's
| either you break or step; you can't start stepping from a
| breakpoint. SBCL got some support for that this year, see
| https://news.ycombinator.com/item?id=43791709. It, however,
| doesn't allow stepping into any functions called after the
| break.
|
| Also, the compilers are allowed to make the code
| unsteppable in some cases, depending on optimization
| declaration: generally, debug needs to be >=2 and >
| speed/compilation-speed/space. In some circumstances, you
| land in decompiled/macroexpanded code, which is also quite
| unhelpful.
|
| Anyway, it's not that source-level stepping isn't there at
| all, it's just quirky and somewhat inconvenient. A fresh
| implementation that does comparatively little optimization
| and is byte-code based can probably support debuggers
| better. I hope such support won't go away later when the
| native code compiler is implemented.
| eadmund wrote:
| Congratulations! Always good to see another Lisp in the world.
|
| Have you thought about writing up your experience?
| andreamonaco wrote:
| Thanks! Maybe I could do that, if I see that people are
| interested
| andreamonaco wrote:
| Also, my Patreon page (https://www.patreon.com/andreamonaco)
| has behind-the-scenes posts, some even in the free tier
| neonscribe wrote:
| Do you have a goal in mind for this project?
| andreamonaco wrote:
| Ideally I'd reach ANSI compliance, first with a bytecode
| compiler and then with a full one
| neonscribe wrote:
| Is there some important shortcoming of all the existing
| Common Lisp implementations that you would like to correct?
| kazinator wrote:
| > _To build from a git snapshot, start with
|
| > $ autoreconf -i
|
| > (which is not needed in released tarballs) and then run the
| usual_
|
| Why would you do that to yourself and your users in a new project
| this day and age.
|
| A release tarball should be nothing more than a git snapshot of a
| commit.
|
| Drop the GNU AutoCrap if you know what's good for you.
| andreamonaco wrote:
| I'm not sure I understand. What I do in my project is very
| common practice: generated files (like the configure script)
| are not part of the repository, but they are put in released
| tarballs
| sspiff wrote:
| This is true and standard for (really) old projects, and
| dealing with this scripts and their problems used to be the
| bane of my existence 10 years ago. But I can't say I've
| encountered any such projects in the last 5 or so years.
|
| Either they use a modern programming language (which
| typically has an included build system, like rust's cargo or
| simply go build) of they use simple Makefiles. For C/C++
| codebases, it seems like CMake has become the dominant build
| system.
|
| All of these are typically better than what GNU autoconf
| offers, with modern modern features and equally or better
| flexibility to deal with differences between operating
| systems, distributions, and/or optional or alternative
| libraries.
|
| I don't really see why anyone would pick autoconf for a
| modern project.
| varjag wrote:
| CMake is really more of a C++ crowd thing, it never won the
| mindshare with C.
|
| > I don't really see why anyone would pick autoconf for a
| modern project.
|
| If you build for your system only and never ever plan to
| cross compile by all means go with static makefile.
| fc417fc802 wrote:
| A few of my personal projects cross compile via static
| makefile. Is there something wrong with that?
| kazinator wrote:
| If you're not writing something which compiles its own
| tools which are then used for the rest of the build, or
| is not a compiled programming language, all you have to
| do is respect the CC, CFLAGS, LDFLAGS and LDLIBS
| variables coming from the distro. Then you will use the
| correct cross toolchain and libs.
|
| If you need to compile programs that run on the build
| machine, you should have a ./configure script which
| allows a host CC and target CC to be specified, and use
| them accordingly. Even if you deviate a bit from what
| others are doing, if it is clearly documented and
| working, the downstream package maintainer can handle it.
| kazinator wrote:
| A good way to make sure your project won't cross compile
| is to use Autoconf. Rampant use of Autoconf is the main
| reason distros gave up on cross compiling and started
| using QEMU. Developers who use Autoconf and who don't
| know what cross-compiling is will not end up with a
| cleanly cross-compiling project that downstream packagers
| don't have to patch into submission.
|
| Most of my disdain for Autoconf was formed when I worked
| at a company where I developed a embedded Linux distro
| from scratch. I cross-compiled everything. Most of the
| crap I had to fight with was Autoconf projects. I was
| having to do things like export various ac_cv_...
| internal variables that nobody should know about, and
| patching configure scripts themselves. Fast forward a few
| years and I see a QEMU everywhere for "cross" builds.
|
| The rest of my disdain comes from having worked with the
| internals of various GNU programs. To bootstrap their
| build systems from a repository checkout (not a release
| tarball) you have to follow their specific instructions.
| Of course you must have the Autotools installed. But
| there are multiple versions, and they generate different
| code. For each program you have to have the right version
| that it wants. If you have to do a git bisect, older
| commits may need an older version of the Autotools.
| Bootstrap from the configure system from scratch, the
| result of which is the privilege to now run configure
| from scratch. It's simply insane.
|
| You learn things like to touch certain files in a certain
| order to prevent a reconfigure that has about a 50%
| chance of working.
|
| Let's not even going to libtool.
|
| The main idea behind Autoconf is political. Autoconf
| based programs are deliberately intended to hinder those
| who are able to build a program on a non-GNU system and
| then want to make contributions while just staying on
| that system, not getting a whole GNU environment.
|
| What I want is something different. I want a user to be
| able to use any platform where the program works to
| obtain a checkout if exactly what is in git, and be able
| to make a patch to the configuration stuff, test it and
| send upstream without installing anything that is not
| required for just building the program for use.
| JonChesterfield wrote:
| Cmake is by a wide margin the worst build tool I've used.
| That covers at least autoconf, gmake, nmake, scons, waf,
| tup, visual studio, the boost thing, bash scripts and lua
| scripts. Even the hand edited xml insanity of visual studio
| caused negligible grief compared to cmake.
| kazinator wrote:
| I strongly concur. Cmake is incompetently designed and
| implemented. The authors had no idea how to make a build
| language, but didn't let it stop them.
| kazinator wrote:
| It's a bad practice commonly found in GNU projects, which
| results in an overcomplicated, inconvenient and unstable
| build system that will discourage future collaboration. Many
| of these projects are very old, two decades or more; they are
| living with ancient decisions made in a world of dozens of
| incompatible Unix forks.
|
| One thing to do instead is to just write a ./configure script
| which detects what you need. In other words, be compatible at
| the invocation level. Make sure this is checked into the repo
| Anyone checking out any commit runs that, and that's it.
|
| Someone who makes a tarball using git, out of a tagged
| release commit, should have a "release tarball".
|
| A recent HN submission shows a ./configure system made from
| scratch using makefiles, which parallelizes the tests. That
| could be a good starting point for a C on Linux project
| today.
| danilor wrote:
| Hey I'm curious as why you chose nongnu to host your project
| instead of github/gitlab! I don't know much about it, hence my
| curiosity ;)
| badmonster wrote:
| +1
| kazinator wrote:
| I hosted the TXR git on nongnu first, starting at around late
| 2009 or early 2010 maybe?
|
| I abandoned that when I discovered there's no control. I seem
| to recall having to wait like over a week for someone to enable
| non-fast-forward pushes. Overly strict and understaffed. I
| opted for self hosting.
|
| I kept the project web page there, though.
| andreamonaco wrote:
| I don't like sites with heavy Javascript, especially if it's
| non-free. (Though recently I started using Github for a
| different project.)
|
| Savannah is very basic, perhaps too much, but it's okay for my
| project.
| volemo wrote:
| Tbh, this is the first time I see nongnu.org used for something
| other than Emacs packages (I know that's on me), so much so
| that I even thought this was a solution to substitute Emacs
| Lisp with Common Lisp. :O
| badmonster wrote:
| Does alisp plan to eventually support full compilation to native
| code, or will it mainly stay an interpreter with limited
| compilation?
| andreamonaco wrote:
| Yeah, the goal is first bytecode compilation and then full
| valorzard wrote:
| I would be excited to use but since it's using GPLv3 I can't
| actually use it for a lot of projects I'd want to make ;-; Is it
| possible to relicense to LGPL or MPL instead?
| kstrauser wrote:
| In general, people who license something as GPLv3 probably
| consider that a feature, not a bug.
|
| I mentioned here recently that I released a personal project
| under the GPLv3. The very first issue someone filed in GitHub
| was to ask me to relicense it as something more business
| friendly. I don't think I've been so offended by an issue
| before. If I'm writing something for fun, I could not possibly
| be less interested in helping else someone monetize my work.
| They can play by Free Software rules, or they can write their
| own version for themselves and license it however they want. I
| don't owe them the freedom to make it un-Free.
|
| The fact that this is hosted on a FSF-managed service indicates
| the author likely sees it similarly.
| fc417fc802 wrote:
| I generally agree but it's worth noting that languages are a
| bit different. Obviously there are GPL'd compilers but those
| often make an explicit carveout for things like the runtime
| and standard library. Meanwhile in the Lisp world my
| impression is that most (but certainly not all)
| implementations are permissively licensed in part due to
| concerns that shipping an image file is essentially shipping
| the entire language implementation verbatim.
| kstrauser wrote:
| That totally makes sense and I do appreciate why that would
| be a problem for some users.
|
| And yet, this is a single-user labor of love by one person
| hosting it on FSF's servers. I don't know them, and this is
| pure conjecture, but I suspect they probably couldn't care
| less if that made it challenging for commercial users.
| There are plenty of other Lisps for them to choose from.
| -__---____-ZXyw wrote:
| Hard to believe this comment could be serious, but nonetheless,
| for the impartial observers, there is a healthy ecosystem of
| Common Lisp implementations, from "permissive" open source all
| the way to (expensive) commercial, proprietary ones.
|
| https://common-lisp.net/implementations
|
| I think a full-featured GPLv3 implementation would be very
| cool, personally.
| whartung wrote:
| At what point does a CL implementation need to be before it can
| start hoovering up the available library code from other
| implementations (license permitting).
|
| How many LOOP macros does the community need, particularly when
| bootstrapping an implementation, as an example.
|
| Similarly with, arguably 70-80% of the runtime. The CL spec is
| dominated by the large library which, ideally, should be mostly
| portable CL, at least I would think.
| klibertp wrote:
| You're not the first one to think so:
| https://github.com/robert-strandh/SICL
|
| I'm unsure how complete it is, but it seems to cover much of
| the standard.
| v9v wrote:
| Here's a recently-written summary of the different libraries
| in SICL (including each library's purpose and status)
| http://metamodular.com/SICL-related-libraries/sicl-
| related-l...
| CleverLikeAnOx wrote:
| What is ASDF?
___________________________________________________________________
(page generated 2025-04-27 23:00 UTC)