Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Tue, 4 Jun 2024 15:16:57 +0100
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <v3n7ko$evip$1@dont-email.me>
References: <v3merq$b1uj$1@dont-email.me> <v3ml0d$bpds$5@dont-email.me>
 <v3mlrb$c7d5$1@dont-email.me> <v3ms7b$d5sq$1@dont-email.me>
 <v3mtf2$ct28$2@dont-email.me> <v3n4is$emdc$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 04 Jun 2024 16:16:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="027492d54fa7a72a30fd705d730c9473";
	logging-data="491097"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Je21Gr2AqrNkmRewSrssz"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RQSAS8mi9ffsYihYkEowq/lBUu4=
In-Reply-To: <v3n4is$emdc$1@dont-email.me>
Content-Language: en-GB
Bytes: 4018

On 04/06/2024 14:24, David Brown wrote:
> On 04/06/2024 13:23, bart wrote:
>> On 04/06/2024 12:02, David Brown wrote:

>>> It is fine if you have a language that has good support for lists, 
>>> sets, ranges, and other higher-level features - then an "in" keyword 
>>> is a great idea.  But C is not such a language, and that kind of 
>>> feature would be well outside the scope of the language.
>>
>> I disagree. I have a script language where 'in' works with all sorts 
>> of data types, and where ranges like a..b and sets like [a..b, c, d, 
>> e] are actual types.
> 
> C is not a script language.
> 
>>
>> Yet I also introduced 'in' into my systems language, even though it is 
>> very restricted:
>>
>>      if a in b..c then
>>      if a in [b, c, d] then
>>
>> This is limited to integer types. The set construct here doesn't allow 
>> ranges (it could have done). Neither the range or set is a datatype - 
>> it just syntax. (I can't do range r := 1..10.)
> 
> Adding such a feature to your own personal language, for your own 
> personal use, is easy enough (relative to the rest of the work involved 
> in designing your own personal language and making tools for it, which 
> is of course no small feat).  Adding it to C with its standards, 
> existing code, toolchains, additional tools, developers, etc., is a 
> whole different kettle of fish.

I was responding to your comment:

"and that kind of feature would be well outside the scope of the language."

I think it can suit that level of language if you avoid being too ambitious.

I agree it is not practical to apply to C at this point, not without 
making it ugly or unwieldy enough that people might as well use existing 
solutions.

(Such a feature also aids simpler non-optimising compilers. Take these 
examples that all do the same thing:

     if a <= f() and f() <= c then fi

     if a <= f() <= c then fi

     if f() in a..c then fi

If the two f() calls in the first example were considered common 
subexpressions, I don't have the means in my compiler to detect that 
that and evaluate them just once.

In the other two examples, the language lets you express that directly.

Even for a simpler 'b in a..c' example, it is easier to generate more 
efficient code, and do that more efficiently too than building something 
up only to tear it down again.)


>>> It would be easy enough to write a macro "in_range(a, x, b)" that 
>>> would do the job.  It is even easier, and more productive, that you 
>>> simply write the "valid_char" function and use it, if that's what you 
>>> need.
>>
>> Yes it would be easier - to provide an ugly, half-assed solution that 
> 
> You and I are British - the term is "half-arsed" :-)

I'm catering for a wider readership.

(Actually I'm not quite considered British enough to be allowed in the 
upcoming election.)