- pro - mailman3.common-lisp.net

a short venting about scheme
by Attila Lendvai 25 Jun '24

25 Jun '24

context: i'm diving deeper into scheme for the first time in my life... and i have to say that i used to have this impression throughout the years i was hacking CL that scheme is a more cleaned up lisp, that it's more thought out than CL. but i don't think that anymore. it's simply leaner, but it's worse at some key parts (and it's not even due to hard compromises, it's simply not designed well at some parts). one example, that initiated this venting, is the API of WITH-EXCEPTION-HANDLER. i don't want to get too deep into this, i just want to express a glimpse of contrary opinion that i have never met thoughout my years of lisp hacking: scheme is not a cleaned up CL. it's just another dialect. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Keep this thought handy when you feel a bit of rage coming on: it isn't manly to be enraged. Rather, gentleness and civility are more human, and therefore manlier. A real person doesn't give way to anger and discontent, and such a person has strength, courage, and endurance ― unlike the angry and complaining. The nearer a man comes to a calm mind, the closer he is to strength.” — Marcus Aurelius (121–180), 'Meditations'

7 9

CLAST: major refactoring
by Marco Antoniotti 23 Jun '24

23 Jun '24

Hi I just pushed a major rework of the CLAST internals. The system is now pretty much usable, of course with an emphasis on the "pretty much". I will welcome any bug report to improve it. Tested on LW, SBCL and Allegro 11.x. CMUCL and CCL will work as well (just need a little time). Probably also ECL. The naughty Java crowd giving us ABCL instead needs to do some work (naughty, naughty, naughty)! People working on other implementations, please drop me a line. https://clast.sf.net (The documentation is not up to date, but that's minor) Enjoy -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

1 0

static-vectors:free-static-vector for LispWorks
by shubhamayare＠yahoo.co.in 31 May '24

31 May '24

Hello all, Currently, static-vectors:free-static-vector on LispWorks is an empty function.This function should free an array allocated with static-vectors:make-static-vector.On LispWorks, static-vectors:make-static-vector uses make-array with :allocation :static.Then, what should be an appropriate definition for free-static-vector? I discovered raw::free-an-object that does what is intended. Does anyone know if there'sa better candidate for the job? Thanks and Best,Shubhamkar Ayare / digikar

2 2

Fwd: Git hunk header regex for CL
by Scott L. Burson 01 Apr '24

01 Apr '24

