Lmst

@kentpitman
https://medium.com/@kenichisasagawa/thank-you-very-much-7ec0aa0a00da
"
Thank you very much. I couldn't listen to the podcast during the broadcast time as I was at work. Besides, I probably wouldn’t be able to catch all the English spoken by native speakers. But I’m very happy and honored. By the way, I’ve seen the #ISLISP page you mentioned. Easy-ISLisp is not listed there. I’ll try to get in touch when I have some free time. If it gets published, I’ll be able to brag about it to my son. Please convey my regards as well.
"

:initarg と :initform と :accessor の実装は出来て、なんとか、構造体程度の使い方は出来るようになってきた。

#ISLisp

🌘 Truffle ISLISP
➤ Truffle ISLISP在GraalVM的Truffle框架上實現了ISLISP2007標準的特性及其優勢
✤ https://arvyy.github.io/islisp-truffle/
Truffle ISLISP是GraalVM的Truffle框架上的ISLISP2007標準實現。它具備ISLISP的特點，即類似於CommonLisp的輕量版，包括通過通用方法實現的Adhoc多態性、動態和靜態作用域、過程宏。通過Truffle框架實現的好處包括：高性能、C FFI、調試器支持（通過DAP或Chrome工具）、與其他Truffle實現（如Java、Python、JavaScript、LLVM等）的互操作性。
+ 這個Truffle ISLISP聽起來真的很有潛力，可以在GraalVM上實現高性能的ISLISP2007標準。
+ 對於熟悉CommonLisp的開發者來說，這個Truffle ISLISP應該很容易上手
#Truffle ISLISP #GraalVM #Truffle框架 #ISLISP #CommonLisp-lite

@screwtape @pkw @mnl

As I think I mentioned recently (in my LispNYC talk?), McCarthy, at least by time of the standards, wanted there not to be any single dialect of Lisp that claimed the unadorned name Lisp. So there was syntactic room for dialects to compete.

There was discussion in design of EuLisp, an influence on ISLISP, about layers. EuLisp had 3 layers, I think. That layering didn't make it into ISLISP. I don't recall it being proposed for CL, though I might be forgetting at this point.

It was never clear to me, though I was not part of their community, whether the underlying language was a subset of, or just an implementation language for, the surface language.

My only very concrete memory was that someone wanted some transform T such that L1 = T(L0) to be applied at some point. Maybe this came up in the CL macros committee. I was pretty adamant that CL did not need macro "hygiene" like Scheme has.

The urgency of that is due to Scheme's choice of being what I called a Lisp1 (the names Lisp1 and Lisp2 in this context are no relation to versioning you referred to in reference to Lisp 1.5, but are abstract categories that address how many variable namespaces are in the language).

Various characteristics of CL, including but not limited to being a Lisp2, helped insulate it from name collisions in the macro system, so the macro system didn't need to have formal hygiene like in scheme, or so I claimed.

I don't think the CL community wanted to change its macro system. Indeed I'd go so far as to say the easy writing of macros is strongly correlated with the rapid success of the family of Lisps that became CL. Breaking something that was succeeding wildly seemed ill-advised, or at least that's how I perceived things. Obviously this was a community discussion.

The fact of a package system rather than a lexical module system was also relevant to this. It's a subtle issue, but important. Scheme is a language defined by its programs' texts. In Common Lisp, the language semantics is on objects.

Speaking only very approximately here for brevity, the compiler operates on lists made of conses and symbols, not text made of parens and alphanumeric tokens. So there need be no source text in CL. Gensyms can easily be created by macros for variable names in CL, something you can't do in Scheme without help of a hygienic macro system to do rewrites for you. The use of gensyms further insulates macros from name collisions that would be routine in scheme if it had a CL-style macro system.

I think the way in which the package system, the macro system, and the namespacing form a kind of ecosystem is ill-understood by most users, even though they're comfortable with the effect. It only matters to understand it if someone suggests changing one of these without changing the others.

It's sometimes hard for someone from the Scheme community to understand why macro hygiene isn't needed in CL if they don't get how packages are fundamentally different than lexical namespacing. So they propose isolated changes thinking it will solve a problem that isn't really there. It's also hard for them to get why CL users see such proposals as adding complexity rather than removing it.

