Anselm R Garbe wrote:
I don't miss closures. You got the static keyword to avoid polluting
the global namespace.
Kind regards,
Anselm
U think it may be genetic? :)
Byzantine libraries, rich class hierarchies, clever closures, maybe are
for members of the species /programmator domesticus/.
Then the suckless prescription is aimed at members of the species
/programmator ferox/.
John, I've read your other articles in Dobb's and it seems
that you've been interested in Forth. Remember then that Forth has a
feature
quite close to closures in the words CREATE and DOES>. It is often
mistaken for
a primitive form of objects, BTW.
It seems that you're interested in radical, sharp, simple approaches to
software
and your interest in Forth because of that wasn't a mistake. Forth
programmers are
generally pretty quick at pruning what's not needed and gives no returns
for the
extra complexity. And still, they keep this CREATE DOES> feature.
It seems to me that you filed closures in the "non-suckless" category a
bit quickly.
For a start, they are just a language feature. OO is a paradigm. That's a
big
difference in nature.
Furthermore, they are not on the same scale of complexity as OO. Their
inner working might
be complex, but their external behavior is quite simple. What would you
expect from:
void (*f)(void) foo(Int x)
{
int b=10*x;
void bar()
{
printf("%d",b);
}
return bar;
}
foo(3)(); /* should obviously print 30 */
So I think that they really are out of place in your "Byzantine libraries,
rich class hierarchies"
category.
I believe that closures could improve dwm for instance. Anselm says that
he doesn't miss them, but it seems to me that he used a lot of tricks to
replace
them.
For instance, the Monitor struct packs all of the fields that a layout
function may need.
The Arg union allow to pass an argument to various functions that needs
various types of
constant parameters. Maybe in the next evolution, where the symbol of the
layout will be given by
a function pointer, one may expect some similar tricks.
This is typically what one has to do without closures. One may accommodate
this in such
a small program, after all - but one has already bypassed the type checker
(union) and paid
a few bytes for this (kitchen sink structure) in a little 2K SLOC program.
I'm not sure one can live with
it in 10 KSLOC programs (or making it bearable helps in reaching faster
the 10KSLOC).
Anonymous functions alone - not even full-blown closures - could replace
the function pointer/argument pair in the Key structure. With closures,
one can
create layout functions that carry with them their own data. No need to
put everything in
one big Monitor structure.
I'm pretty sure that if C featured closures, Anselm would cleverly use
them and
make an even more simple, customizable and elegant dwm.
