Hacker News Reader

Comment by eimrine | Hacker News Reader

The article seems like mostly about Common Lisp, but how many of the points are applicable to rest of Lisps? (Scheme, Emacs Lisp, Janet, etc)

View on HN

Racket has mediocre interactive features or so I hear: https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1...

> no condition/restart but just print you a trace, and little runtime inspector/debugger support

CL really was built with interactive support from the ground up.

I don't think Janet has many?

I'm curiuos about the interactivity of Janet as well. I saw that someone added support for opting into a level of indirection for resolving symbols, which would theoretically support re-defining functions interactively. There also appears to be Conjure support for editor integration.

In my case, I wasn't convinced Janet would support REPL-driven programming like Common Lisp, so I decided to try CL first. I very much like the concept of Janet (a Lua-sized Lisp), but I couldn't identify a compelling reason to choose Janet over CL in my case (just some hobby projects).

Janet has the pieces for this in the spork stdlib with netrepl combined with fibers, but there's no standard or pre-configured way to set it up. Its current approach to namespaces doesn't particularly allow for it either, so you have to choose one of a few various hacks for redefining things as you noticed.

People have been asking for it and demonstrating proofs of concepts for the last year or so so it wouldn't surprise me to see it formally addressed soon. But I don't know, I don't have any particularly insight I just like that language and keep half an eye on it.

I find most of it applies to Clojure, although being a younger language there is no code from 30 years ago to run. Based on the stability I’ve seen so far, it wouldn’t shock me if the Clojure code I write today still works 30 years from now.

Edit: There are some nuances of interactive support Common Lisp has that Clojure lacks, but I find Clojure supports interactive development much better than other languages.

Somewhat! The authors talk about the longevity of CL, which is less a fact about lisp than an accident of history. Janet, for instance, is obviously quite new. Elisp is quite old, but I wouldn't use it for non-emacs development. Schemes are old, and while there are lots of one-off schemes which seem to be educational projects for their developers there are also lots of very old and battle-tested dialects (Chicken scheme comes to mind, Racket is old-ish and backed by its use in education).

The interactivity is fairly universal. Scheme in its smallest nuts and bolts doesn't care that much about interactivity, giving eval but no other real support for a REPL, but due to cultural effects pretty much every specific scheme is very interactive. I've seen complaints about every specific lisp I've ever used that it's not a real lisp because it doesn't support [extremely specific interactive option user integrated into their workflow in '93 and can't live without], but everything the authors talked about is likely to be present in just about every lisp.

Janet is not a Lisp, it uses parentheses though.

I have pg's list of nine Lisp ideas [1]. What of these are missing in Janet? My guess is that only 9th one but I would like to understand Lisp (any) vs Janet point.

[1] www.paulgraham.com/diff.html

LISP originally came in an implementation (LISP I) and LISP is short for List Processor.

Janet looks like a really great language&implementation, but it is not similar to that specific List Processor, for example given that it does not use linked lists at its core.

>> it does not use linked lists at its core

does Clojure?

I can implement a Scheme interpreter that passes most test suites using vectors instead of linked lists, would you not consider it a lisp?

> I can implement a scheme that passes most test suites using vectors instead of linked lists, would you not consider it a lisp?

My Symbolics Lisp Machine has a Lisp implementation where some form of vectors are an optimization of lists (-> CDR coding). But that's an implementation detail. For most purposes the thing behaves as it uses linked lists - and even has primitive operators for linked lists as CPU instructions.

