As a little schemer, in a year I've gone from "this is a bit wordy" to coming to think Scheme has
the optimal naming conventions. When they are followed, I can get into any repository and quickly
understand whats happening. When I follow them, collisions are the last of my worries. If a phrase
has been used twice, it should be the same function.

The only downside in my experience is that it makes every other communities' idioms appear more
like collections of idiolects, where everyone, keen on brevity, abbreviates in ways that forces the
reader to play philologist.

August 19, 2022 8:06 PM, "Lassi Kortela" <xxxxxx@lassi.io> wrote:

>> locative
>> ephemeron
>> assertion
>> violation
>> reference
>> I like these more than loc, eph, ass, vio, ref.
>> Or what do you have in mind?
>
> E.g. place, weak pair, check, error.
>

FWIW, these words are all in use for various purpose in Guile, and I believe other implementations as well.

> I don't mean to suggest we can adopt these specific words, merely to point out that these sound
> sensible and the longer ones sound obtuse.
>
>> PS I am not a native speaker of English, but I have never had a
>> problem with these "big" (by whatever metric) words. At least to me,
>> precision in wording is more important than brevity, so better use two
>> not-so-short words for two different things than to name the two
>> different things by the same short word. Personally, I think the
>> existing traditions in naming should also be respected if it makes
>> sense. E.g., R6RS makes the distinction between "errors" and
>> "violations" (in its condition hierarchy). When future Scheme
>> standards adopt this division, there are good reasons for sticking to
>> these established terms instead of calling these types, say, "user
>> error" and "programmer error", just to get rid of the "big" word
>> "violation".
>
> Having to make fine distinctions between similar concepts means we have too many concepts. Over the
> long term, most software projects morph into the Titanic. Scheme is getting there. There's nothing
> we can do in the short term about the existing conceptual bloat in RnRS but we should be cautious
> about adding new stuff.