Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: C vs Haskell for XML parsing Date: Mon, 28 Aug 2023 16:49:21 -0700 Organization: A noiseless patient Spider Lines: 68 Message-ID: <861qfmwwvy.fsf@linuxsc.com> References: <576801fa-2842-40dc-bf19-221a5b1cf660n@googlegroups.com> <639e8e6f-2729-476b-9a6e-0b3eb066b06an@googlegroups.com> <878r9zeynn.fsf@nosuchdomain.example.com> <20230826123929.770@kylheku.com> <20230826210521.20@kylheku.com> <20230827151627.814@kylheku.com> <87edjocbqj.fsf@nosuchdomain.example.com> <86edjnxo81.fsf@linuxsc.com> <87ledubyeh.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="1084eb5dd0b1a11121af7ba127734067"; logging-data="2018636"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/lz3fPuE2LrIe+gN/6i42rOe8XP4f7yvs=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:WiUeEBuL2qUFtLVMFOtDlYmWGYA= sha1:IKQOI7t2pyp7RMrc43aTM0OVlmc= Xref: csiph.com comp.lang.c:173127 Keith Thompson writes: > Tim Rentsch writes: > >> Keith Thompson writes: >> >>> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >> [named function arguments] >> >>>> The only way this can be sanely introduced into C with backward >>>> compatibility is if there is a separate way to introduce the >>>> parameter names used for named calling, like this: >>>> >>>> char *strcpy(const char * : dest, char * : src); >>> >>> Why not just declare >>> char *strcpy(const char *dest, char *src); >>> and use those names in calls, with a few simple rules for when there's >>> more than one visible declaration? >> >> I favor a different approach to this problem: >> >> static inline char * >> copy_to_from( char *to, const char *from ){ >> return strcpy( to, from ); >> } >> >> with no language changes needed. And people are still free to >> use the more concise form if they so desire. > > But if we change the names used in the standard for strcpy's parameters, Part of the point of my approach is that it doesn't need any changes to the C standard. > there's no need for a wrapper function (with, in your approach, a name > that doesn't suggest that it operates on strings). That's incidental. It could be copy_string_to_from(); > Your wrapper would be useful only if the language added named arguments, > yes? Not at all, that's the point. The function name indicates where the destination (to) and source (from) arguments go. There is no reason a declaration has to use those names, or any names at all, for the function parameters. All the information needed is present in the name of the function. > I'd expect that an edition of the standard that added named > arguments would also rework the argument names in the standard library. Part of the advantage of the approach I favor is it doesn't need to wait for a new edition of the C standard. I think there are lots of cases where simply adopting a coding style obviates any need for new language features. > Even without named arguments, I don't think "s1" and "s2" the best > choices for parameters of strcpy(). They're consistent with strcmp(), > but they don't need to be. It makes no semantic difference, but IMHO > the description would be a little clearer with more meaningful names. In the context of the C standard, and especially for strcpy(), I don't see anything wrong with s1 and s2. Moreover using s1 and s2 means there won't be any bike-shedding arguments about what the names should be.