No we should not support enum types derived from strings

[NonNull]

On Wednesday, 12 May 2021 at 15:08:46 UTC, Paul Backus wrote:
> On Wednesday, 12 May 2021 at 14:49:35 UTC, NonNull wrote:
>> No. Ranges are not a generalization of arrays unless you 
>> ignore the most important feature of the notion of a Range. An 
>> array is a sequence of things in space: a spatial container 
>> (all values stored) that happens to be a sequence. A Range is 
>> a sequence of things in time. (Purist definition, often true 
>> in practice.)
>
> Ranges are a generalization of arrays (or slices, if you 
> prefer) in the same way that iterators are a generalization of 
> pointers. In both cases, certain features of the specialized 
> version are ignored or left out in the generalized version. As 
> you've correctly pointed out, one of those ignored features is 
> the array's layout in memory. A range *may* store all of its 
> elements in memory, or it may not; as users of the range API, 
> we are not suppose to know or care.

This is the standard pattern of the interpretation of the meaning 
of Range. It is more concrete. I want the idea of range to escape 
its historical semantic origins.

I am suggesting a different and cleaner interpretation of that 
meaning. One that draws a deliberate line between space and time 
as a means of motivating language design.

Instead of regarding the psychological process of regarding a 
spatial data structure as a range as being the psychological 
process of simply ignoring other non-range features and just 
using range operations, I am suggesting a semantic hard line be 
drawn between the two. A range could be obtained by exploding a 
spatial data structure (array say) and regarded as a distinct 
entity. Concretely the latent temporal sequence of things taken 
from the spatial data structure (the derived range) could be 
regarded as semantically quite different and separate from that 
data structure.

While some may consider this a distinction without a difference, 
it does nevertheless change how one might relate a range to a 
spatial data structure in a programming language.

My view leads to an explicit explode operation of some kind on 
all occasions, whereas yours can munge together range stuff with 
other operations on spatial data structures, so that your spatial 
structure IS a range and abstraction is avoided. Moving away from 
the historical semantics to the semantics I suggest above and 
having that guide language design separates those concerns.

The idea of /explode/ is a nice intuitive fundamental concept 
that is concealed and entangled in D right now. Things could be 
less baroque. Specifically, arrays would then be treated the same 
way as any other spatial data structure. They would not be ranges.