common lisp vs elisp.

common lisp vs elisp.

[Hongyi Zhao]

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

Re: common lisp vs elisp.

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

Re: common lisp vs elisp.

[Hongyi Zhao]

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

Re: common lisp vs elisp.

[2QdxY4RzWzUUiLuE]

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.

Re: common lisp vs elisp.

[Stefan Monnier via Users list for the GNU Emacs text editor]

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

Re: common lisp vs elisp.

[Hongyi Zhao]

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

Re: common lisp vs elisp.

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

Re: common lisp vs elisp.

[Joost Kremers]

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

Re: common lisp vs elisp.

[Hongyi Zhao]

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

Re: common lisp vs elisp.

[Jean Louis]

* 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/

Re: common lisp vs elisp.

[Jean Louis]

* 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/

Re: common lisp vs elisp.

[Jean Louis]

* 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/

Re: common lisp vs elisp.

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

Re: common lisp vs elisp.

[Andreas Eder]

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

Re: common lisp vs elisp.

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

Re: common lisp vs elisp.

[Jean Louis]

* 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/

Re: common lisp vs elisp.

[Emanuel Berg via Users list for the GNU Emacs text editor]

>> 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

Re: common lisp vs elisp.

[Alexandre Garreau]

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 :/)

Re: common lisp vs elisp.

[Emanuel Berg via Users list for the GNU Emacs text editor]

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