Use better named macros?

[Ambrevar]

defnclo is not very readable nor very Common Lispy. Also Emacs does not highlight it by default.

What about define-closure instead? Emacs automatically detects the define- prefix by default.

[kchanqvq]

define-named-closure and named-closure might be more appropriate, but that's very long :(.

I have the feeling traditional Lisp abbreviate a lot. Maybe it's much more efficient for punchcards.

[Ambrevar]

Common Lisp is also moving forward and it'd be neat to encourage readable names. It makes little sense to compromise readability for punchcards support these days ;)

It's fine to have long names (and yet they are not that long), every one can have completion in Common Lisp.

[kchanqvq]

Upon reflecting on my own sentiment, i found another important reason I dislike long name: indeed nowadays inputting long name is not much inefficient, but reading them is. There's physical bandwidth limit of both screen space, and how many symbols per second human brain can process. In an alphabetic writing system, the most practical way to alleviate that is to use acronyms, and acronyms can be read faster than full names once they're starting to be recognized as new morphemes (e.g. car or cdr), however it does have the disadvantage of initially blocking reading instead, before the reader registers them as morphemes.

I think the ultimate solution to this naming problem is to use a better writing system. C'mon, not only alphabetic writing system sucks, but English sucks as well. I suggest switching to a logographic writing system, and a language with more "compositional" word formation, so that acronym still makes sense instead of looking like gibberish.

I have three candidates in mind:

1. sitelen pona. A writing system for toki pona. named-closure will be written as: (poki-nasin nimi, lit. container of method with name) define-named-closure will be written as: (nimi-e poki-nasin nimi, lit. give name to container of method with name)

Pros: very easy-to-learn, very concise, word formation is highly regular and compositional Cons: The current rendering solution need some tweaks to fit Lisp programming https://github.com/janSame/linja-pona/issues/15. Because it doesn't have Unicode code point yet. it requires hacks...

2. 汉字. Chinese characters. named-closure will be written as: 指名闭包, potentially abbreviated as 名包 (lit. name closed parcel, abbreviation lit. named parcel) define-named-closure will be written as: 定义指名闭包, potentially abbreviated as 定名包 (literal: fix meaning of name closed parcel, abbreviation lit. fix named parcel). The abbreviations do look funny, probably because of high level of homonyms in Chinese and we're in fact breaking down two-syllables word (I can't help reading it as "famous handbag" or "famous buns" or "famous Xi Jinping" lol). Maybe don't abbreviate for now because the full form is not too long so far.

Pros: good support on most platforms, have unicode codepoints. Cons: The language is at least 100x larger than toki pona. Words are slightly more verbose, hieroglyphs are more complex. The problem of language size itself might not be a big issue in practice because one do not need to know all of the language, they just need to recognize the pattern of all those recurring technical terms.

3. Iţkuîl. Ithkuil named-closure will be written as: aesyál (lit. manifest method itself) define-named-closure will be written as: aesyawél (lit. (imperative) manifest method itself) It will be more concise in its own writing system, but because the morphemes are mostly single or even half syllable, the romanization do fine.

Pros: Very concise. Romanized script works on most platform. Good Emacs support: https://bitbucket.org/pdonnelly/romanized-ithkuil-emacs-ime/src/master/ithkuil-ime.el. JQ is working on a new version (Ithkuil IV) that will also be regular and easier to learn. Cons: Ithkuil IV is not completed yet. If we start using Ithkuil III, it might become outdated. We could wait for final release of Ithkuil IV.

4. Ygyde. I actually like the language a lot, and the author seems to know Lisp (it is mentioned in the grammar document). However author is rACisT, rip.