Anything Gibson, especially Sprawl Trilogy
Anything Stephenson, though I particularly liked Diamond Age, Cryptonomicon, and Snow Crash, In the beginning was the command line.. oh, I like everything by him.
Seriously though, In the beginning was the command line and Cryptonomicon are basically an ode to 90s hacker culture, the true neckbeard type of CS. Love that aesthetic, culture and ethics.
I don't really get why you'd ever want a Lisp-2. Is there an argument/explanation somewhere that I could read up on?
(I've used Clojure and JS, which also seems like a "Lisp"-1 in that you can just put fns into variables and call them like 1st class fns, I just don't get why the distinction is in any way positive rather than confusing, and in Lisp-2s you now need to dereference everything all the time, like in Ruby).
If I understand it correctly, Lisp-2 is a way (not the only way!) of maintaining more intuitive semantics in the face of macros. If I write the following:
(your-macro
(let ((x (foo y))
(bar x))))
I probably don't want the meaning of FOO or BAR to be up for grabs based on the expansion of YOUR-MACRO, and certainly not LET. Lisp-1s often have hygienic macros to deal with this concern, but not always.
Completing your thought (please let me know if I misunderstood you) Y _is_ up for grabs because what you wrote might macroexpand to for example (let ((y 5)) (let ((x (foo y))) (bar x))).
Where your comments falls down is that all the Lisp-2s I know allow the "function definition" of a symbol to be overriden in a similar way, e.g., in Common Lisp the macro might expand to (flet ((bar (arg) (* 5 arg))) (let ((x (foo y))) (bar x))) where FLET is a macro similar to LET but for function definitions.
Where your comment falls down is that in a Lisp-1, every let is also a flet.
Also, of course, you must use gensyms for any locally bound identifier, whether it is a let or flet. Nobody said that Lisp-2 allows for labels and flets without having to use gensyms; nobody in their right mind is going to lexically bind identifiers in macro-generated code that don't use gensymed names (other than in cases when there is no possible capture).
Lisp-2 addresses (in a good-enough-beats-perfect way) the following problem: the programmer's code wrongly capturing references that the macro would like to use.
The macro wants to generate some (foo ...) call to a function in the global environment. But, oops, in a Lisp-1, a user's local variable foo takes this. In a Lisp-1, the user would have to have a local function by that name.
If global functions have reasonably descriptive names, and local functions are used sparingly, the potential for a clash is low.
We can have a warning when a local function shadows a global one; it won't be too much of a nuisance since global functiions tend to use descriptive names, and local functions are relatively rare compared to local variables.
Yes, that's a good point. Multiple namespaces arose in Lisps before things like FLET and LABELS, so this particular issue is likelier to come up in Common Lisp nowadays. I think there are several historical considerations in play and https://www.dreamsongs.com/Separation.html (as mentioned) is probably the best source for more information.
A lot of the comments mention reasons. In my experience, once you get used to a lisp-2 programming in a lisp-1 feels limiting: you can’t just write
(def str “foo”)
In Clojure, because you’ll shadow the builtin definition of str (which leads to really weird bugs). But, this means that there’s one more thing to think about when naming your variables.
Additionally, I think we’re pretty used to “separate namespaces” for nouns and verbs in normal languages: it’s fairly rare, for example, for the word “run” to be ambiguous between its noun use and it’s verb use, in the context of a sentence.
Lisp-1 fails to prevent the situation that the left position of a form is treated specially, both syntactically and semantically. Yet, the evaluation-strategy is sold that way to programmers: "look, symbols all positions of a compound form are treated uniformly".
It is not true syntactically, because special operators are recognized only in the leftmost position, as are function-style macros.
But it is not even true when all symbols in the form are variable bindings. Because at some point, the function is called, and that is not uniform. The leftmost thing is treated as a function being invoked, and the others as arguments being passed. These are different categories. We take the leftmost object and activate its ability to behave as a process; and we don't do that for the other objects. That's effectively a different semantic space.
Objects potentially have two "semantic bindings": a binding to the ability to behave as a function (denoting a process which takes arguments and produces values, and possibly side effects) and the trivial binding to the value that they denote; e.g. the integer object 3 to the abstract integer three. These bindings are two spaces, effectively. Therefore, Lisp-1 doesn't get away from two spaces. It resolves the leftmost object of a call form in the "function behavior space" and the remaining objects in the "value denotational space", in order to bring about a function call.
Lisp-2 has a cleaner story/explanation of operators. It simply embraces the idea that the left position and argument positions are different, through the entire evaluation stack, rather than trying to pretend they are the same.
In a Lisp-2, you cannot write an expression which refers to an operator as if it were a variable. Whereas in Lisp-1, meaningless nonsense like (progn progn) is possible, in a Lisp-2 this can exist with a meaning. The potential that we can give any form meaning is a core theme in Lisp. The fact that we can bind a progn variable so that (progn progn) works is more "Lispy" than having to give up and conclude that it's an absurdity.
To a certain extent it's just syntax sugar. It's relatively easy to implement a lisp-1 with a macro in a lisp-2 and vice versa.
At this point I'm so used to lisp-2 that I make all sorts of silly mistakes when I program in a lisp-1. In English, a word could be a noun or a verb depending on its position in a sentence, so there is a parallel there. Whether or not it's a good thing is a matter of taste.
The only clearly objective difference is that lisp-1 is simpler, which is probably why most lisps created in the past 30 or so years are lisp-1s.
Yes, JavaScript also has a single namespace, like a Lisp-1.
The advantage of a Lisp-2 is that it makes macro writing easier; you can include calls to known functions in the expansion without having to deal with the possibility that those names have been shadowed.
A Lisp-2 can treat function bindings specially at the compiler level.
In addition to the simplified hygiene, one consideration is that Lisp dialects typically have mutable variables. But the ANSI-Lisp-style labels and flet forms bind functions immutably. Thus a compiler never has to suspect that a local function will change.
In TXR Lisp, developed a way to combine Lisp-2 and Lisp-1 into a single dialect, to get the best of both with almost no downsides. In a nutshell, the square bracket syntax performs Lisp-1 style evaluation: [a b c] means expand/evaluate a, b, c in the same mannner, and then treat the value of a as a callable object which receives the values of b c.
Furthermore, any arguments of [...] which are symbolic (after macro-expansion) are treated in a combined namespace which contains both function and variable bindings. When the symbol is global, if it has both kinds of bindings, preference is given to the variable.
This [a b c] is a sugar for (dwim a b c), which is a special operator that is recognized properly by the macro expander, interpreter and compiler, including the various shadowing corner cases between macro and ordinary bindings.
Thus, there is no reason to have to choose between Lisp-1 and Lisp-2.
However, the implementation is a bit more complicated than just Lisp-2 alone, never mind Lisp-1.
The most commonly expressed reason is that you should be able to use variable names like "list" without shadowing the list function.
Someone with insight mentioned that there was a belief that it would be easier to optimize separate namespaces, but that reality proved them wrong, but I haven't verified that claim.
I wrote my own software, mostly scripts. Does that count?
I have a "todo" folder. It contains a subfolder "contexts", with one text file for each context. There are also "icebox", "inbox", and "projects" files.
I use vim to edit, and I've written a little command that lets me mark lines in my todo files with a "target context/file" and use the command to send them there.
I also have a command to let me add items to the inbox from the command line, they just get appended to the "inbox" file.
Say my inbox file looks like this:
buy milk
buy food
clean garage
send email to bob
I will then mark the lines in the file like so:
buy milk @buy
buy food @buy
clean garage :projects
send email to bob @laptop
Now I'll invoke my command, and it'll send all the lines ending in @x to contexts/x, and all the :y ones to y (i.e. icebox, inbox, projects).
I also have a little script that counts how many tasks are in my various contexts, so I can an overview. When invoked, it currently says this:
home:3 room:2 reflect:5 laptop:9 garage:3 (22)
Overall I'm pretty happy with it. I can add any functionality I want, and most of the time it just takes a few lines of shell or Ruby. It's extremely personalized because I'm the only user.
There are a few things that are missing because of the text file structure. For example, I can't easily reference back how many tasks belong to a given project, because I'd have to store references and introduce IDs, which would look terrible in a text file. At that point I should probably just switch to Sqlite. But that tradeoff isn't so bad - and working with text files is so much easier.
A few of the add-ons I've added with a few lines each include:
- Recurring tasks: recurring/wednesday or recurring/01 contains tasks that will be slurped in every Wednesday or every 1st day of the month, respectively. I just loop through all the files in the recurring folder and try to match them to weekdays or #s.
- integration with "calendar" file. I also wrote a clone of the UNIX calendar that takes my calendar file as an optional argument, highlighting days on which I have things scheduled and shows the appointments for today.
Calendar file has the following format:
Sunday, July 15th:
Do thing
Do other thing
3pm: Meet Bob
Monday, July 16th:
Call Alice
The whole system has evolved over ~5 years or so, starting with a single flat text file I edited in vim. There are various pieces I added over time that I ended up never using, for example I have a stateful command to "choose" a context and then pop the list one at a time, that also lets me complete them. But I find I rarely feel like actually finishing random tasks off a context, I like to scan and refactor/reorganize the context before choosing what to do.
It's interesting how similar refactoring my todo list is to refactoring code. Refactoring gives me a lot of clarity on my tasks, and I typically refactor almost every task, some multiple times.
Anything Gibson, especially Sprawl Trilogy Anything Stephenson, though I particularly liked Diamond Age, Cryptonomicon, and Snow Crash, In the beginning was the command line.. oh, I like everything by him.
Seriously though, In the beginning was the command line and Cryptonomicon are basically an ode to 90s hacker culture, the true neckbeard type of CS. Love that aesthetic, culture and ethics.