No post body was provided.
Ask HN: If you were designing Common Lisp today, what would you change?
1–10 of 32 posts
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#2Leave less undefined in the specification. In particular, there should be more defined cases for errors in safe code.
Complex type upgrading is just broken. The spec is inconsistent.
sort should have been called nsort, to be consistent with the names of other potentially side-effecting operations. SORT would not alter its argument.
If defpackage has no :use clause, it would be equivalent to (:use), not implementation-defined. Also: make package local nicknames part of the standard.
Many built ins functions should be generic and allow user defined methods if at least one argument is not of a standard-defined class. This should not have an efficiency penalty.
Many built-in classes should be user extensible, or at least have internal generic functions that can be extended. The exemplar here is user defined sequences in SBCL. This would also be useful for hash tables and streams.
Pathnames tried to be general and failed. They need a revamp.
Add support for multiple threads, concurrency, unicode.
Although it saddens me to say it, get rid of the punning of NIL and false, and make CAR/CDR not work on NIL.
Although it's not part of the standard, have a more robust social mechanism for curating and maintaining a semi-standard library, just outside the standard.
Packages should allow weakness, so that if a weak symbol is not used anywhere it can be GCed from the package. This could help with tree shaking.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#3NIL punning should remain. Otherwise there needs to be some NIL-equivalent value or some exception nonsense.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#4Systems programming language in the style of Chez.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#5namespaces tied to an abstraction level.
multi-threads, concurrency would be a process namespace & standard command / data name spaces could be mapped by programmer to how wanted to use in process name space.
error(s) would be done in a 'error' namespace.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#6Using "box of punch cards" as REPL, "punch card machine" as 'solo cpu' and "device operator" as handler for everything else.
Lisp just does the punch card box. Scheme does "the box" with access to the "punch card machine" and emacs covers the whole REPL, 'solo cpu', 'device operator' stuff
So, common lisp needs a 'device operator' namespace.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#7Some sort of governing entity. The ANSI standard has left the language totally dead in the water, and is the single biggest thing holding back this really quite beautiful language
Package local nicknames. The situation that libraries like Alexandria are in is really sad.
Nested namespacing/packages.
The ability to alias imports, like in Python.
In the same vein, most symbols in the spec should be moved into a standard library.
A general equality predicate which can be specialized by the user.
Just replace multiple-value-returns with structs, they don't add anything useful.
Standardize some variant of arrow macros.
Every form which introduces a binding should be able to take a (optional) type specifier. It'd be great if compilers could use this option to remove generic dispatch in certain compilation modes.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#8Some sort of governing entity. The ANSI standard has left the language totally dead in the water, and is the single biggest thing holding back this really quite beautiful language Package local nicknames. The situation that libraries like Alexandria are in is really sad. Nested namespacing/packages. The ability to alias imports, like in Python. In the same vein, most symbols in the spec should be moved into a standar…
why the hate on ansi
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#9Some sort of governing entity. The ANSI standard has left the language totally dead in the water, and is the single biggest thing holding back this really quite beautiful language Package local nicknames. The situation that libraries like Alexandria are in is really sad. Nested namespacing/packages. The ability to alias imports, like in Python. In the same vein, most symbols in the spec should be moved into a standar…
> Just replace multiple-value-returns with structs, they don't add anything useful.
Oh yes they do! They allow to add a return value without modifying all the calling sites. Extremely useful.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#10Systems programming language in the style of Chez.
Interesting can you elaborate?