freenode/lisp - IRC Chatlog
Search
3:53:09
beach
seok: In general, if you don't have a predicate like STRINGP, the way to check it is (TYPEP <object> '<type-descriptor>) so in this case (TYPEP X 'STRING).
4:02:42
ffwacom
the main issue is the package :iterate and :generators both define the #'next symbol
4:03:59
beach
And if the name of the package is too long, use package-local nicknames, now available in every significant implementation.
4:05:10
beach
By using explicit package prefixes, your code is easier to understand, because the person reading it can immediately see what package a symbol comes from.
4:44:42
White_Flame
ffwacom: there's package-local-nicknames, which is an extension that pretty much every lisp implementationhas now
8:07:26
beach
Do we have a collective name for the type specifier names AND, OR, EQL, MEMBER, MOD, NOT, SATISFIES, and VALUES.
9:26:06
beach
I'll just put "compound-only" in the name of the file in which I planned to put code for those type specifier names.
10:43:38
MrtnDk[m]
<phoe "if we can help you in anything r"> I'm mostly into scheme and e-lisp. I guess E-lisp and common lisp are very similar, in some ways at least, maybe not so much in other ways. I understand that CL is more complex.
10:44:58
MrtnDk[m]
phoe: I'm mostly into scheme and e-lisp. I guess E-lisp and common lisp are very similar, in some ways at least, maybe not so much in other ways. I understand that CL is more complex.
10:45:28
phoe
elisp most likely belongs to #emacs and scheme to #scheme and/or other channels related to the various scheme implementations
10:49:55
jackdaniel
technically speaking Common Lisp is LISP (unlike scheme which was designed from scratch)
10:52:39
no-defun-allowed
Time to go to #scheme and ask what operator changes the colour of the cat.
12:53:25
aeth
Emacs Lisp is essentially a historic Lisp in its design, and CL was designed to replace historic Lisps (rms disagreed, and hence we got the archaic-on-release Emacs Lisp), so that's why they're similar.
12:56:32
beach
Was work on Common Lisp as finished as that when RMS wrote Emacs Lisp? Where did you see this information?
12:57:39
aeth
Ah, CLtL 2 is 1990 and only the first CLtL (1984) was available in 1985. https://en.wikipedia.org/wiki/Common_Lisp_the_Language
12:58:08
aeth
It's in one of those histories of GNU (or Emacs) things online, so it would probably be pretty hard to find.
12:58:45
beach
I think he still is, but I doubt that it was as finished enough when he wrote Emacs Lisp.
12:59:15
aeth
phoe: Sorry, I'm used to search engines being trash these days even when I remember the exact phrases I'm trying to search
12:59:35
White_Flame
afair, CL was too big/complex to implement in emacs, so RMS took a simpler route
13:00:50
aeth
White_Flame: well, phoe's link says that RMS opposed some elements of its design, like keyword arguments
13:01:44
beach
I am not sure about that. I sometimes quote the email exchange I had with him when he first released GNU Emacs. I wrote something like "It would be better to first implement a real Lisp system, and then write Emacs in it" (since I had used Multics Emacs then), and he answered something like "Sounds good. Let me know when you have implemented it.".
13:02:38
beach
I just think he wanted Emacs released as soon as possible, and it would have taken longer to write a Lisp system first."
13:05:15
aeth
But then we have this from last year: https://sourceforge.net/p/sbcl/mailman/message/36659403/
13:06:26
White_Flame
or alternatively, pull python out of sbcl and use emacs lisp underneath instead
13:07:27
aeth
elisp-on-CL would be the way to go for that. There already is at least one of those attempts, but it wouldn't be hard to write a fresh one that meets GNU Emacs's expectations exactly.
13:08:52
aeth
Writing a smaller language on the larger language is the easier route. e.g. Scheme-on-CL is only really a few thousand lines while CL-on-Scheme is a large undertaking.
13:11:30
aeth
jmercouris: The only advantage of having elisp-on-CL in a fully GNU Emacs compliant way would be if people were actually going forward with the GNU Emacs on SBCL project which was in the mailing list a year ago
13:14:08
jmercouris
also, too many problems with assumptions made in existing elisp code, actual reuse would be trivial
13:15:42
phoe
elisp as a language is small, but then there's buffers, windows, all the stuff that is more emacs than elisp
13:17:47
aeth
No, it's not an optimal solution, but it will at least give you a working program. Then you can talk about rewriting.