{"title":"Kilns:没有Lambda的Lisp","authors":"Greg Pfeil","doi":"10.1145/2635648.2635663","DOIUrl":null,"url":null,"abstract":"Kilns is a programming language based on the kell calculus. The kell calculus can roughly be seen as an extension of the πCalculus that adds a notion of \"locality\" (the kell), which provides semi-permeable boundaries that make it possible to restrict the type of communication between components (E.G., machine-local, rather than network). This kell construct also allows for very direct encodings of things like data encapsulation and security capabilities. Kilns has several unique features. While lambdas have been implemented as a library, they are not part of the core language. It also has modified versions of other features that are often considered fundamental to being a lisp. Some examples: Macros are \"lazy\" -- calls to macros can exist before the macro is visible in the relevant scope, and macros are only expanded when the calls exist in certain syntactic contexts (this allows embedding macro calls in mobile processes that will be expanded in some other environment). The fundamental data (and code) structure is not a list, but a multimap. These distinctions have largely come about while finding natural ways to embed the original lispisms in the kell calculus. In trying to minimize the size of the core language while making performance acceptable, I have offloaded even basic numeric representations to libraries, but provide an injection feature that is similar to Philip Wadler's \"Views\" -- defining a translation from a kell calculus definition (say, Peano arithmetic) to a more efficient representation. The compiler provides a set of these from standard library structures to native structures, and then programmers can define injections from their own data structures and operations to standard library structures, because transitivity. There is a lot of ongoing work on Kilns -- from developing a type system, to implementing a data-parallel version of the core match operation in OpenCL, to simply learning the right way to use it. Or even moving away from the kell calculus entirely, which is already at least the third process calculus that this language (or at least its siblings) has been built upon.","PeriodicalId":113396,"journal":{"name":"Proceedings of ILC 2014 on 8th International Lisp Conference","volume":"17 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2014-08-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"1","resultStr":"{\"title\":\"Kilns: A Lisp Without Lambda\",\"authors\":\"Greg Pfeil\",\"doi\":\"10.1145/2635648.2635663\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Kilns is a programming language based on the kell calculus. The kell calculus can roughly be seen as an extension of the πCalculus that adds a notion of \\\"locality\\\" (the kell), which provides semi-permeable boundaries that make it possible to restrict the type of communication between components (E.G., machine-local, rather than network). This kell construct also allows for very direct encodings of things like data encapsulation and security capabilities. Kilns has several unique features. While lambdas have been implemented as a library, they are not part of the core language. It also has modified versions of other features that are often considered fundamental to being a lisp. Some examples: Macros are \\\"lazy\\\" -- calls to macros can exist before the macro is visible in the relevant scope, and macros are only expanded when the calls exist in certain syntactic contexts (this allows embedding macro calls in mobile processes that will be expanded in some other environment). The fundamental data (and code) structure is not a list, but a multimap. These distinctions have largely come about while finding natural ways to embed the original lispisms in the kell calculus. In trying to minimize the size of the core language while making performance acceptable, I have offloaded even basic numeric representations to libraries, but provide an injection feature that is similar to Philip Wadler's \\\"Views\\\" -- defining a translation from a kell calculus definition (say, Peano arithmetic) to a more efficient representation. The compiler provides a set of these from standard library structures to native structures, and then programmers can define injections from their own data structures and operations to standard library structures, because transitivity. There is a lot of ongoing work on Kilns -- from developing a type system, to implementing a data-parallel version of the core match operation in OpenCL, to simply learning the right way to use it. Or even moving away from the kell calculus entirely, which is already at least the third process calculus that this language (or at least its siblings) has been built upon.\",\"PeriodicalId\":113396,\"journal\":{\"name\":\"Proceedings of ILC 2014 on 8th International Lisp Conference\",\"volume\":\"17 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2014-08-14\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"1\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Proceedings of ILC 2014 on 8th International Lisp Conference\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/2635648.2635663\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of ILC 2014 on 8th International Lisp Conference","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/2635648.2635663","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Kilns is a programming language based on the kell calculus. The kell calculus can roughly be seen as an extension of the πCalculus that adds a notion of "locality" (the kell), which provides semi-permeable boundaries that make it possible to restrict the type of communication between components (E.G., machine-local, rather than network). This kell construct also allows for very direct encodings of things like data encapsulation and security capabilities. Kilns has several unique features. While lambdas have been implemented as a library, they are not part of the core language. It also has modified versions of other features that are often considered fundamental to being a lisp. Some examples: Macros are "lazy" -- calls to macros can exist before the macro is visible in the relevant scope, and macros are only expanded when the calls exist in certain syntactic contexts (this allows embedding macro calls in mobile processes that will be expanded in some other environment). The fundamental data (and code) structure is not a list, but a multimap. These distinctions have largely come about while finding natural ways to embed the original lispisms in the kell calculus. In trying to minimize the size of the core language while making performance acceptable, I have offloaded even basic numeric representations to libraries, but provide an injection feature that is similar to Philip Wadler's "Views" -- defining a translation from a kell calculus definition (say, Peano arithmetic) to a more efficient representation. The compiler provides a set of these from standard library structures to native structures, and then programmers can define injections from their own data structures and operations to standard library structures, because transitivity. There is a lot of ongoing work on Kilns -- from developing a type system, to implementing a data-parallel version of the core match operation in OpenCL, to simply learning the right way to use it. Or even moving away from the kell calculus entirely, which is already at least the third process calculus that this language (or at least its siblings) has been built upon.