4 ms·

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 yo

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
    Some of the things in that list are being done already or provided in different ways. Implementations have weak hash support; not all exactly the same. I haven't seen weak references; that would be an invention. There are expand-all type functions; not all the same. Could it be a library function? Not one that supports everything in every implementation. The code walker support would help. What if an implementation has a &foobar keyword that is supported in its macro lambda lists? A portable expander that doesn't know about this won't properly handle macros that use it. (It will handle global macros because it just calls those, but expand-all has to itself implement macrolet). Code walking is done, with ugly portability switching and whatnot. Also w.r.t. that, add: - useful accessors on macro environment objects! You can't do anything with a macro &env now other than pass it to macroexpand or macroexpand-1. It holds useful information like "is X a lexical variable in this scope?" Speaking of lambda lists: - standard parser for lambda and macro lambda lists.

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
  Some of the things in that list are being done already or provided in different ways. Implementations have weak hash support; not all exactly the same. I haven't seen weak references; that would be an invention. There are expand-all type functions; not all the same. Could it be a library function? Not one that supports everything in every implementation. The code walker support would help. What if an implementation has a &foobar keyword that is supported in its macro lambda lists? A portable expander that doesn't know about this won't properly handle macros that use it. (It will handle global macros because it just calls those, but expand-all has to itself implement macrolet). Code walking is done, with ugly portability switching and whatnot. Also w.r.t. that, add: - useful accessors on macro environment objects! You can't do anything with a macro &env now other than pass it to macroexpand or macroexpand-1. It holds useful information like "is X a lexical variable in this scope?" Speaking of lambda lists: - standard parser for lambda and macro lambda lists.