6 ms·

You have to think about this ecologically. What niche would a new CL occupy? What use would anyone have for something similar to CL but not identical? How co

You have to think about this ecologically. What niche would a new CL occupy? What use would anyone have for something similar to CL but not identical? How could such a thing catch on? If the features you think should be added are just extensions, it's very likely they can be added as libraries (though there are occasional exceptions). If they actually change the language so as to break existing code, it's very hard to see why anyone currently using CL would want to use your language. The CL ecosystem is already considered to be behind other major languages in terms of library coverage; your new language would be starting from zero on that point. I think the only way a completely new Lisp would catch on is for some company to create their own, and then to spend enough years using it for enough different things that they create an adequate library on their own -- requiring that they get pretty large. But why would a small company, just starting out, create their own Lisp when they could use CL? (Okay, okay, of course PG did exactly that with Arc. But it's still an unusual choice.) CL is unusually mutable as languages go, anyway. It's even possible for a library to turn it into a subtly but pervasively different language -- I think my functional collections library, FSet [0], is a great example. And of course, this is done without breaking existing libraries. [0] https://github.com/slburson/fset https://github.com/slburson/fset

kazinator 10y ago
> How could such a thing catch on? The way C++11 catches on: implementations update to the standard and it creeps into use.
- ScottBurson 10y ago
  C++ implementations catch up to the standard because they know there's user demand. The hard thing for a new CL standard would be getting users to care. Do you know of anything a new standard could offer that would attract wide interest?
  - kazinator 10y ago
    - Unicode support - Special characters in string literals via something analogous to \x3F, \177, \n, \t, \u+1234. - Way to write long string literals split across lines with indentation, without involving format: TXR Lisp: (foo bar "this is just one \ \ string literal with only single spaces") - Standardized code walking primitives: one body of user code with no #+this #-that which correctly walks all special forms. - expand-full function: perform all expansion on an expression in a given macro environment. Optionally report all free variable and function references still emanating from the expanded code. - native lazy list via lazy-cons type which satisfies consp. - require numerically equivalent fixnums to be friggin' EQ, damn it. - Overhaul of path names, w.r.t. current OS landscape. One standard way to parse a POSIX or Windows path string to a path name, or a URL. path names should have a :method for this. - Standardize the Meta-Object Protocol for CLOS. - Standard support for weak hash table keys and values. - Hash tables with arbitrary :test function. - GC finalization support: register callback for finalized object.
    - ScottBurson 10y ago
      > - Unicode support Agreed, it would be nice if this were standard. > - Special characters in string literals via something analogous to \x3F, \177, \n, \t, \u+1234. > - Way to write long string literals split across lines with indentation I haven't needed these often, but I guess some people would use them a lot and there's no downside. > - Standardized code walking primitives: one body of user code with no #+this #-that which correctly walks all special forms. Also agreed. Do you happen to know of an open source code walker that has all the required conditionalizations? I would be curious to see it. > - expand-full function Can't this be in a library? > - native lazy list I haven't done enough programming with lazy lists to have a good feel for the value of this. > - require numerically equivalent fixnums to be friggin' EQ, damn it. Heh :-) Why? Seems like this would be a big problem for ABCL. > - Overhaul of path names, w.r.t. current OS landscape. I agree, it would be nice if there were more standardization here. > - Standardize the Meta-Object Protocol for CLOS. Agreed; this should be easy by now. > - Standard support for weak hash table keys and values. I would prefer a more general weak-reference mechanism that would let us build our own weak data structures. Java has this. It's going to be hard for some implementors, though. > - Hash tables with arbitrary :test function. Desirable, though I don't use the built-in hash tables that much anymore anyway. > - GC finalization support I've never found finalization to be as useful as it sounds like it ought to be. It also seems to have a lot of overlap, both in use cases and in implementation difficulties, with weak references. I would just go with the latter. Overall, this is a good list, though I don't agree with every item, and I have my own desires, as I mentioned previously. The question is whether the community can be pushed to any kind of consensus, at least on the point that there are enough things worth doing that it's worth setting up some kind of formal process to decide on them. It seems like an uphill battle to me. (In any case, I have no time to devote to it myself.)

kazinator 10y ago

> How could such a thing catch on? The way C++11 catches on: implementations update to the standard and it creeps into use.

ScottBurson 10y ago
C++ implementations catch up to the standard because they know there's user demand. The hard thing for a new CL standard would be getting users to care. Do you know of anything a new standard could offer that would attract wide interest?
- kazinator 10y ago
  - Unicode support - Special characters in string literals via something analogous to \x3F, \177, \n, \t, \u+1234. - Way to write long string literals split across lines with indentation, without involving format: TXR Lisp: (foo bar "this is just one \ \ string literal with only single spaces") - Standardized code walking primitives: one body of user code with no #+this #-that which correctly walks all special forms. - expand-full function: perform all expansion on an expression in a given macro environment. Optionally report all free variable and function references still emanating from the expanded code. - native lazy list via lazy-cons type which satisfies consp. - require numerically equivalent fixnums to be friggin' EQ, damn it. - Overhaul of path names, w.r.t. current OS landscape. One standard way to parse a POSIX or Windows path string to a path name, or a URL. path names should have a :method for this. - Standardize the Meta-Object Protocol for CLOS. - Standard support for weak hash table keys and values. - Hash tables with arbitrary :test function. - GC finalization support: register callback for finalized object.
  - ScottBurson 10y ago
    > - Unicode support Agreed, it would be nice if this were standard. > - Special characters in string literals via something analogous to \x3F, \177, \n, \t, \u+1234. > - Way to write long string literals split across lines with indentation I haven't needed these often, but I guess some people would use them a lot and there's no downside. > - Standardized code walking primitives: one body of user code with no #+this #-that which correctly walks all special forms. Also agreed. Do you happen to know of an open source code walker that has all the required conditionalizations? I would be curious to see it. > - expand-full function Can't this be in a library? > - native lazy list I haven't done enough programming with lazy lists to have a good feel for the value of this. > - require numerically equivalent fixnums to be friggin' EQ, damn it. Heh :-) Why? Seems like this would be a big problem for ABCL. > - Overhaul of path names, w.r.t. current OS landscape. I agree, it would be nice if there were more standardization here. > - Standardize the Meta-Object Protocol for CLOS. Agreed; this should be easy by now. > - Standard support for weak hash table keys and values. I would prefer a more general weak-reference mechanism that would let us build our own weak data structures. Java has this. It's going to be hard for some implementors, though. > - Hash tables with arbitrary :test function. Desirable, though I don't use the built-in hash tables that much anymore anyway. > - GC finalization support I've never found finalization to be as useful as it sounds like it ought to be. It also seems to have a lot of overlap, both in use cases and in implementation difficulties, with weak references. I would just go with the latter. Overall, this is a good list, though I don't agree with every item, and I have my own desires, as I mentioned previously. The question is whether the community can be pushed to any kind of consensus, at least on the point that there are enough things worth doing that it's worth setting up some kind of formal process to decide on them. It seems like an uphill battle to me. (In any case, I have no time to devote to it myself.)