Deutsch   English   Français   Italiano  
<v3mtf2$ct28$2@dont-email.me>

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

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 12:23:15 +0100
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <v3mtf2$ct28$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 04 Jun 2024 13:23:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="027492d54fa7a72a30fd705d730c9473";
	logging-data="422984"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/MQjquCWRAEw1iKr/bmrv/"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:uI8//FtxNuYuDErYME6kvPLQDxY=
Content-Language: en-GB
In-Reply-To: <v3ms7b$d5sq$1@dont-email.me>
Bytes: 4645

On 04/06/2024 12:02, David Brown wrote:
> On 04/06/2024 11:13, Mikko wrote:
>> On 2024-06-04 08:58:53 +0000, David Brown said:
>>
>>> On 04/06/2024 09:14, Lawrence D'Oliveiro wrote:
>>>> Would it break backward compatibility for C to add a feature like this
>>>> from Python? Namely, the ability to check if a value lies in an 
>>>> interval:
>>>>
>>>> def valid_char(c) :
>>>> "is integer c the code for a valid Unicode character." \
>>>> " This excludes surrogates."
>>>> return \
>>>> (
>>>> 0 <= c <= 0x10FFFF
>>>> and
>>>> not (0xD800 <= c < 0xE000)
>>>> )
>>>> #end valid_char
>>>
>>> Do you mean, could C treat "a <= x <= b" as "(a <= x) && (x <= b)" 
>>> without breaking existing code?  The answer is no, C treats it as the 
>>> expression "(a <= x) <= b".  So you would be changing the meaning of 
>>> existing C code.  I think it's fair to say there is likely to be very 
>>> little existing correct and working C code that relies on the current 
>>> interpretation of such expressions, but the possibility is enough to 
>>> rule out such a change ever happening in C.  (And it would also 
>>> complicate the grammar a fair bit.)
>>>
>>>
>>> <https://c-faq.com/expr/transitivity.html>
>>
>> That does not prevet from doing the same with a different syntax.
>> The main difference is that in the current C syntax that cannot be
>> said without mentioning c twice. In the example program C would
>> require that c is mentioned four times but the shown Python code
>> only needs it mentioned twice. An ideal syntax woult only mention
>> it once, perhaps
>>
>>   return c in 0 .. 0xD7FF, 0xE000 .. 0x10FFFF ;
>>
>> or
>>
>>   return c : [0 .. 0xD800), [0xE000 .. 0x10FFFF] ;
>>
>> or something like that, preferably so that no new reserved word is
>> needed.
>>
> 
> Sure, you can always add new things to a language if they would 
> previously have been syntax errors or constraint errors.  But is there a 
> use for it?
> 
> 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.

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

It is incredibly useful:

    if c in [' ', '\t', '\n'] then ... # whitespace
    if b in 0..255 then
    if b in u8.bounds then             # alternative

Not to forget:

    if x = y = 0 then                  # both x and y are zero

It doesn't need the full spec of the higher level language.

> 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 
everyone will write a different way (I would use (x, a, b) for example),
and which can go wrong as soon as someone writes (a, x(), b).

That's the problem with the macro scheme, it stops the language properly 
evolving.