pro May 2019

pro@common-lisp.net

8 participants
4 discussions

Re: CDR-14 and optional modules
by Marco Antoniotti 01 Jun '19

01 Jun '19

Hi if you don’t load code that implements a feature you wouldn’t be able to push a feature onto the *FEATURES* list. That is, unless you are a jerk :) :) :) and push stuff onto the *FEATURES* list just for the heck of it, or as a, I’d say tasteless, joke :) :) :) Cheers MA > On May 12, 2019, at 22:04 , Michael Raskin <38a938c2(a)rambler.ru> wrote: > > Hello > I look at CDR-14 that says about putting :CDR-NN symbols into > *features* if implementation purports to implement a CDR. What is the > recommended behaviour in the case when the implementation provides > a loadable module to support a CDR? Should the feature be always present > or only appear when the module is loaded? > What are the opinions? > > Thank you, good bye > Michael Raskin > > > -- Marco Antoniotti

3 3

Reading spreadsheets
by Nick Levine 22 May '19

22 May '19

Has anyone tried reading a google spreadsheet from lisp (Allegro)? Searching produced a couple of libraries for this, and neither of them compiled cleanly (which is not where I wanted to spend my morning). - nick

6 8

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro May 2019