- pro - mailman3.common-lisp.net

Re: Pre-submission discussion: code walking
by Antoniotti Marco 12 May '19

12 May '19

HI > On May 8, 2019, at 18:24 , Michael Raskin <38a938c2(a)rambler.ru> wrote: > > > Thank you for your comments. > >> * The proposal requires the presence of a CDR-NN package. Such a proposal should be made separately. FTTB if CDR-14 is used, only the CDR-NN feature should be provided. I would be in favor of a new CDR stating that a CDR-XX nickname could be added to a package implementing a given feature. > > I thought that maybe I don't want to create too many proposals at once. I see, I will split. > >> * The proposal as is may not be portably implemented by a third party without resorting to implementation support which may or may not be there. The problematic operators are WITH-PARENT-ENVIRONMENT and ENVIRONMENT-ENTRY-NAMES. Do you see any way to provide it in a simple (read: non SBCL) way? >> >> Finally, COPY-ENVIRONMENT may and LEXICAL-ENVIRONMENT also be problematic. > > Note that B-level and C-level support requires some properties of underlying implementation that do not currently hold for many popular ones. I may have misread the proposal, but, AFAIU, even what you call “Level A” cannot be easily provided without a commitment by the implementations. > Also note that I want to provide common names for much more functionality than I want to require. It is enough to have WITH-AUGMENTED-ENVIRONMENT for B-level complieance, and COPY-ENVIRONMENT (or standalone AUGMENT-ENVIRONMENT) is not required even on the C-level. It is purely a «please tell me if you already provide this». > > Frankly, I think SLIME wants to do something that boils down to ability to define ENVIRONMENT-ENTRY-NAMES, so that shouldn't be too bad. > > LEXICAL-ENVIRONMENT has very weak requirements, I think on most implementations it can be defined by a third-party library. > > WITH-PARENT-ENVIRONMENT is definitely completely optional — on the other hand, if the implementation never tracks parent environments, it is OK to always have NIL there. LW already has SYS:MAP-ENVIRONMENT which looks like ENVIRONMENT-ENTRY-NAMES, so, yes, it is definitively doable, like everything else, given a “sufficiently supportive implementation/vendor”. I just feel that CDRs should not make too many requests on the implementation. Apart from that, I would also note that listing names should not be sufficient for a CDR. Functions and macros signatures should also be described (*), as well as types. As for the specific content, I would also explicitly refer to the CLtL2 Environment Section 8.5. All the best Marco Antoniotti (*) To the chagrin of the folks at Franz (you-know-why 3:) 3:) 3:) ) -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

1 0

Re: Pre-submission discussion: code walking
by Antoniotti Marco 07 May '19

07 May '19

Hi I looked at the proposal. I agree it would be useful, but I have two concerns. * The proposal requires the presence of a CDR-NN package. Such a proposal should be made separately. FTTB if CDR-14 is used, only the CDR-NN feature should be provided. I would be in favor of a new CDR stating that a CDR-XX nickname could be added to a package implementing a given feature. * The proposal as is may not be portably implemented by a third party without resorting to implementation support which may or may not be there. The problematic operators are WITH-PARENT-ENVIRONMENT and ENVIRONMENT-ENTRY-NAMES. Do you see any way to provide it in a simple (read: non SBCL) way? Finally, COPY-ENVIRONMENT may and LEXICAL-ENVIRONMENT also be problematic. cheers Marco Antoniotti On Apr 25, 2019, at 16:47 , Michael Raskin <38a938c2(a)rambler.ru<mailto:38a938c2@rambler.ru>> wrote: Hello. I want to try to do something about portability of universally present features, given that stndard revisions are extremely unlikely, and CDR process seems to be the best way to obtain a stable ID for some version of description. As automatic code processing is a large part of Common Lisp identity as it is presented, and there is a small and easy to define chunk of functionality that is missing, I am preparing a CDR on portable code walking support. Before I formally submit a CDR proposal, I want to try to get some feedback. The current version of the writeup I have is at: https://gitlab.common-lisp.net/mraskin/cdr-walkability/blob/master/walkabil… Please comment on that proposal, here or via issues or maybe even merge requests. I will announce the link to the discussion in the ELS mailing list (as ELS conference seems to be the closest approximation to community discussion we have). I considered including Trucler API as an option, but currently I doubt I am able to do it well: mixing a coherent API with multiple optional additions that are useful even as single functions is a harder task. I want to start somewhere. Separately, if someone has some proposals on how to make CDR process used more — or matter more, please share. Probably on cdr-devel https://mailman.common-lisp.net/listinfo/cdr-devel Thank you, goodbye Michael Raskin -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

1 0

Is your company listed in the "awesome" list ?
by vindarel 11 Apr '19

11 Apr '19

