Email list hosting service & mailing list manager

A reference type Marc Nieper-Wißkirchen (18 Aug 2022 21:45 UTC)
Re: A reference type John Cowan (19 Aug 2022 01:36 UTC)
Re: A reference type Lassi Kortela (19 Aug 2022 10:03 UTC)
Re: A reference type Marc Nieper-Wißkirchen (19 Aug 2022 10:11 UTC)
Re: A reference type Lassi Kortela (19 Aug 2022 10:25 UTC)
Places in Scheme Marc Nieper-Wißkirchen (19 Aug 2022 10:42 UTC)
Re: Places in Scheme Marc Nieper-Wißkirchen (19 Aug 2022 11:36 UTC)
Re: Places in Scheme Per Bothner (19 Aug 2022 16:33 UTC)
Re: Places in Scheme Marc Nieper-Wißkirchen (19 Aug 2022 17:58 UTC)
Re: Places in Scheme Panicz Maciej Godek (25 Aug 2022 15:20 UTC)
Re: Places in Scheme Ray Dillinger (26 Aug 2022 02:29 UTC)
Re: A reference type Marc Nieper-Wißkirchen (19 Aug 2022 10:54 UTC)
Re: A reference type Marc Nieper-Wißkirchen (19 Aug 2022 11:44 UTC)
Re: A reference type Peter Bex (19 Aug 2022 12:02 UTC)
Re: A reference type Marc Nieper-Wißkirchen (19 Aug 2022 12:26 UTC)
Big words Lassi Kortela (19 Aug 2022 16:29 UTC)
Re: Big words Marc Nieper-Wißkirchen (19 Aug 2022 18:07 UTC)
Re: Big words Lassi Kortela (19 Aug 2022 20:06 UTC)
Re: Big words Marc Nieper-Wißkirchen (19 Aug 2022 20:31 UTC)
Re: Big words blake@xxxxxx (19 Aug 2022 22:06 UTC)
Re: Big words blake@xxxxxx (19 Aug 2022 22:08 UTC)
Re: Big words Arthur A. Gleckler (19 Aug 2022 18:09 UTC)
Re: Big words John Cowan (19 Aug 2022 18:39 UTC)

Re: Big words Marc Nieper-Wißkirchen 19 Aug 2022 18:07 UTC

Am Fr., 19. Aug. 2022 um 18:30 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?

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