Deutsch   English   Français   Italiano  
<v3nch6$frn1$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Tue, 4 Jun 2024 17:40:22 +0200
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <v3nch6$frn1$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>
 <v3n7ko$evip$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 17:40:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7740955b17fd8df0cccaba227b9e3b39";
	logging-data="519905"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+GW6ujs+GM68H2Dlui+Qbl/senDIK3MGI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:P9dj18RJBVjCTTKN/BrCRLUj25k=
Content-Language: en-GB
In-Reply-To: <v3n7ko$evip$1@dont-email.me>
Bytes: 5396

On 04/06/2024 16:16, bart wrote:
> 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.
> 

It might be that we would agree on that if we worked hard enough to find 
a common definition for "that level of language".  But I think that 
would be a lot of time and effort for little purpose.  I do agree that 
with enough limitation in the scope of the feature, it is less 
unreasonable for a low-level language.  But I think I would want to 
limit the scope until there is little point in the "in" operator - or I 
would want to go the other direction and define something like Pascal's 
sets with many more operators and uses.

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

Yes.

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

I see your point, but I rate the design and use of a language as /much/ 
more important than the ease of implementation.  I realise the balance 
is a bit different when the user is the implementer.

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

We can educate them!

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

I can't vote either, but that's because I don't live in the UK.  And 
given the state of UK politics these days, I'm happy to be out of it. 
For quite a while, the Scottish Parliament were looking like the adults 
in the room, but they've managed to mess things up for themselves too.