CLISP, another Lisp implementation, has its own virtual machine, written in C. There too, CAR, CDR, CONS are primitive operations in the VM:

  [1]> (defun foo (list) (cons (cdr list) (car list)))
  FOO
  [2]> (disassemble #'foo)

  Disassembly of function FOO
  1 required argument
  0 optional arguments
  No rest parameter
  No keyword parameters
  5 byte-code instructions:
  0     (LOAD&CDR&PUSH 1)
  2     (LOAD 2)
  3     (CAR)
  4     (CONS)
  5     (SKIP&RET 2)

For me Lisp means more than parentheses or some vague idea of a language "family". It's a language, a bunch of implementations which have a similar core (data structures, operators) and which share code. These languages tend to have the name 'Lisp' in their language.

Then there is this meaning that Lisp is a very diverse group of languages bases on largely undefined criteria. Like C is a member of the ALGOL language family.

That's the "Lisp family": It includes JavaScript/ECMAScript, Dylan, Clojure, Scheme, Racket, R, SKILL... Some have s-expressions, some not. Some use linked lists, some not. Some are object-oriented, some not. And so on.

But for practical purposes it's meaningless: if I want to know about how a particular Scheme construct works, I would look into a Scheme documentation (or its particular implementation), not into a Lisp book.

Scheme, Clojure, .. all have their own language family by now: there are language definitions, a bunch of similar implementations, shared code, books, ...

It's also funny how people claim that language X is a Lisp, as if that would mean something "special" or even "better". There are lots of excellent and useful programming languages out there, which are not Lisp.

So if Janet refactored the interpreter to use linked lists, CONS/CAR/CDR everywhere in the C code but the language stayed the same (if possible) would it fit your definition of being a lisp ?

> So if Janet refactored the interpreter to use linked lists

Which interpreter do you mean? A Lisp interpreter, which runs Lisp source code or a byte code interpreter?

Lisp is defined that it processes lists, either compiled or interpreted.

I'm looking at interpreted Lisp code in a debugger:

  CL-USER 19 : 1 > :lambda 
  (LAMBDA (A) (DECLARE (SYSTEM::SOURCE-LEVEL #<EQ Hash Table{0} 8010058C43>)) (DECLARE (LAMBDA-NAME FOO)) (SETF A (+ 10 A)) (BREAK) (+ A 20))

  CL-USER 20 : 1 > (car (nthcdr 5 *))
  (BREAK)

The code which is interpreted, is Lisp code in the form of lists. Lists are processed in user programs and the implementation itself processes Lisp code in the form of lists. Both are using the same list data structure, the same representation of the list data structure and the same primitive operators for it.

For me that's the core of Lisp.

If the language and its implementation does not process lists, then don't call it to be a "List Processor".

Am I understand right that Janet becames a Lisp (in your understanding of Lisp) if two conditions will be fullfilled: if everything will be reimplemented on linked lists with CAR/CDR everywhere and also a byte code interpreter will somehow coerce all the C syntax with ability to recompile all C code in such a way to fullfill a "no compile time" condition and that's it?

Sorry for speaking about things I do not understand, just I am searching for a comprehensive answer in "C vs Janet" question. I have a feel that there is something beautiful in Janet but I don't know what, so I have started this tree of discussion.

JavaScript and R are more Lisp-inspired to me. I tend to think of the Lisp family as containing Scheme, Clojure, and other languages with a fairly close resemblance. Common Lisp, its predecessors, and a few other languages like uLisp are more closely related still and are practically, if not strictly, the same language.

I’m not sure this informal taxonomy is “right,” but it seems to be useful and in line with common usage.

what is this fairly close resemblance? Parentheses?

There are a bunch of Lisp like languages without s-expression syntax: Lisp 2, Logo, MDL, RLISP, CLISP (not the CL implementation), Dylan, Racket with its new syntax (Racket2, Rhombus), Skill, ...

For example Dylan is based on Scheme & CLOS + a different syntax + some other influences. https://opendylan.org

https://github.com/dylan-lang/opendylan/blob/master/sources/...

Expression-based and supporting macros are two big features JavaScript lacks that the ones with the close resemblance have. Subjectively, they also have constructs in common that make coding relatively similar (although the presence of features like CLOS, continuations, and multimethods can have a pretty big effect). And yes, they use the same S-expression syntax. (Although you can be a Lisp without it.)

In fairness, R might be closer than I realized since I’ve never done extensive programming in it.

JavaScript started as a Scheme inspired language. It has runtime evaluation, a serialized data structure format, first class functions, garbage collection, dynamic typing, functional/imperative/object-oriented features, Many languages are not just looking at the syntax or the user-facing features of the language, but also at the implementation techniques of Lisp-like languages. An early example was Garbage Collection, which was invented for automatic and dynamic memory management of linked lists in the first Lisp implementation. R for example started as an attempt to reimplement S with a Scheme-like runtime.

and neither is scheme

Why do you say Scheme not a Lisp?

there's obviously a strong family resemblance, but scheme's focus on purity over practicality lends to a much different feel.

one of the illustrations from this 20 year old discussion that someone linked here a bit ago [t] was that, while you might say c is a 'member of the algol family', you wouldn't say that c 'is an algol'. perhaps an extreme example, but the idea is that lisp having a history of multiple implementations doesn't make scheme one of them.

put another way- while schemes extrapolate on a similar kind of purity to that which lisps are already famous for, giving them a kind of 'more lisp than lisp' aura, that shouldn't negate the language split.

[t] https://groups.google.com/g/comp.lang.lisp/c/Bj8Hx6mZEYI (perhaps skim kent pitman's posts for a summary)

Reply on news.ycombinator.com