Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart 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: References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> <78eabb4054783e30968ae5ffafd6b4ff2e5a5f17@i2pn2.org> <6724CFD2.4030607@grunge.pl> <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org> 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: 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.