Am Fr., 19. Aug. 2022 um 22:07 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >>> 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.

A place is not a locative, an weak pair is not an ephemeron. An error
is not a violation (using R6RS semantics). If you fuse the names, you
confound previously well-defined and separate concepts.

> 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.

That's probably a matter of opinion. And then there's the question of
whether it is really a problem that the longer names sound obtuse for
some.

> > 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.

There are few subjects where you have to learn as much terminology and
vocabulary per week as when you study maths. Nevertheless, students
successfully cope with this amount of (sometimes only subtly
different) concepts. And the existence of this sheer volume of
concepts does not mean mathematics is bloated.

Things we want to talk about all have some inherent complexity. One
cannot cope with complexity by glossing over it.

Besides, complexity doesn't necessarily make things harder to
understand or use. One needs far fewer concepts to describe assembler
language precisely than to describe Scheme. But understanding and
writing Scheme is much simpler than what it is for assembler code.

Also, modularity comes to the rescue. For example, the beginner
doesn't have to understand call/cc to write their first successful
programs in Scheme.

Marc
--

* Unfortunately, I can't recall the exact number of new (mathematical)
words per week a survey found, but it was astonishingly high, much
higher than when you study languages, for example.