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

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

Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Tue, 5 Nov 2024 17:02:04 +0100
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <vgdfhs$1jefc$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg2g37$37mh3$1@dont-email.me> <6724CFD2.4030607@grunge.pl>
 <vg2llt$38ons$1@dont-email.me>
 <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org>
 <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org>
 <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me>
 <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me> <vgd3ro$2pvl4$1@paganini.bofh.team>
 <vgdc4q$1ikja$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 05 Nov 2024 17:02:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="57a2613ac94f24808de446d87ca9a407";
	logging-data="1685996"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18KDD3gPKdjnUPMIiA3ws6veJSlJYGpWGE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:5vTlILrecM/lLXGb8FyKDh+3nNM=
In-Reply-To: <vgdc4q$1ikja$1@dont-email.me>
Content-Language: en-GB
Bytes: 3325

On 05/11/2024 16:03, Bart wrote:
> On 05/11/2024 12:42, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>>
>>> Then we disagree on what 'multi-way' select might mean. I think it means
>>> branching, even if notionally, on one-of-N possible code paths.
>>
>> OK.
>>> The whole construct may or may not return a value. If it does, then one
>>> of the N paths must be a default path.
>>
>>
>> You need to cover all input values.  This is possible when there
>> is reasonably small number of possibilities.  For example, switch on
>> char variable which covers all possible values does not need default
>> path.  Default is needed only when number of possibilities is too
>> large to explicitely give all of them.  And some languages allow
>> ranges, so that you may be able to cover all values with small
>> number of ranges.
>>
> 
> What's easier to implement in a language: to have a conditional need for 
> an 'else' branch, which is dependent on the compiler performing some 
> arbitrarily complex levels of analysis on some arbitrarily complex set 
> of expressions...
> 
> ...or to just always require 'else', with a dummy value if necessary?

If this was a discussion on learning about compiler design for newbies, 
that might be a relevant point.  Otherwise, what is easier to implement 
in a language tool is completely irrelevant to what is good in a language.

A language should try to support things that are good for the 
/programmer/, not the compiler.  But it does have to limited by what is 
practically possible for a compiler.  A fair bit of the weaknesses of C 
as a language can be attributed to the limitations of compilers from its 
early days, and thereafter existing practice was hard to change.