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.