Hello lispers, I find quite important to have an up to date list of companies using Common Lisp at hand, to effectively answer: "of course CL is still used and picked by companies today, look:". We now have such a list with https://github.com/azzamsa/awesome-lisp-companies Is your company in it ? We had an old one: http://pchristensen.com/blog/lisp-companies/ where he had this funny good point, which still held until the "awesome" list: > Everyone says “Nobody uses Lisp” and Lispers say “Yes they do, there’s ITA, and, um, Autocad, and, uh, oh yeah, Paul Graham wrote Viaweb in Lisp!” Not very helpful for either side. I encourage you to make a pull request to github, or to create an issue with a couple information, or to simply answer in this thread and I'll edit the list. If your company's website doesn't mention CL, it'd be necessary you explain in a sentence the type of product CL is used for. Thank you ! Vincent

1 0

Looking for Lisp consultant
by Remi van Trijp 03 Apr '19

03 Apr '19

Dear fellow Lisp programmers I am a researcher at the Sony Computer Science Laboratories Paris, and together with the VUB Artificial Intelligence Laboratory in Brussels we have developed an open source framework in Common Lisp for conducting experiments on language evolution (see https://gitlab.ai.vub.ac.be/ehai/babel-core <https://gitlab.ai.vub.ac.be/ehai/babel-core> and https://emergent-languages.org/ <https://emergent-languages.org/>) under the Apache 2.0 license. One of the systems in this framework is Fluid Construction Grammar, a platform for developing natural language grammars for parsing and generation. We use LispWorks for our development, but also ensure compatibility with sbcl. I am currently looking for a Lisp consultant who can help us out for developing in the first place a few free-to-use apps, and if the collaboration is successful, perhaps work on a more ambitious project on refactoring the code, developing additional tools, and reviving some art-science projects we’ve done in the past. The app for which I am currently looking a consultant involves a ready-to-use editor for Fluid Construction Grammar: we often organise ateliers for teaching students how to write grammars in Fluid Construction Grammar, but we always lose time on getting people to install Lisp + other dependencies. We would therefore like to have an editor that already has an image of our software working. I created one myself using LispWorks 7.0 for Mac (which you can find here: https://github.com/EvolutionaryLinguisticsAssociation/Babel2/wiki/FCG-Editor <https://github.com/EvolutionaryLinguisticsAssociation/Babel2/wiki/FCG-Editor>) but it has several bugs/shortcomings and we would like one for supporting multiple platforms. You can work from distance for this project, but we prefer consultants that are sufficiently close to Paris, France for also being able to meet in person (especially if we move to more ambitious projects). If you are interested, you can contact me directly at remi.vantrijp(a)sony.com or remi.vantrijp(a)gmail.com. Kind regards, Remi van Trijp Sony Computer Science Laboratories Paris https://www.csl.sony.fr/ <https://www.csl.sony.fr/>

1 0

Please Contribute what you can to the ASDF Fundraiser (now with Doubling)
by Dave Cooper 16 Feb '19

16 Feb '19

Happy Friday Everyone! Now is your opportunity to inject some energy into your technical community by contributing what you can to the ASDF Appreciation Fundraiser going on here: https://payments.common-lisp.net/asdf Until we reach the doubling limit, your contribution will be amplified by 100% (i.e. DOUBLED), thanks to the generosity of Franz Inc and another donor who remains anonymous. If you're completely satisfied with ASDF, please contribute in order to show appreciation. If you're not completely satisfied, please also contribute, in order to show that people care and attract more energy to the project for continued improvement. Common Lisp continues to survive and even thrive in its way, largely because of incremental efforts and successes by independently-thinking individuals and small companies such as yourselves. With CL, a small amount of sincere effort can have outsized results, and the same is true with your donation, however small or large. Let's keep this awesome power in our hands, and determine our own future! All the best and have a great weekend, -- Dave Cooper Board Member, Common Lisp Foundation

1 0

[Reminder CfP] ELS 2019, 12th European Lisp Symposium, April 1-2, Genova
by Didier Verna 12 Jan '19

12 Jan '19

ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In cooperation with: ACM SIGPLAN In co-location with <Programming> 2019 Sponsored by EPITA http://www.european-lisp-symposium.org/ Recent news: - Keynote by Stefan Monnier on Emacs Lisp - Keynote by Christophe Rhodes on SBCL - Guest appearance by Matthew Flatt on Racket The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 12th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2019 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 01 Feb 2019 Submission deadline - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: Marco Antoniotti, Universita Milano Bicocca, Italy Marc Battyani, FractalConcept, France Pascal Costanza, IMEC, ExaScience Life Lab, Leuven, Belgium Leonie Dreschler-Fischer, University of Hamburg, Germany R. Matthew Emerson, thoughtstuff LLC, USA Marco Heisig, FAU, Erlangen-Nuremberg, Germany Charlotte Herzeel, IMEC, ExaScience Life Lab, Leuven, Belgium Pierre R. Mai, PMSF IT Consulting, Germany Breanndán Ó Nualláin, University of Amsterdam, Netherlands François-René Rideau, Google, USA Alberto Riva, Unversity of Florida, USA Alessio Stalla, ManyDesigns Srl, Italy Patrick Krusenotto, Deutsche Welle, Germany Philipp Marek, Austria Sacha Chua, Living an Awesome Life, Canada Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Macro system
by Alexandre Rademaker 26 Nov '18

26 Nov '18

In the LoL book we learn the flexibility of the Common Lisp macro system. Reading now http://blog.racket-lang.org/2011/04/writing-syntax-case-macros.html It seems that the Racket macros do not necessarily impose constraints to the programmers. But I never really used it. Does anyone here have experiences with both approaches, sufficient to give insights about the good and bad of each one? Alexandre Rademaker Sent from my iPhone

2 2

Common wisdom on arithmetic (IEEE)
by Antoniotti Marco 05 Nov '18

05 Nov '18

Dear all I am fooling around (again!) with the spec of a math library that I want the students to work on as a project. Language is Common Lisp. Essentially the library is an extended generic math library built on the basis of the many ones floating around. Now. Here comes IEEE. And “infinity" Among many implementations there is more or less a consensus about how to “represent” IEEE infinities in CL. E.g. LW > math:long-float-positive-infinity +1D++0 #| +1D++0 is double-float plus-infinity |# CCL ? math:long-float-positive-infinity 1D++0 and so on. NaN is not as clearly defined. LW 45 > math:nan 1D+-0 #| 1D+-0 is double-float not-a-number |# CCL ? math:nan 1D+-0 #| not-a-number |# But to get a NaN in SBCL/CMUCL requires a trick. I use (sb-kernel:make-double-float -524288 0)) ; Courtesy of Raymond Toy. In any case… There are two issues that I would like to brainstorm a bit. The first one pertains rounding modes. Give the current state of affairs, it does not seem possible to access them in all the CL implementations. CMUCL/SBCL give you the necessary hooks, but LW doesn’t. Let’s skip this. The second is just a simple question. Given that we *do* have (with some acrobatics) access to IEEE infinities, would you add symbolic constants to such library like (defconstant +posinf+ ‘+posinf+) or would you just rely on the IEEE infinities? Generic functions like (defgeneric plus (x y) …) Will obviously be affected. I just want to get a feeling about the overall wisdom of this crowd. All the best Marco -- Marco Antoniotti

5 11

[CfP] 12th European Lisp Symposium, April 1-2 2019, Genova, Italy
by Didier Verna 31 Oct '18

31 Oct '18

ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In co-location with <Programming> 2019 Sponsored by EPITA http://www.european-lisp-symposium.org/2019/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 12th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2019 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 01 Feb 2019 Submission deadline - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: tba Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Common Lisp style: multiple packages in same repo
by Daniel Pezely 28 Aug '18

28 Aug '18

I posted this to Stack Overflow but was hoping for more input. https://stackoverflow.com/questions/51638864/common-lisp-style-multiple-pac… May I get recommendations or links to representative code repositories with good style for multiple related Common Lisp packages, please? For instance, consider a high-level workflow library with accompanying lower-level API, each in its own CL package but same git repo due to synchronized releases. Each system (|*.asd| file) isolates tests and may be invoked using: |(asdf:test-system foo :force t)| Separate systems may be built via |make|, which definitely helps isolate SBCL code-coverage reports. Some users of the library may only want to load the lower-level API. For simplifying dependencies for those using higher-level API, it seems best to keep everything bundled in one repo. Any revision to one library would likely require updating all for the same release. I currently have a single directory tree with a subdirectory for each CL package. There's a top-level |Makefile| plus one in each subdirectory that the library maintain would use. The top-level also contains symbolic links for |.asd| files pointing into relevant subdirectories. (It's a library deeply dependent upon POSIX calls via |uiop-posix|, so it's only applicable on an OS with sym-links.) This seems to be an issue at large considering issue #1 for Quicklisp-docs [0]. Found nothing relevant in Google's CL style guide [1], State of the Common Lisp Ecosystem, 2015 [2], Edi's CL Recipes [3] or Lisp-lang [4]. Browsing repos seem to have quite a mix of styles. * [0] https://github.com/rudolfochrist/quicklisp-docs/issues/1 * [1] https://google.github.io/styleguide/lispguide.xml * [2] https://web.archive.org/web/20160305061250/http://eudoxia.me/article/common… * [3] http://weitz.de/cl-recipes/ * [4] http://lisp-lang.org/learn/writing-libraries but see also their section on Continuous Integration Repo to be fixed: https://gitlab.com/dpezely/cl-mmap (commit a23bd88d of 2018-07-14; release will be tagged when fixed) Thanks, -Daniel

8 16