Re: Unnamed functions, functors or, more formally, function literals

[Bo Thorsen <bo at sonofthor dot dk>]

I CC'ed gcc ml again, forgot that in my reply. Sorry.

On Friday 15 March 2002 15:38, Paul V. Andreev wrote:
> On Fri, 15 Mar 2002, Bo Thorsen wrote:
> > > Of course, my example is too artificial. Now imagine a call to qsort is
> > > nested deep inside some function. You have to define compare_strings at
> > > top level, but use it somewhere deep inside some other function.
> > > That is, usage is distantiated from  definition, that may be too far
> > > for big containing functions, which worsens readability.
> > >
> > > But it mostly aids maintainability. To define and to use a function,
> > > that is used only once, you would want to do it in one place.
> >
> > This is a style issue, not something you get to decide if it's good or
> > not. There are reasons for and against this argument.
>
> Really? Is this only style issue?
> Is convenience of programming good or not?
> Is better maintainability good or not?
> Is readability good or not?
> Is predictability and consistence with other language constructs good or
> not?
>
> Let me show you on our qsort example.
>
> You are writing some function. In the process of writing you come up with
> a need to call qsort to sort your data. Now you need a function pointer to
> pass to qsort. Here you must go up your source file, find a place where
> file scope function may be defined, select some appropriate function name,
> desirably qualify it as static, define it's body. Then descend back and
> find a place where you were at. Stop.
>
> Now imagine that you have dramatically decreased complexity of your
> algorithm and no more have the necessity to sort your data. Usage of this
> function disappeared, the function itself must disappear too (if not, C
> compiler will warn you about unused static function). Now redo actions
> from above and remove the definition.
>
> After all, in a big source, you come up to having some main functions
> and many helper functions, all trying to catch your eye. You would lye to
> me if wouldn't agree that helper functions should be modularised
> (incapsulated) into functions which use them, i.e. their scope should
> not be wider than really necessary.
>
> That is much about Ada or Pascal that bother with implementing
> displays/chains. In C we have to live with what we have, but we employ
> a different concept here. Functions that are shareable have names
> which reside is global namespace, others may be unnamed and appear only
> where they are needed.
>
> This is different but very consistent concept, which is compatible with
> what we see from C99. Just recall compound literals for arrays and
> structs. The same we have for strings from long time ago. With function
> literals we would complete the set of literals in C language. This would
> be more consistent and predictable language.

Maybe I should have clarified my meaning here since there are two arguments 
in this. First of all, wether or not to make a function nested or global is 
indeed a matter of style. You do not at all take into account that some other 
usage might come up for your nested function. If that happens, you need to 
change your implementation to be a real function anyway. This isn't a 
problem, if it's your own source, but can be a huge problem in someone elses 
code. Free software only goes so far to remedy this problem, since I have 
crossed paths with way too many maintainers of various packages that simply 
didn't care about patches that fixed a problem they didn't have themselves 
(like my x86-64 patches to bzip and others going into some black hole). 
That's what I mean when I say that the decision to go with a nested function 
or a real global one is a matter of style. It obviously also depends on the 
context etc.

The next issue in this is my point that extending a language with a feature 
to make some coding style more maintainable isn't a matter to be taken 
lightly. Every time you add something to a language, you clutter up the 
grammar even more than it was before. Designing a language is all about 
making decisions about when the feature is worth cluttering up the grammar 
even more.

Take as two examples C++ and Java. Java is the small language approach where 
you're supposed to put stuff in libraries instead of in the language. That 
gives a reasonably small and clean grammar. (I know there are a lot of others 
much smaller languages than Java, but I picked one that gcc implements.) The 
other approach is C++ where Bjarne Stroustrup has always had the philosophy 
that "if it wasn't incompatible with the current language, a new feature 
wanted by users should go into the language since it wasn't up to him to 
decide what is good". This approach gives a huge language with very fine 
grained control. Take your pick on which you want, but don't come saying one 
is better than the other.

Given your argument that functors would enhance code maintainability, C++ 
code should be much more maintainable than Java code simply because you have 
a lot of these programming short cuts in the language. I don't believe this 
to be universally true.

> > > Do you create "compare" functions for all seasons of life in your
> > > global namespace? Now imagine you have to create a function to be used
> > > only once. You have to create a distinguishing name, that don't clash
> > > other names.
> >
> > Now you're giving real reasons. This is a good argument. But convince the
> > C committee, not gcc people.
>
> Well, but what to call a standard of a language? I know several companies
> that write code only for GCC, so they have a GNU C standard and are happy
> with that fact. Some features that appeared in C99 are adopted from GCC.
> Some features which GCC support distinguish the compiler from many others
> and make it a compiler of choice. As I said in my first post the feature
> affect in no way existent programs and is rather easy to implement in GCC.
> It will be a mistake to abandon wishes of GCC users (whom, however, as I
> see from your replies, are not as many as I expected).

I absolutely despise extensions to standards, unless they really pay off. 
Locking people in with extensions is a horrible idea, no matter if it's done 
with MS Word files or C source code. And suppose that GCC were to implement 
your idea and then C 2003 (or whatever) implements a slightly incompatible 
standard way to do this, then it means problems in the transition code. Check 
the mailing list archives for more examples of this problem than GCC gurus 
want to think about.

> > > 1) People need this feature, so it will appear soon or later.
> >
> > Wrong again. Cramming features into a language doesn't make it better.
> > People have lived nicely without this feature for many years and continue
> > to do so. Note that this doesn't mean that I necessarily disagree with
> > you, I just won't accept that you claim that there's a *need* for the
> > feature.
>
> I agree that what this phrase states doesn't correspond to real state of
> things. Please read this as "Some people need this feature, they will
> not die without it, but they can't be happy without it".
>
> After all, there are many extensions which GCC support, but which do not
> even pretend to be as fundamental as function literals.

Yes, but GCC has been making more of these obsolete with every release. There 
seem to be a strong current towards less extensions and more standard 
compliance. This gets easier to do as the languages evolves and there are few 
things you can do in GCC that isn't in some form in C99 (pascal style nested 
functions are one exception).

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark