2 ms·

> We have an informal rule that every feature that starts with the words "Why not ..." gets rejected. I wonder how much language inertia can be overcome by sur

> We have an informal rule that every feature that starts with the words "Why not ..." gets rejected. I wonder how much language inertia can be overcome by surveying what's been implemented multiple times and ranking them. One imagines a very minimal language with multiple implementations, say, of asynchronous I/O or common data structures. Frequently-implemented features would be good candidates for thoughtful inclusion.

lmilcin 5y ago
That language already exists and it is called *Lisp. In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library.
- fouric 5y ago
  I'm a Common Lisp user, and I would like to refine your claim. I don't think that many true "language features", like borrow checking and a static type system, can be implemented in a Lisp (without writing an entirely new language on top - Lisps are generally Turing complete, so you can always write an interpreter for another language on top, but I would claim that at that point you're not "extending your Lisp" so much as making a new one). Instead, what Lisps seem to excel at is allowing you to implement syntactic sugar. For instance, you can easily write CL macros that give you JSON/hashtable literal syntax, list comprehensions (pretend LOOP didn't exist), foo.bar to access struct elements, and infix notation - those things that people think of as being "part of the language" but don't give you any new capabilities (e.g. closures, a MOP, multiple-value returns, conditions).
- memling 5y ago
  > In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library. I should have been perhaps a bit more clear, though T9 makes that hard. I mean more in the sense of standardization. In some ways, LISP makes a better case for what I've suggested simply because you can modify the syntax with such relative ease. If you see patterns emerge, it makes it easier to standardize a syntactic construction to make it less idiosyncratic.

lmilcin 5y ago

That language already exists and it is called *Lisp. In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library.

fouric 5y ago
I'm a Common Lisp user, and I would like to refine your claim. I don't think that many true "language features", like borrow checking and a static type system, can be implemented in a Lisp (without writing an entirely new language on top - Lisps are generally Turing complete, so you can always write an interpreter for another language on top, but I would claim that at that point you're not "extending your Lisp" so much as making a new one). Instead, what Lisps seem to excel at is allowing you to implement syntactic sugar. For instance, you can easily write CL macros that give you JSON/hashtable literal syntax, list comprehensions (pretend LOOP didn't exist), foo.bar to access struct elements, and infix notation - those things that people think of as being "part of the language" but don't give you any new capabilities (e.g. closures, a MOP, multiple-value returns, conditions).
memling 5y ago
> In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library. I should have been perhaps a bit more clear, though T9 makes that hard. I mean more in the sense of standardization. In some ways, LISP makes a better case for what I've suggested simply because you can modify the syntax with such relative ease. If you see patterns emerge, it makes it easier to standardize a syntactic construction to make it less idiosyncratic.