Hi all, I am using Git to manage a CL project I am working on, and have noticed that there is no predefined regular expression to pull out "hunk headers". If you look at 'git diff' output, each hunk (sequence of consecutive lines with differences noted) has a header line, which is intended to show the first line of the top-level syntactic object (function definition, class declaration, etc.) that contains the hunk, so you can quickly see what function, class, etc. it is within. To find the appropriate header line for each hunk, Git scans backwards from the top of the hunk with a regular expression, and takes the first line that matches. The regex to use, of course, depends on the language of the source file. Git has a table of built-in regexes for a number of languages, including Scheme, but there is neither a generic Lisp entry nor a more specific CL entry. I am inclined to submit one for inclusion, but I wanted to bounce it off you folks first. Here is the current Scheme regex. This is in POSIX Extended ("ERE") syntax: ^[\t ]*(\\(((define|def(struct|syntax|class|method|rules|record|proto|alias)?)[-*/ \t]|(library|module|struct|class)[*+ \t]).*)$ This is unfortunately not general enough to work for CL, as it doesn't pick up 'defun', though it does allow some other CL constructs. So I started to think about what would be good for CL. Some possibilities: 1. Simply match any line that starts with an open paren in column 0. The upside of this simple rule is that it allows for arbitrary top-level construct names. But if you indent your defuns for some reason, it will overlook them. 2. Match any line that starts with '(def', even if indented. This could have false positives. 3. Match either (1) or (2). I'm leaning toward (3), but would like to hear your thoughts. Certainly, we could use a more specific regex that matches only predefined CL top-level constructs, but this seems wrong to me considering that CL encourages us to define macros to add such constructs when we see a need. -- Scott

3 2

DEFTYPE and SATISFIES
by Marco Antoniotti 22 Feb '24

22 Feb '24

Hi I just stumbled upon this and I need confirmation. You cannot do anything like this, can you? *(defstruct foo x)* *(deftype foo-with-x (x) (satisfies 'foo-with-x-p)) ; No `x'!* *(typep (make-foo :x 42) '(foo-with-x 42))* I.e., there is no way to pass the *x* to *foo-with-x-p*, is there? All the best MA -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

4 6

[Last CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna
by Didier Verna 18 Feb '24

18 Feb '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 25 2024 ** EXTENDED ** - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ 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. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. 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 link http://www.easychair.org/conferences/?conf=els2024. 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. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Organizing Chair ~~~~~~~~~~~~~~~~ Didier Verna, EPITA, France Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michal Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

Academic endian question
by Marco Antoniotti 06 Feb '24

06 Feb '24

Hello everybody, I am in a rabbit hole (don't ask!), and I need to drag some other people with me. What is the consensus about the most portable way to detect the endianness of a machine/platform? (Ok, we can assume that while running on an ARM the endianness is "fixed" by the OS) All the best MA -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

5 6

[CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna, Austria
by Didier Verna 19 Jan '24

19 Jan '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 Sponsored by EPITA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 18 2024 - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ 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. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. 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 link http://www.easychair.org/conferences/?conf=els2024. 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. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michał Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

Re: Help with bit bashing code: differences between C and CL
by Bob Cassels 14 Nov '23

14 Nov '23

Yes, that’s the Steele (and JonL) paper I was thinking of. > On Nov 13, 2023, at 2:16 AM, raymond.wiker(a)icloud.com wrote: > > “How to Print Floating-Point Numbers Accurately”, perhaps? > > https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf > >> On 10 Nov 2023, at 12:37, bobcassels(a)netscape.net wrote: >> >> I did the Symbolics Lisp Machine implementation of floating point print. Mine was completely accurate, using exact rational arithmetic with bignums. But not very efficient. >> >> I have seen papers showing how to be accurate with fixed precision arithmetic. It requires great care. I believe that some C or C++ implementations use this procedure. So I would not be surprised if some implementation of floating point printing is incorrect. >> >> I have a vague recollection of some paper by Guy Steele on the subject. I recall using ideas from Bill Gosper's continued fraction work. >> >> >> On Nov 10, 2023 5:39 AM, Marco Antoniotti <marco.antoniotti(a)unimib.it> wrote: >> Thank you. >> >> I have not checked the details, but are you implying that clang printf is... buggy? Knuth has such a caveat (about buggy printf implementations) on his page. >> >> All the best >> >> Marco >> >> >> On Fri, Nov 10, 2023 at 11:35 AM <raymond.wiker(a)icloud.com <mailto:raymond.wiker@icloud.com>> wrote: >> I think that clang is simply printing more information than it is allowed (or supposed) to. For a double-precision IEEE754 float, the number of significant digits should be >> >> (floor (* 54.0d0 (/ (log 2.0d0) (log 10.0d0)))) >> >> which evaluates to 16 (53-bit mantissa + 1 hidden digit). The Lisp output has exactly 16 significant digits, while the clang output has 20. >> >> The actual correct digits seem to be >> >> (ash (expt 10 52) -52) >> >> which evaluates to >> >> 2220446049250313080847263336181640625. >> >> >> >> >> >> On 10 Nov 2023, at 09:55, Marco Antoniotti (as marco dot antoniotti at unimib dot it) <lisp-hug(a)lispworks.com <mailto:lisp-hug@lispworks.com>> wrote: >> >> Hi >> >> Thanks Pascal. >> >> For LW on Intel (Mac) the ULP seems the same. With SBCL you should actually be able to peek at the actual bits making up the double float. Can you do something similar with LM? >> >> Just curious: has anybody tried this on a M*/Arm Mac? Or, with LW, on your smartphone? :) >> >> Cheers >> >> MA >> >> >> On Fri, Nov 10, 2023 at 8:29 AM Pascal Bourguignon (as pjb at informatimago dot com) <lisp-hug(a)lispworks.com <mailto:lisp-hug@lispworks.com>> wrote: >> >> >> On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)unimib.it <mailto:marco.antoniotti@unimib.it>> wrote: >> >> <problem-loop.lisp> >> >> >> From the start, it looks like the ulp is more precise in C: >> >> >> sbcl: 2.220446049250313d-16 >> clang: 2.2204460492503130808e-16 >> >> (using %.20g instead of %.20f) >> >> Or perhaps it’s only the display procedure that truncates in lisp? >> >> -- >> __Pascal J. Bourguignon__ >> >> >> >> >> >> >

1 1

Re: Help with bit bashing code: differences between C and CL
by Marco Antoniotti 13 Nov '23

13 Nov '23

Thank you Raymond. Yes I am aware of the paper and of the vagaries of printing floats FROM binary. I was, at this point, going in the reverse: printing the binary representation of a float. Having said that, I love the sentence in the paper "we did not think it was such a big deal". It looks like it still is 🙄 Also, an ode to Common Lisp (preaching to the choir): the code I wrote is, IMHO, somewhat more portable than the C versions I saw around, thanks to all the float introspection functions and the (let's say it! underdocumented) DECODE-FLOAT and INTEGER-DECODE-FLOAT functions. All the best Marco On Mon, Nov 13, 2023 at 8:17 AM <raymond.wiker(a)icloud.com> wrote: > “How to Print Floating-Point Numbers Accurately”, perhaps? > > https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf > > On 10 Nov 2023, at 12:37, bobcassels(a)netscape.net wrote: > > I did the Symbolics Lisp Machine implementation of floating point print. > Mine was completely accurate, using exact rational arithmetic with bignums. > But not very efficient. > > I have seen papers showing how to be accurate with fixed precision > arithmetic. It requires great care. I believe that some C or C++ > implementations use this procedure. So I would not be surprised if some > implementation of floating point printing is incorrect. > > I have a vague recollection of some paper by Guy Steele on the subject. I > recall using ideas from Bill Gosper's continued fraction work. > > > On Nov 10, 2023 5:39 AM, Marco Antoniotti <marco.antoniotti(a)unimib.it> > wrote: > > Thank you. > > I have not checked the details, but are you implying that clang printf > is... buggy? Knuth has such a caveat (about buggy printf implementations) > on his page. > > All the best > > Marco > > > On Fri, Nov 10, 2023 at 11:35 AM <raymond.wiker(a)icloud.com> wrote: > > I think that clang is simply printing more information than it is allowed > (or supposed) to. For a double-precision IEEE754 float, the number of > significant digits should be > > (floor (* 54.0d0 (/ (log 2.0d0) (log 10.0d0)))) > > which evaluates to 16 (53-bit mantissa + 1 hidden digit). The Lisp output > has exactly 16 significant digits, while the clang output has 20. > > The actual correct digits seem to be > > (ash (expt 10 52) -52) > > which evaluates to > > 2220446049250313080847263336181640625. > > > > > > On 10 Nov 2023, at 09:55, Marco Antoniotti (as marco dot antoniotti at > unimib dot it) <lisp-hug(a)lispworks.com> wrote: > > Hi > > Thanks Pascal. > > For LW on Intel (Mac) the ULP seems the same. With SBCL you should > actually be able to peek at the actual bits making up the double float. > Can you do something similar with LM? > > Just curious: has anybody tried this on a M*/Arm Mac? Or, with LW, on > your smartphone? :) > > Cheers > > MA > > > On Fri, Nov 10, 2023 at 8:29 AM Pascal Bourguignon (as pjb at > informatimago dot com) <lisp-hug(a)lispworks.com> wrote: > > > > On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)unimib.it> > wrote: > > <problem-loop.lisp> > > > > From the start, it looks like the ulp is more precise in C: > > > sbcl: 2.220446049250313d-16 > clang: 2.2204460492503130808e-16 > > (using %.20g instead of %.20f) > > Or perhaps it’s only the display procedure that truncates in lisp? > > -- > __Pascal J. Bourguignon__ > > > > > > > >

1 0