Visual voicemail
- Some Dell that belonged to the school
- JCreator
- Java
- about 5
- Racket
- Emacs 7.Haskell & Common Lisp
- Common Lisp
It is fun to make a cl:loop replacement. It is definitely overdone though. Lately I have been using https://git.sr.ht/~charje/loop to much enjoyment.
For point 7 see: https://github.com/lem-project/async-process/issues/21
I have it ready to be packaged other than that.
I wonder what happens when an elevator panic!s.
I have never received a spam email on the email that I use for guix patches.
Isn’t this (in-package ...) form just a namespace feature?
It is not only a namespace feature; it is first class. You can use find-package to fetch a package object and pass it around and manipulate. It looks like this can be done to some extent in C# as well.
For C# namespaces, exports carry over to different uses of the same namespace, but using statements go out of scope at the end of the current namespace use. That signals to me that imports are not related at all to namespaces. It seems that C++ acts similarly. From what I can tell Both C# and C++ allow for fully qualified names without any sort of import.
I have to agree with you about Rust: they goofed it up my trying to make too many rules about which libraries and symbols can be used in which places.
There are many things to like about Common Lisp packages. In everyday programming, I really like being able to define one or more packages in one file then just have a (in-package package-name) at the top of other files opposed to having sometimes hundreds of lines of imports. Some programming languages are worse than others, but no other programming language that I know of allows one to keep imports in a totally different file.
The real point of this post is to talk about a specific scenario that reveals in interesting interaction between asdf systems (libraries), symbols, and macros. A conversation about packages almost always involves talking about symbols. Here is the situation: there is a library, A, that implements some very useful computations. The public interface for the library is a combination of macros and functions. It is rather verbose though, so you want to wrap it in a macro and create a new library: B. You want the users of your library to only have to use your library and not have to worry about depending directly on library A, so you want to re-export some of the symbols from library A so the users of your library can just use those symbols exported from your library.
If you don't see a problem with this then congratulations: you are sane. This relies on just a couple features:
-
feature of asdf: orthogonal to packages meaning that one can use a symbol from any package without having to explicitly load the system. If a package is loaded, it's symbols can be used.
-
feature of packages: symbols in a package can be referred to by their full name (
package-name:symbol-name) anywhere in anyone's program. It does not matter if they have the symbol imported into their package. It does not matter if they have a package local nickname. It does not matter that they have a different symbol interned with the samesymbol-name. -
macros do not have any feature of their own that make this possible, but because of the previously mentioned features, using a symbol from another library in a macro expansion works just fine. As an added benefit, you cannot expand to symbol from a package that is not exported or from a non-existent package because the reader (which happens before macro expansion, even before macro definition) makes sure all the symbols are accounted for.
I witnessed someone in almost this exact situation. They were using Rust. The problem happened when someone tried to use the macro from library A that had been re-exported from library B. The macro expanded to use some symbols that were qualified assuming that the user had already imported them from library A. However, the user imported from library B. The work around ended up being to not re-export and just tell the user via documentation that they have to explicitly depend on library A, and use their macro.
That is the story. Let me know what you think, and tell me about a time that you were grateful for the way Common Lisp handles packages and symbols.
True. They are not near as nicely integrated as lisp macros though.
- Common Lisp
- Haskell I guess
defmacro. This would probably involve changing the syntax to list form like axel does.
This exact thing happens to me.
JS doesn't do any type inference. Ocaml Connor l type checker knows all the types and is completely type safe without type annotations.
Many farmers growing plants for animal feed. Also there are Deer farms that raise deer specifically for the hunting industry.
I think the bigger problem is that they are hard to write and sometimes break tooling.
-
Common Lisp. I basically only use SBCL. It has good introspection, restarts, and source analysis for debugging. I mainly write theoretical research code that doesn't depend on calling into the JVM or C++ code. I do try to keep my code portable, so I will check with other implementations from time to time.
-
I use GNU Emacs and Sly (though I am thinking of trying Lem). I don't use any structural editing outside of Emacs' built in electric-pair-mode, show-paren-mode, and expand-region (not built in). I don't even use rainbow delimiters anymore. I get all my Common Lisp dependencies from GNU Guix. It is very pleasant to use and is rolling release. In addition to Guix, I use cl-guix-utils, which adds live loading of dependencies quicklisp style.
-
I first learned Racket then Emacs Lisp (both in college). Emacs lisp was more pleasant due to its interactive and self documenting nature. I wanted to write real programs; Common Lisp looked and felt more like Emacs Lisp (but better). I started learning Common Lisp primarily with the "Lisp for the web" series. I was hooked. I learned more mainly through reading the hyperspec, studying other people source code and reading articles. I didn't read any of the famous books until I recently read "Practical Common Lisp". I already knew pretty much everything it had to offer. I wish I had read it sooner.
GNU Guix: https://guix.gnu.org/
cl-guix-utils: https://git.sr.ht/~charje/cl-guix-utils
"Lisp for the web": https://adamtornhill.com/articles/lispweb.htm
"Practical Common Lisp": https://gigamonkeys.com/book/
I know it is an unpopular opinion, but it is a huge headache in general. I don't think the theoretical benefits (which make total sense) actually pay off in reality and are worth the extra headache. I'm not saying they should not have it at all, but it should be at least opt-out instead of forced.
In the case of github, I think it is part of their long drawn out plan of data collection and proprietary lock down. Next they are going to require your house address and government ID. I feel better using an free and open source platform anyway.