Lingolol

screwlispDespite ample evidence to the contrary, <a href="https://mastodon.sdf.org/tags/Ilive" class="mention hashtag" rel="nofollow noopener" target="_blank">#Ilive</a> (hmm, if I were also <a href="https://mastodon.sdf.org/tags/evil" class="mention hashtag" rel="nofollow noopener" target="_blank">#evil</a>, that would be a pallindrome as well as a visual collision) Fascinating (if I do say so) <a href="https://mastodon.sdf.org/tags/lispgames" class="mention hashtag" rel="nofollow noopener" target="_blank">#lispgames</a> <a href="https://mastodon.sdf.org/tags/gamejam" class="mention hashtag" rel="nofollow noopener" target="_blank">#gamejam</a> <a href="https://mastodon.sdf.org/tags/gamedev" class="mention hashtag" rel="nofollow noopener" target="_blank">#gamedev</a> <a href="https://mastodon.sdf.org/tags/retrospective" class="mention hashtag" rel="nofollow noopener" target="_blank">#retrospective</a> on <a href="https://mastodon.sdf.org/tags/itch_io" class="mention hashtag" rel="nofollow noopener" target="_blank">#itch_io</a> <a href="https://lispy-gopher-show.itch.io/lispmoo2/devlog/834615/princess-revisited" rel="nofollow noopener" target="_blank">https://lispy-gopher-show.itch.io/lispmoo2/devlog/834615/princess-revisited</a> I am enormously happy with the { verb [ dobj [ prep iobj ] ] } x language dynamic, and how it shares your <a href="https://mastodon.sdf.org/tags/lisp" class="mention hashtag" rel="nofollow noopener" target="_blank">#lisp</a> <a href="https://mastodon.sdf.org/tags/repl" class="mention hashtag" rel="nofollow noopener" target="_blank">#repl</a>, and their concerns are just... Different so they don't collide. I guess I get my <a href="https://mastodon.sdf.org/tags/languageDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#languageDesign</a> friends a little better now. Thoughts?

soc<a href="https://mastodon.social/@mcc" class="u-url mention" rel="nofollow noopener" target="_blank">@mcc</a> <a href="https://social.noyu.me/@hikari" class="u-url mention" rel="nofollow noopener" target="_blank">@hikari</a> I have been doing language design for 15 years, and I still love talking about every aspect involved in it.But I literally never want to deal with Rust people ever again. Seemingly their only motivation in language design discussions is to defend Rust and to assume that anyone not cloning Rust's approach 100% verbatim just means he/she haven't been crabsplained enough.<a href="https://chaos.social/tags/LanguageDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#LanguageDesign</a> <a href="https://chaos.social/tags/rust" class="mention hashtag" rel="nofollow noopener" target="_blank">#rust</a>

Brian DavisI've alluded to my big project of 2023, a homebrewed programming language I'm calling Dyn. Today I published my first article in a series discussing the design choices I've been exploring. This one is about syntax. I don't expect this series will be interesting to many people but writing something intended for public consumption is helpful for my thought process. And if anyone does want to discuss, that would be delightful.<a href="https://vmst.io/tags/programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#programming</a> <a href="https://vmst.io/tags/languagedesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#languagedesign</a><a href="https://fadedbluesky.com/tech/DynSyntax.html" rel="nofollow noopener" translate="no" target="_blank">https://fadedbluesky.com/tech/DynSyntax.html</a>

Kent Pitman<a href="https://mastodon.sdf.org/@screwtape" class="u-url mention" rel="nofollow noopener" target="_blank">@screwtape</a> <a href="https://mastodon.sdf.org/@pkw" class="u-url mention" rel="nofollow noopener" target="_blank">@pkw</a> <a href="https://hachyderm.io/@mnl" class="u-url mention" rel="nofollow noopener" target="_blank">@mnl</a> 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.) <a href="https://www.nhplace.com/kent/Papers/Technical-Issues.html" rel="nofollow noopener" translate="no" target="_blank">https://www.nhplace.com/kent/Papers/Technical-Issues.html</a>I may be far afield and I have no idea if that answers your question or just creates more questions, so I'll stop. :)<a href="https://climatejustice.social/tags/CommonLisp" class="mention hashtag" rel="nofollow noopener" target="_blank">#CommonLisp</a> <a href="https://climatejustice.social/tags/EuLisp" class="mention hashtag" rel="nofollow noopener" target="_blank">#EuLisp</a> <a href="https://climatejustice.social/tags/ISLISP" class="mention hashtag" rel="nofollow noopener" target="_blank">#ISLISP</a> <a href="https://climatejustice.social/tags/Lisp" class="mention hashtag" rel="nofollow noopener" target="_blank">#Lisp</a> <a href="https://climatejustice.social/tags/Macros" class="mention hashtag" rel="nofollow noopener" target="_blank">#Macros</a> <a href="https://climatejustice.social/tags/HygienicMacros" class="mention hashtag" rel="nofollow noopener" target="_blank">#HygienicMacros</a> <a href="https://climatejustice.social/tags/LanguageDesign" class="mention hashtag" rel="nofollow noopener" target="_blank">#LanguageDesign</a> <a href="https://climatejustice.social/tags/Standardization" class="mention hashtag" rel="nofollow noopener" target="_blank">#Standardization</a>

Recent searches

Search options

Administered by:

Server stats:

#LanguageDesign