├── LICENSE └── README.org /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 Andrew 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.org: -------------------------------------------------------------------------------- 1 | * Common lisp next generation 2 | 3 | This is a template document. Its main goal is to collect ideas and propositions about next generation CL (standard/specification/othername). This way, people can commit their ideas and discuss them in issues. Keep in mind that many things proposed here can be contradictory, and the end result may very well crystallize into several differently designed languages. However, this is a step forward, compared to single messages and abrupt threads found on in different random chats blogs and formus. It is certainly time to at least start accumulating all those ideas. now matter how fundamental or small they are. Main inspiration comes from Common Lisp, but people contributing to this certainly know more than one language. 4 | 5 | 6 | * Motivation: 7 | 8 | Common Lisp standard was created in 1994. One of the main motavations for its creation was uniting many relatively big as well as relatively small dialects of previous Lisp, making it an ultimate successor of MacLisp Lisp series. The natural advantage of this is uniting community forces around a single project, thus getting a large amount of manpower for further development. However, as a result the developers had to try to maintain a ceratin level of backwards compatibility with all the previous existing dialects, resulting in language with different not always consistent with each other features, as well as some historical weight. 9 | 10 | 11 | ** Summary: 12 | So far it seems that all suggestions can be divided into three categories -- fully backwards compatible, almost backwards compatible (with very minor refactorizations required)...and basically a new lisp-based lagnauge. Apparently, the new language sugesstions tend to be way more low-level, as the demand for high-level features is already satisfied by CL high flexibility. 13 | 14 | * Alternatives: 15 | 16 | + [[https://common-lisp.net/project/cdr/][CDR Project]] 17 | The project is mainly focused on backwards compatible suggestions, implementated incrementally. 18 | 19 | + Honorable mention: 20 | 21 | [[https://www.cliki.net/Proposed%20Extensions%20To%20ANSI][List of proposed ANSI revisions]] 22 | 23 | And there is also [[https://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications][List of clarifications]] 24 | 25 | 26 | * Fully backwards compatible changes: 27 | 28 | ** High-level features: 29 | 30 | + Extensible loop 31 | 32 | Inextensible loop is the very reasons iterate library exists. 33 | 34 | + Hash tables with arbitrary :test function. 35 | 36 | Also probably typed hash-tables. 37 | 38 | ** General features: 39 | 40 | + Standard support for weak hash table keys and values. 41 | 42 | + Less undefined behavior 43 | 44 | Very generic statement 45 | 46 | + Standard parser for lambda and macro lambda lists. 47 | 48 | There are a lot of generic half-baked ones. 49 | 50 | + CFFI 51 | 52 | Existing one is said to be somewhat decent but surely there are improvememnts. 53 | 54 | ** Low-level features: 55 | 56 | + Require numerically equivalent fixnums to be eq. 57 | 58 | They sometimes are and sometimes aren't. 59 | 60 | + Unicode support 61 | 62 | Please. 63 | 64 | 65 | + Way to write long string literals split across lines with indentation, without involving format: 66 | 67 | ```` 68 | (foo bar "this is just one \ 69 | \ string literal with only single spaces") 70 | ```` 71 | 72 | + Expand-full function: perform all expansion on an expression in a given macro environment. Optionally report all free variables. 73 | 74 | + Security (fixing reader eval, ...) 75 | 76 | Or at least, more security on certain areas. 77 | 78 | * Almost backwards compatible changes: 79 | 80 | + Extensible sequences 81 | 82 | As well as extensible data structures of different kind. 83 | 84 | + Native lazy list via lazy-cons type which satisfies consp. 85 | 86 | While laziness can be theoretically speaking implemented as a library, the __efficient__ (that is, for production use) laziness is very untrivial to make. Thereofre, maybe it makes sense for 87 | maintainers of the language implement them (at some point) as a part of "close to standard" library. 88 | 89 | + Standardize the Meta-Object Protocol for CLOS. 90 | 91 | Instead of closer-mop we should have just mop. 92 | 93 | + Sockets 94 | 95 | + GC finalization support: register callback for finalized object. 96 | 97 | The very necessity of gc is a thing to discuss, but at least some control over it is in high demand. 98 | 99 | + Environments 100 | 101 | Standardtized, and a set of baisc functions to wrok with them. 102 | 103 | + Special characters in string literals via something analogous to \x3F, \177, \n, \t, \u+1234. 104 | 105 | + Standardized code walking primitives: one body of user code with no #+this #-that which correctly walks all special forms. 106 | 107 | * New (presumably low-level) language: 108 | 109 | + Different kind of polymorphism (or none by default. but ability to implement many) 110 | 111 | + Reader macros overhaul 112 | 113 | Details later. 114 | 115 | + Useful accessors on macro environment objects. 116 | 117 | + Type system overhaul 118 | 119 | A lot of small and big things to add -- proper parametrized types, recursived type definitions, more strict (?) type checks and inference, the ability to adjust it so building something like [[https://github.com/stylewarning/coalton][Coalton]] would be less painful. 120 | 121 | + [[https://pvk.ca/Blog/2013/11/22/the-weaknesses-of-sbcls-type-propagation/][Paul Khuong has many notes on potential compiler improvement, regarding sbcl]] 122 | 123 | While many of those ideas are very specific to sbcl, that blog has a lot of material to consider. 124 | 125 | + Separations into libraries: separate class system 126 | 127 | Separate condition system, separate data structuers library, algorithms library, math library, concurrency library, iteration library, code-walking library, .... 128 | 129 | + Overhaul of path names, w.r.t. current OS landscape. 130 | 131 | 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. 132 | 133 | + GC existence. 134 | 135 | This will cause a lot of arguments, and the semantics may change because of it. 136 | 137 | ** Is this idea new? 138 | 139 | Of course not. Attempts to build low level lisps exist, lots of them: [[https://github.com/eudoxia0/corvus][1]], [[https://github.com/tomhrr/dale][2]], [[https://github.com/kiselgra/c-mera][3]], [[https://github.com/eudoxia0/interim][4]] and there are more. 140 | Two things they seemingly lack are: pre-built well defined specification and community visibility and support. 141 | 142 | 143 | Same can be said about attempts to just upgrade exsiting CL implementation, such as famous CL21. 144 | 145 | 146 | * Counterarguments 147 | 148 | + Money 149 | 150 | + Time 151 | 152 | + People 153 | 154 | 155 | 156 | 157 | 158 | 159 | * Conclusion 160 | May not be written until this bulk of this document is finished. 161 | --------------------------------------------------------------------------------