Hacker News Reader

Comment by lenkite | Hacker News Reader

> I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages.

Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.

View on HN

And it remains in a state of almost getting to the point of generic collections (like C++, Clojure, many others) using the standard functions, but not quite getting there. There are functions (not generic functions) which operate on sequences, but no standard way to extend what types are considered sequences (as one example). It makes sense that the 1995 version of the spec would be incremental, but without a further development (or consensus amongst the implementations if no official standard) it's difficult to continue moving forward to make better use of the language's generic function capabilities.

That's where Clojure, Julia, and many others have advanced beyond what CL (by the standard) provides. The language needed at least one or two more standards to drive those features forward, but never got them.

I don't quite understand what you mean by generic collections in this case. Do you want to restrict a list to only contain one specific type?

I wrote that quickly and should have edited it for clarity. What I meant was a new collection type that could be treated as a sequence.

https://www.lispworks.com/documentation/HyperSpec/Body/17_a....

None of the functions operating on sequences are generic, so you cannot create your own type and do a `defmethod` and have them automatically adapt to it. And unlike `print-object` which gets used by format and print and others, there's also no "protocol" (or whatever term you like) generic function you can implement which will make your collection acceptable as a sequence.

You could build something like this, and maybe shadow the standard functions so that it's not a new set of functions from a user perspective, but it's a notable absence in a language with a rich OO system through CLOS. It makes sense that it wasn't in the original spec, but I still think it would have been something that would have been added if the development of CL (as a standard) had continued.

Oh, I understand. For what it's worth, some implementations do have that as an extension, although I've personally never used it. See http://www.sbcl.org/manual/#Extensible-Sequences.

> The standard hasn't been updated since 1995

The latest finalised submission to the Common Lisp Document Repository (confusingly called CDR instead of CLDR) dates from August 4, 2013. CDRs are the equivalent to the SRFIs from the Scheme world. You could argue that they are not THE standard, but they are A standard. And considering the original standardization supposedly cost 400,000 USD (about 900,000 USD in today's money), I can see why there hasn't been another official ANSI standard.

Since my job involves a lot of Unicode stuff, I personally would have been confused if it had been called the CLDR, thinking that it was referring the Common Locale Data Repository. (I have to look something up in the CLDR about once a month on average).

And since the Common Lisp Document Repository appears to have been created in 2006 (the first document at https://cdr.common-lisp.dev/index_files/final.html is a description of the rationale for its existence, dated August 2006) while the Common Locale Data Repository was created in 2003, the Common Locale Data Repository had the CLDR acronym first. So kudos to the Common Lisp Document Repository folks for not overloading the acronym but finding an alternative.

I see. Wasn't aware of this. However, it does not appear that an official standard for concurrency exists within the Common Lisp Document Repository (CDR). To be honest, CL implementers should just solicit donations for producing a standard.

There are also other basic things needed for adoption - standard APIs for database providers, etc

https://github.com/CodyReichert/awesome-cl lists some concurrency packages, such as https://github.com/sionescu/bordeaux-threads and https://github.com/sharplispers/lparallel, as being "so widespread and solid that they became community standards. You can't be wrong with them." I don't know enough to know whether or not they're right about those being widespread, but if that list is wrong then I'm sure someone will chime in to say so.

So while the official standard may not have concurrency, that does not mean that there isn't a de facto community standard way to do it.

CL may not but other lisps do. Clojure’s concurrency is just so hawt

Reply on news.ycombinator.com