You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ReadLine Wrapper (rlwrap) utility is actually a must have when you want to run SBCL
from the command line,
because by default, SBCL in the terminal:
doesn't offer symbol completion
doesn't offer a history of commands
doesn't even understand the arrow keys, left and right (they input [[[A instead), nor any default readline keybindings,
the ones we find in bash et all: C-e, C-a, C-u, C-k, Alt-b, Alt-f etc.
This article is a response to mfiano’s From Common Lisp to Julia which might also convey some developments happening in Common Lisp. I do not intend to suggest that someone coming from a Matlab, R, or Python background should pickup Common Lisp. Julia is a reasonably good language when compared to what it intends to replace. You should pickup Common Lisp only if you are interested in programming in general, not limited to scientific computing, and envision yourself writing code for the rest of your life. It will expand your mind to what is possible, and that goes beyond the macro system. Along the same lines though, you should also pickup C, Haskell, Forth, and perhaps a few other languages that have some noteworthy things to teach, and that I too have been to lazy to learn.
/I also do not intend to offend anyone. I’m okay with criticizing Common Lisp (I myself have done it below!), but I want t
quick survey of swank interfaces in order to see what could be broken out into proper portability libraries or, more optimistically, language extensions.
this is preliminary. i pretty much just went down swank.lisp looking for definterfaces. Some other portability related things are not covered yet.
Encoding/decoding
Babel
Encode a Lisp string to an octet vector of its UTF-8 encoding
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A comparison and wish-list of features for a Common Lispy approach to a (better) Numpy
Features of a Common Lispy approach to (better) Numpy
Numpy is great, in fact it’s one of the things that pulls people to Python. But can it be better?
Common Lisp is great, in fact it’s one of the things that pulls people to Common Lisp. But can it be better? Indeed Python can’t be better than Common Lisp without it becoming another Lisp. The closest we have is Julia. And while it gets some things right, Julia lacks certain features that limit the goodness of a numerical computing library.
All combined, below I will highlight some of the features that I wish a numerical computing library or ecosystem had. I also want to request the readers for their own inputs about how things can be even better. The goal amidst this is solely to keep things numpy-like. I do not intend to - nor have the background to - make a DSL like April or Petalisp.
While I take some interest in performance and numerical computing, I have m
I saw devs leaving CL for a new graal (and eventually coming back). Grass may not be greener on the other side…
Long compilation times
You can't make it a CLI script, because it compiles the whole code WITH dependencies every time, and as soon as you import some serious libraries, compile times will skyrocket. I quickly hit 40 seconds of compilation with just geospatial lib and dataframes. These 40 seconds turned out to be A LOT when you develop interactively. And you can't build everything in a Jupyter Notebook, because eventually you'll have to switch to a CLI script.
Emacs/SLIME frontend to Quicksearch, a search-engine-interface for Common Lisp.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters