* common lisp vs elisp. @ 2021-06-20 2:22 Hongyi Zhao 2021-06-20 3:13 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 19+ messages in thread From: Hongyi Zhao @ 2021-06-20 2:22 UTC (permalink / raw) To: help-gnu-emacs Dear all, It's well known that "Common Lisp the Language, 2nd Edition" is a classic monograph on lisp language. I want to know how they differ and to what extent. Any hints will be highly appreciated. Regards -- Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com> Theory and Simulation of Materials Hebei Vocational University of Technology and Engineering NO. 552 North Gangtie Road, Xingtai, China ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 2:22 common lisp vs elisp Hongyi Zhao @ 2021-06-20 3:13 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-20 3:26 ` Hongyi Zhao 0 siblings, 1 reply; 19+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-20 3:13 UTC (permalink / raw) To: help-gnu-emacs Hongyi Zhao wrote: > It's well known that "Common Lisp the Language, 2nd Edition" > is a classic monograph on lisp language. I want to know how > they differ and to what extent. Common Lisp (or CL, 1984) is the industrial-strength Lisp while Emacs Lisp (or Elisp, 1985) is the Emacs domain-specific Lisp. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 3:13 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-20 3:26 ` Hongyi Zhao 2021-06-20 3:42 ` 2QdxY4RzWzUUiLuE 0 siblings, 1 reply; 19+ messages in thread From: Hongyi Zhao @ 2021-06-20 3:26 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs On Sun, Jun 20, 2021 at 11:13 AM Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote: > > Hongyi Zhao wrote: > > > It's well known that "Common Lisp the Language, 2nd Edition" > > is a classic monograph on lisp language. I want to know how > > they differ and to what extent. > > Common Lisp (or CL, 1984) is the industrial-strength Lisp > while Emacs Lisp (or Elisp, 1985) is the Emacs > domain-specific Lisp. So, the following questions come to my mind: 1. Does this mean that the former is a superset of the latter? 2. What's the standard compiler/debugger for the latter on *nix platforms? HY -- Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com> Theory and Simulation of Materials Hebei Vocational University of Technology and Engineering NO. 552 North Gangtie Road, Xingtai, China ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 3:26 ` Hongyi Zhao @ 2021-06-20 3:42 ` 2QdxY4RzWzUUiLuE 2021-06-20 4:04 ` Stefan Monnier via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 19+ messages in thread From: 2QdxY4RzWzUUiLuE @ 2021-06-20 3:42 UTC (permalink / raw) To: help-gnu-emacs On 2021-06-20 at 11:26:43 +0800, Hongyi Zhao <hongyi.zhao@gmail.com> wrote: > On Sun, Jun 20, 2021 at 11:13 AM Emanuel Berg via Users list for the > GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote: [...] > > Common Lisp (or CL, 1984) is the industrial-strength Lisp > > while Emacs Lisp (or Elisp, 1985) is the Emacs > > domain-specific Lisp. > > So, the following questions come to my mind: > > 1. Does this mean that the former is a superset of the latter? No. > 2. What's the standard compiler/debugger for the latter on *nix platforms? There's not really a standard. That's one of the great things about *nix (as opposed to POSIX). :-) If you want a free solution, the de facto environment is SBCL (https://sbcl.org) and SLIME under Emacs. For a commercial solution, try Allegro (https://franz.com/products/allegrocl/). Both implement CLtL2 and have an ANSI standards compliant mode. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 3:42 ` 2QdxY4RzWzUUiLuE @ 2021-06-20 4:04 ` Stefan Monnier via Users list for the GNU Emacs text editor 2021-06-20 4:44 ` Hongyi Zhao 0 siblings, 1 reply; 19+ messages in thread From: Stefan Monnier via Users list for the GNU Emacs text editor @ 2021-06-20 4:04 UTC (permalink / raw) To: help-gnu-emacs 2QdxY4RzWzUUiLuE@potatochowder.com [2021-06-19 20:42:39] wrote: > If you want a free solution, the de facto environment is SBCL > (https://sbcl.org) and SLIME under Emacs. Indeed. > For a commercial solution, try Please don't advertise/promote proprietary products on FSF-managed mailing lists, thank you, Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 4:04 ` Stefan Monnier via Users list for the GNU Emacs text editor @ 2021-06-20 4:44 ` Hongyi Zhao 2021-06-20 6:21 ` Emanuel Berg via Users list for the GNU Emacs text editor ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Hongyi Zhao @ 2021-06-20 4:44 UTC (permalink / raw) To: Stefan Monnier; +Cc: help-gnu-emacs On Sun, Jun 20, 2021 at 12:04 PM Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote: > > 2QdxY4RzWzUUiLuE@potatochowder.com [2021-06-19 20:42:39] wrote: > > If you want a free solution, the de facto environment is SBCL > > (https://sbcl.org) I can't open <https://sbcl.org>, the working website is <http://www.sbcl.org/>, based on my tries. > and SLIME under Emacs. Basically, this means that I can replace ielm with slime (https://github.com/slime/slime) for more comprehensive and advanced functionality. > > Indeed. Thank you for letting me know this fascinating thing. > > > For a commercial solution, try > > Please don't advertise/promote proprietary products on FSF-managed mailing > lists, thank you, > > > Stefan > > HY -- Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com> Theory and Simulation of Materials Hebei Vocational University of Technology and Engineering NO. 552 North Gangtie Road, Xingtai, China ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 4:44 ` Hongyi Zhao @ 2021-06-20 6:21 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-20 6:36 ` Joost Kremers 2021-06-20 7:04 ` Jean Louis 2 siblings, 0 replies; 19+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-20 6:21 UTC (permalink / raw) To: help-gnu-emacs Hongyi Zhao wrote: >> and SLIME under Emacs. > > Basically, this means that I can replace ielm with slime > (https://github.com/slime/slime) for more comprehensive and > advanced functionality. And it should be faster, also. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 4:44 ` Hongyi Zhao 2021-06-20 6:21 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-20 6:36 ` Joost Kremers 2021-06-20 6:57 ` Hongyi Zhao 2021-06-20 7:16 ` Jean Louis 2021-06-20 7:04 ` Jean Louis 2 siblings, 2 replies; 19+ messages in thread From: Joost Kremers @ 2021-06-20 6:36 UTC (permalink / raw) To: help-gnu-emacs On Sun, Jun 20 2021, Hongyi Zhao wrote: > Basically, this means that I can replace ielm with slime > (https://github.com/slime/slime) for more comprehensive and advanced > functionality. Well, that very much depends on what you want to do with it. First, Elisp and Common Lisp look a lot alike, but they are not identical, nor is Elisp a proper subset of Common Lisp. Second, IELM interacts with your Emacs session. If you set a variable or define a function in it, the variable or function is available throughout Emacs. SLIME interacts with a Common Lisp subprocess and whatever you do there has no effect on Emacs. So you can't define a function in SLIME and then call it from somewhere else in Emacs, nor can that function access Emacs' state. -- Joost Kremers Life has its moments ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 6:36 ` Joost Kremers @ 2021-06-20 6:57 ` Hongyi Zhao 2021-06-20 7:35 ` Jean Louis 2021-06-20 12:44 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-20 7:16 ` Jean Louis 1 sibling, 2 replies; 19+ messages in thread From: Hongyi Zhao @ 2021-06-20 6:57 UTC (permalink / raw) To: Joost Kremers; +Cc: help-gnu-emacs On Sun, Jun 20, 2021 at 2:46 PM Joost Kremers <joostkremers@fastmail.fm> wrote: > > > On Sun, Jun 20 2021, Hongyi Zhao wrote: > > Basically, this means that I can replace ielm with slime > > (https://github.com/slime/slime) for more comprehensive and advanced > > functionality. > > Well, that very much depends on what you want to do with it. First, Elisp and > Common Lisp look a lot alike, but they are not identical, nor is Elisp a proper > subset of Common Lisp. > > Second, IELM interacts with your Emacs session. If you set a variable or define > a function in it, the variable or function is available throughout Emacs. SLIME > interacts with a Common Lisp subprocess and whatever you do there has no effect > on Emacs. So you can't define a function in SLIME and then call it from > somewhere else in Emacs, nor can that function access Emacs' state. Such being the case, IELM is the only available REPL env for Elisp, but I'm not sure if it's full-featured. HY -- Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com> Theory and Simulation of Materials Hebei Vocational University of Technology and Engineering NO. 552 North Gangtie Road, Xingtai, China ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 6:57 ` Hongyi Zhao @ 2021-06-20 7:35 ` Jean Louis 2021-06-20 12:44 ` Emanuel Berg via Users list for the GNU Emacs text editor 1 sibling, 0 replies; 19+ messages in thread From: Jean Louis @ 2021-06-20 7:35 UTC (permalink / raw) To: Hongyi Zhao; +Cc: Joost Kremers, help-gnu-emacs * Hongyi Zhao <hongyi.zhao@gmail.com> [2021-06-20 09:59]: > Such being the case, IELM is the only available REPL env for Elisp, > but I'm not sure if it's full-featured. I find it more useful than Common Lisp REPL. If you start observing features, it will allow switching working buffers and thus context of evaluation. That is like multiple REPLs in same session. Then you have nice menues and plethora of options not available in other LISP implementations' REPL-es. Most of time I use M-: to evaluate quickly, thus all of the Emacs is one big REPL. Common Lisp is a pleasure to program. But I have changed almost all programs from Common Lisp to Emacs Lisp without regret as I got the user interfaces both in console and GUI. For now I use Common Lisp on remote servers handling dynamic communication with clients and sending me encrypted emails. I have a plan to switch that as well to Emacs Lisp. My areas of programming are exclusively communications such as emails, SMS, phone calls, faxes, letters, mostly related to marketing and relationships with people and the Dynamic Knowledge Repository. About Dynamic Knowledge Repositories (DKR) https://www.dougengelbart.org/content/view/190/163/ In other subjects, maybe some heavy calculations, collection of data from networks, heavy data processing, networking, I could use Common Lisp. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 6:57 ` Hongyi Zhao 2021-06-20 7:35 ` Jean Louis @ 2021-06-20 12:44 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-27 15:08 ` Andreas Eder 1 sibling, 1 reply; 19+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-20 12:44 UTC (permalink / raw) To: help-gnu-emacs Hongyi Zhao wrote: > Such being the case, IELM is the only available REPL env for > Elisp, but I'm not sure if it's full-featured. Just do it in Elisp if it has something to do with Emacs, otherwise do it in CL if you are aiming to impresses the hard-core computer community... PS. I think a handful of PlayStation 1 games, at least one, was written in some Lisp dialect. That must have been very fun development! Crash Bandicoot? The game itself was a bit imbecille for my refined taste even then, but it had attitude and as for the tech parts it had speed and the whole experience was seamless, including the graphics, so if they used Lisp for it, it sure worked for their purposes... -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 12:44 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-27 15:08 ` Andreas Eder 2021-06-27 15:36 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 19+ messages in thread From: Andreas Eder @ 2021-06-27 15:08 UTC (permalink / raw) To: help-gnu-emacs On So 20 Jun 2021 at 14:44, Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote: > PS. I think a handful of PlayStation 1 games, at least one, > was written in some Lisp dialect. That must have been very > fun development! Crash Bandicoot? Crash Bandicoot was developed in GOOL, a lisp dialect espacially developed for creating games. See https://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/ 'Andreas ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-27 15:08 ` Andreas Eder @ 2021-06-27 15:36 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-28 6:46 ` Jean Louis 0 siblings, 1 reply; 19+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-27 15:36 UTC (permalink / raw) To: help-gnu-emacs Andreas Eder wrote: >> PS. I think a handful of PlayStation 1 games, at least one, >> was written in some Lisp dialect. That must have been very >> fun development! Crash Bandicoot? > > Crash Bandicoot was developed in GOOL, a lisp dialect espacially > developed for creating games. > > See https://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/ Wow, what an amazing article, thanks a lot! I want to make a 2D game tho, that's why I tried to get SLIME and SBCL going, maybe one could do SDL2 with that and have some sprites bounce off the ceiling... -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-27 15:36 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-06-28 6:46 ` Jean Louis 2021-07-06 1:53 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 19+ messages in thread From: Jean Louis @ 2021-06-28 6:46 UTC (permalink / raw) To: help-gnu-emacs * Emanuel Berg <moasenwood@zoho.eu> [2021-06-27 11:37]: > Andreas Eder wrote: > > >> PS. I think a handful of PlayStation 1 games, at least one, > >> was written in some Lisp dialect. That must have been very > >> fun development! Crash Bandicoot? > > > > Crash Bandicoot was developed in GOOL, a lisp dialect espacially > > developed for creating games. > > > > See https://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/ > > Wow, what an amazing article, thanks a lot! > > I want to make a 2D game tho, that's why I tried to get SLIME > and SBCL going, maybe one could do SDL2 with that and have > some sprites bounce off the ceiling... I don't agree to discussions of proprietary software on GNU mailing lists unless there is intention or project to make free software out of it. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-28 6:46 ` Jean Louis @ 2021-07-06 1:53 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-07-06 12:28 ` Alexandre Garreau 0 siblings, 1 reply; 19+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-07-06 1:53 UTC (permalink / raw) To: help-gnu-emacs >> I want to make a 2D game tho, that's why I tried to get >> SLIME and SBCL going, maybe one could do SDL2 with that and >> have some sprites bounce off the ceiling... > > I don't agree to discussions of proprietary software on GNU > mailing lists unless there is intention or project to make > free software out of it. What's proprietary, GOOL? Yes, Game Oriented Object Lisp (GOOL) is proprietary [1] What does it mean that the dialect is made for writing games? You have to have that in _the actual language_ ? :O Hm, also, what does it mean exactly when a *language* is proprietary? Offer support, write a book? Not anyone can write a compiler and/or other tools legally? Or not anyone can take parts of the language to another language s/he is working on? (Heh, were a lot of programming languages developed by women, I wonder...) But that doesn't matter in this/my case, I use Emacs, SLIME, CL (SBCL), all free, right? This is how far I've got [2] - right now I'm just adding stuff, no plan, and I won't need one for a loong time since I can think of A LOT to add :) I know you don't like to use Elisp in Elisp (e.g., cl-lib), but it is OK to use in CL, right? Elisp, I mean? [1] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp [2] https://dataswamp.org/~incal/cl/general-base/ -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-07-06 1:53 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-07-06 12:28 ` Alexandre Garreau 2021-07-06 16:08 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 19+ messages in thread From: Alexandre Garreau @ 2021-07-06 12:28 UTC (permalink / raw) To: help-gnu-emacs Le mardi 6 juillet 2021, 03:53:47 CEST Emanuel Berg via Users list for the GNU Emacs text editor a écrit : > >> I want to make a 2D game tho, that's why I tried to get > >> SLIME and SBCL going, maybe one could do SDL2 with that and > >> have some sprites bounce off the ceiling... > > > > I don't agree to discussions of proprietary software on GNU > > mailing lists unless there is intention or project to make > > free software out of it. > > What's proprietary, GOOL? Yes, Game Oriented Object Lisp > (GOOL) is proprietary [1] So maybe it should be avoided on emacs ML? Or maybe the fact it’s no longer used, not publicly downloadable and usable and buyable, etc. and its advertisement wouldn’t lead to its use, makes it okay? at least for historical reasons/discussion? I don’t know. But usually it is asked not to make advertisement to proprietary software because it would promote its use. > What does it mean that the dialect is made for writing games? > You have to have that in _the actual language_ ? :O What do you mean? > Hm, also, what does it mean exactly when a *language* is > proprietary? Offer support, write a book? Not anyone can write > a compiler and/or other tools legally? Or not anyone can take > parts of the language to another language s/he is working on? > (Heh, were a lot of programming languages developed by women, > I wonder...) It means it has no free-software implementations. Java was a proprietary language once, it is not anymore: https://www.gnu.org/philosophy/java-trap.html Same for swift. Objective-C would have been, without gcc’s strong strong copyleft (which, I hope, will stay, just as strong :/) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-07-06 12:28 ` Alexandre Garreau @ 2021-07-06 16:08 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 0 replies; 19+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-07-06 16:08 UTC (permalink / raw) To: help-gnu-emacs Alexandre Garreau wrote: >>>> I want to make a 2D game tho, that's why I tried to get >>>> SLIME and SBCL going, maybe one could do SDL2 with that >>>> and have some sprites bounce off the ceiling... >>> >>> I don't agree to discussions of proprietary software on >>> GNU mailing lists unless there is intention or project to >>> make free software out of it. >> >> What's proprietary, GOOL? Yes, Game Oriented Object Lisp >> (GOOL) is proprietary [1] > > So maybe it should be avoided on emacs ML? I think it should rather be interpreted like this, say some guy comes and asks, "Hey guys, how does this mail look? Not good, huh? Any hints what mail client to use these days? Also my son show great interest in and - I hope - aptitude for technology, but, as a mere amateur myself, I don't know what advice to give him to help him take 'the next step'?" Then you SHOULD NOT reply - "Try Outlook Express, I've used it for ages, never had any problem. Your son, why don't you buy a Nintendo for Xmas? Always great fun for the entire family" Other than that, one is allowed to discuss technology! The world is not perfect and it will never be. There will always be proprietary and FOSS software - and maybe free hardware to a much larger extent than now, we hope - and never mentioning it won't make it (the proprietary stuff) go away, anyway... > Or maybe the fact it’s no longer used, not publicly > downloadable and usable and buyable, etc. and its > advertisement wouldn’t lead to its use, makes it okay? > at least for historical reasons/discussion? It is OK, no one is suggesting anyone _use_ it. >> What does it mean that the dialect is made for writing games? >> You have to have that in _the actual language_ ? :O > > What do you mean? Take Common Lisp. It isn't a Lisp dialect specifically designed for writing games. Yet you can, for example with SDL and/or OpenGL. Libraries are enough, you don't have (and aren't benefited from) designing a new dialect just for that. I know it worked for them but I still don't like it. Let's see, the CL for loop is pretty practical - how can we adjust that to take game development into the equation, or *iteration*, if you will? errr (I don't know if it happened like that - probably not. Maybe they had good reasons, perhaps associated with hardware specific optimizations? I still don't like the idea.) >> Hm, also, what does it mean exactly when a *language* is >> proprietary? Offer support, write a book? Not anyone can >> write a compiler and/or other tools legally? Or not anyone >> can take parts of the language to another language s/he is >> working on? (Heh, were a lot of programming languages >> developed by women, I wonder...) > > It means it has no free-software implementations. Yes, but what does that mean in practice, what is it that you cannot (legally) do with it? -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 6:36 ` Joost Kremers 2021-06-20 6:57 ` Hongyi Zhao @ 2021-06-20 7:16 ` Jean Louis 1 sibling, 0 replies; 19+ messages in thread From: Jean Louis @ 2021-06-20 7:16 UTC (permalink / raw) To: Joost Kremers; +Cc: help-gnu-emacs * Joost Kremers <joostkremers@fastmail.fm> [2021-06-20 09:46]: > Second, IELM interacts with your Emacs session. If you set a variable or define > a function in it, the variable or function is available throughout Emacs. SLIME > interacts with a Common Lisp subprocess and whatever you do there has no effect > on Emacs. So you can't define a function in SLIME and then call it from > somewhere else in Emacs, nor can that function access Emacs' state. Though it is possible to emulated or get some limited functionality by calling external Lisp or other languages from Emacs Lisp: (defun clisp-number-to-words (n &optional trim) "Returns the cardinal English number representation, for example if N is 4, it would return \"four\"" (clisp (format "(format t \"~R\" %d)" n) trim)) Number of our ancestors in 50 generations (left to thinking): (clisp-number-to-words (expt 2 50)) ⇒ "one quadrillion, one hundred and twenty-five trillion, eight hundred and ninety-nine billion, nine hundred and six million, eight hundred and forty-two thousand, six hundred and twenty-four " Or evaluating string with Perl programming language: (defun perl (string) (if (rcd-which "perl") (if string (rcd-command-output-from-input "perl" string) "") (rcd-warning-message "RCD ERROR: `perl' not found in $PATH"))) (perl "print 2 + 2") ⇒ "4" (perl "print 2 + 2; print \"\n\"; print 10") ⇒ "4 10" Or evaluating variable DATA as string, sending it to external Common Lisp implementation CLISP and getting result from it: (defun clisp (data &optional trim) (if (rcd-which "clisp") (let* ((value (if data (rcd-command-output-from-input "clisp" data "-q" "-norc" "-") "")) (value (if trim (string-trim value) value))) value) (rcd-warning-message "RCD ERROR: `clisp' not found in $PATH"))) (clisp "(princ (+ 2 2))") ⇒ "4 " (clisp "(format t \"~R\" (expt 2 50))") ⇒ "one quadrillion, one hundred and twenty-five trillion, eight hundred and ninety-nine billion, nine hundred and six million, eight hundred and forty-two thousand, six hundred and twenty-four "" or with the macro that allows some easier Lisp writing and illusion of direct evaluation: (defmacro clisp-macro (&rest body) (declare (indent 1) (debug t)) `(clisp (prin1-to-string (quote ,@body)) t)) (clisp-macro (format t "~R" (expt 2 50))) ⇒ "one quadrillion, one hundred and twenty-five trillion, eight hundred and ninety-nine billion, nine hundred and six million, eight hundred and forty-two thousand, six hundred and twenty-four" Though I would like that this macro becomes able to evaluate any number of forms. If somebody has a solutin, let me know. (clisp-macro (princ "First form")) ⇒ "First form" (clisp-macro (princ "First form") (princ "Second form")) -- not working Of course this way it would work: (clisp-macro (progn (princ "First form") (princ " Second form"))) ⇒ "First form Second form" -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: common lisp vs elisp. 2021-06-20 4:44 ` Hongyi Zhao 2021-06-20 6:21 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-20 6:36 ` Joost Kremers @ 2021-06-20 7:04 ` Jean Louis 2 siblings, 0 replies; 19+ messages in thread From: Jean Louis @ 2021-06-20 7:04 UTC (permalink / raw) To: Hongyi Zhao; +Cc: help-gnu-emacs, Stefan Monnier * Hongyi Zhao <hongyi.zhao@gmail.com> [2021-06-20 07:45]: > On Sun, Jun 20, 2021 at 12:04 PM Stefan Monnier via Users list for the > GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote: > > > > 2QdxY4RzWzUUiLuE@potatochowder.com [2021-06-19 20:42:39] wrote: > > > If you want a free solution, the de facto environment is SBCL > > > (https://sbcl.org) > > I can't open <https://sbcl.org>, the working website is > <http://www.sbcl.org/>, based on my tries. > > > and SLIME under Emacs. > > Basically, this means that I can replace ielm with slime > (https://github.com/slime/slime) for more comprehensive and advanced > functionality. IELM is for Emacs Lisp evaluation, you don't replace it, you can just stop using it. Regarding programming language choice maybe you should say what are your subjects of programming? Maybe you can still handle all things with Emacs Lisp. It is well integrated environment while any other Lisp is external. If you for example need some friendly features like menu, that is very easy in Emacs Lisp because the graphical user interface is already there. (easy-menu-define cf-people-menu global-map "People menu" (list "People" cf-people-menu-find-people cf-people-menu-list-of-people cf-people-menu-collaborate cf-people-menu-add-new-people cf-people-menu-edit-people cf-accounts-add-accounts cf-mailing-list-menu cf-central-files-menu rcd-db-database-maintenance-menu ;;hyperscope-menu-module-for-other-menu )) Thus making a menu would be pretty simple in Emacs. Such menu works both in console mode and GUI. Making an equal menu in Common Lisp requires various external libraries and decision on the GUI type, and it will most probably not work in console, thus remote programs through SSH would not be compatible with such. Or Common Lisp would require explicit console work. Various completion functions will also not work, the function `completing-read' you will need to implement yourself. When working with Common Lisp I recommend using external software such as `fzf' or `rofi' for easier menu or choice selection. On the other hand, not only Common Lisp is available, there are many various dialects of Lisp like Scheme and Dr. Racket Description : A full-spectrum language with DrRacket IDE. Formerly known as PLT Scheme. URL : https://racket-lang.org/ Racket will work on various operating systems. Or GNU Guile: Description : Portable, embeddable Scheme implementation written in C URL : https://www.gnu.org/software/guile/ Emacs offers support for many Lisp languages and dialects, many other programming languages, you may evaluate it in real time, compile, or run it. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-07-06 16:08 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-06-20 2:22 common lisp vs elisp Hongyi Zhao 2021-06-20 3:13 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-20 3:26 ` Hongyi Zhao 2021-06-20 3:42 ` 2QdxY4RzWzUUiLuE 2021-06-20 4:04 ` Stefan Monnier via Users list for the GNU Emacs text editor 2021-06-20 4:44 ` Hongyi Zhao 2021-06-20 6:21 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-20 6:36 ` Joost Kremers 2021-06-20 6:57 ` Hongyi Zhao 2021-06-20 7:35 ` Jean Louis 2021-06-20 12:44 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-27 15:08 ` Andreas Eder 2021-06-27 15:36 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-28 6:46 ` Jean Louis 2021-07-06 1:53 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-07-06 12:28 ` Alexandre Garreau 2021-07-06 16:08 ` Emanuel Berg via Users list for the GNU Emacs text editor 2021-06-20 7:16 ` Jean Louis 2021-06-20 7:04 ` Jean Louis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).