Goung one level meta, it's worth observing that there are not good language features and bad language features, but good within a context or bad within a context. People sometimes get a feature they like and want to impose it on other languages, not seeing that's harmonious in some and not others.

Context matters in assessing abstracts like goodness. It's the harmony of the ecosystem that matters. Adopting change, even well-meaning change, can be very disruptive, sometimes causing unexpected cascade effects (and community cost in both dollars and happiness) one doesn't realize will be needed.

Some of this is covered in the paper Gabriel and I wrote called Technical Issues of Separation in Function Cells and Value Cells. We were tasked by X3J13 to write such a thing because we disagreed on how things should go and between the two of us would likely hit all the issues. :) If you read carefully, you'll see the paper is a kind of debate between us where one would say something and the other would say "yeah, but.." and inject counterpoint. (This is the origin of the namespacing categories Lisp1/Lisp2. Also, the original paper, titled just Issues of Separation in Function Cells and Value Cells was longer and more X3J13-specific. We tightened it up for journal publication, mostly at Gabriel's insistence, as "Technical Issues..." to emphasize some dropped politics.) https://www.nhplace.com/kent/Papers/Technical-Issues.html

I may be far afield and I have no idea if that answers your question or just creates more questions, so I'll stop. :)

#CommonLisp #EuLisp #ISLISP #Lisp #Macros #HygienicMacros #LanguageDesign #Standardization

🌘 GitHub - sasagawa888/eisl: ISLisp interpreter/compiler
➤ Easy-ISLisp Installation, GNU Emacs support, Invoke eisl
✤ https://github.com/sasagawa888/eisl
這是一個符合ISLisp標準的解釋器和編譯器，可在GitHub上找到。它是由Kenichi Sasagawa編寫的，支持GNU Emacs，並在多個環境中運行良好。
+ 這是一個很好的工具，對於那些需要使用ISLisp的人來說非常有用。
+ 看起來很方便，我會試試看。
#GitHub #ISLisp #interpreter #compiler

The #Telegram and #Matrix groups named #FamilyOfLisp are now synchronized (bridged):

🦎 https://telegram.me/FamilyOfLisp

🦎 https://matrix.to/#/#family-of-lisp:magdeburg.jetzt

The two groups are for friendly exchange and dialogue on topics related to the Family of #Lisp #programming languages.

🌺

🏷️ #Scheme #CommonLisp #Racket #Clojure #DylanLang #ELSConf #AMOP #CLOS #InterLisp #OpenGenera #LispMachine #Medley #ConnectionMachine #Symbolics #AutoLisp #MacLisp #ZetaLisp #EuLisp #ISLisp #CLHS #SICP #AIMA #CLtL2 #PAIP #HTDP

On #Friendica and #Telegram:

›Call for Papers — 16th European #Lisp Symposium — #ELSConf —#Amsterdam — 2023-04-24/25‹

🔗 Friendica: https://libranet.de/display/0b6b25a8-1763-a88a-e526-72b275177682

🦎 Telegram: https://t.me/FamilyOfLisp/309

🌺

🏷️ #CommonLisp #Scheme #EmacsLisp #Clojure #Racket #ACL2 #AutoLisp #ISLISP #DylanLang #SKILL #Hy #Shen #Carp #Janet #Jank #uLisp #Picolisp #Gamelisp #TXR #FunctionalProgramming #AMOP #SICP #CLOS #PAIP #CLtL2 #AIMA #Emacs #VIM #LispWorks #AllegroCommonLisp #ACL #CLISP #SBCL #MetaObject #MetaObjectSystem

If you would like to come over to a friendly group on Telegram focused on the programming languages in the #FamilyOfLisp — please feel welcomed to join!

We are here:

→ https://t.me/FamilyOfLisp 🦎

🌺

🏷️ #Lisp #Scheme #CommonLisp #Racket #InterLisp #Clojure #BaLindaLisp #Hy #ELSConf #ZetaLisp #LispMachine #ConnectionMachine #ThinkingMachines #Emacs #AutoLisp #CLOS #AMOP #SICP #CLtL2 #PAIP #AIMA #PCL #Symbolics #Genera #DylanLang #LFE #ISLisp #Arc #Janet #Jank #OnLisp #HTDP #CLHS #EuLisp