Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Thu, 7 Nov 2024 17:51:09 +0000
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <vgiumc$2o9mn$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg0t3j$2ruor$1@dont-email.me>
 <78eabb4054783e30968ae5ffafd6b4ff2e5a5f17@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> <vg8a84$euka$1@dont-email.me>
 <vg8koq$gpsg$1@dont-email.me> <vgat50$112jp$1@dont-email.me>
 <vgb8if$13ioj$1@dont-email.me> <vgbhkt$155v2$1@dont-email.me>
 <vgfv5l$25hs6$1@dont-email.me> <vgg337$26880$1@dont-email.me>
 <vgggj2$28fqj$1@dont-email.me> <vgipiq$2nji2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 07 Nov 2024 18:51:09 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ec686777c96cc376bc9818100d47f072";
	logging-data="2893527"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18i/nHgycVYWGp49EyvzfZr"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:UCsJfo1LhxK805RaClG72xcRD8k=
Content-Language: en-GB
In-Reply-To: <vgipiq$2nji2$1@dont-email.me>
Bytes: 4317

On 07/11/2024 16:23, David Brown wrote:
> On 06/11/2024 20:38, Bart wrote:

[Functions vs. procedures]

>>    void F();
>>    void (*G);
>>    void *H();
>>    void (*I)();
>>
>> OK, 4 things declared here. Are they procedures, functions, variables, 
>> or pointers to functions? (I avoided using a typedef in place of 
>> 'void' to make things easier.)
>>
>> I /think/ they are as follows: procedure, pointer variable, function 
>> (returning void*), and pointer to a procedure. But I had to work at 
>> it, even though the examples are very simple.
>>
>> I don't know about you, but I prefer syntax like this:
>>
>>     proc F
>>     ref void G
>>     ref proc H
>>     func I -> ref void

(The last two might be wrong interpretations of the C. I've stared at 
the C code for a minute and I'm still not sure.

If I put it through my C compiler and examine the ST listing, it seems I 
I'd just swapped the last two:

    func H -> ref void
    ref proc I

But you shouldn't need to employ a tool to figure out if a declaration 
is even a function, let alone whether it is also a procedure. That 
syntax is not fit for purpose. This is a HLL, so let's have some some HL 
syntax, not gobbledygook.)

> It is not the use of a keyword for functions that I disagree with, nor 
> am I arguing for C's syntax or against your use of "ref" or ordering.  I 
> simply don't think there is much to be gained by using "proc F" instead 
> of "func F -> void" (assuming that's the right syntax) - or just "func F".
> 
> But I think there is quite a bit to be gained if the func/proc 
> distinction told us something useful and new, rather than just the 
> existence or lack of a return type.

I use the same syntax for my dynamic language where type annotations are 
not used, including indicating a return type for a function. That means 
that without distinct keywords here:

   func F =
   end

   proc G =
   end

I can't tell whether each a returns value or not. So 'func'/'proc' is 
useful to me, to readers, and makes it possible to detect errors and 
omissions:

-  'return' without a value in functions
-  'return x' used in procedures
-  A missing return or missing return value in functions (since this
    is also expression-based and the "return" keyword is optional in the
    last statement/expression)
-  A missing 'else' clause of multi-way constructs within functions
-  Trying to use the value of a function call when that is not a
    function.