Erlang/OTP R10B-10 has been released

[David Hopwood]

Richard A. O'Keefe wrote:
> Let's add a "feature" pseudo-function (strictly speaking it should be
> an abstract pattern, but here I am not assuming abstract patterns)
> with one argument which must at compile time be an atom; its values
> are limited to numbers, atoms, and strings.  Compiled using erlc,
> we might have -D<feature>=<value>, ....  Compiled using a function
> call, we might pass the features through the options list somehow.
> 
[...]
> We cannot make a choice between alternatives some of which our
> compiler can read and some of which it can't.  (Lisp systems processing
> #+ and #- have to be careful not to try to convert things that look like
> numbers into numeric form, because the point of conditionalising might
> be to choose between 80-bit numbers and 64-bit numbers, and a 64-bit
> system shouldn't do anything with the 80-bit numbers.)
> 
> We cannot conditionally export things.  For that we would need new
> syntax,
> 
>     -export([...]) when <guard>.
> 
> We cannot make the *existence* of a function conditional, but that's
> as it should be.  If a function is called or exported, it should exist.
> If it is not called and not exported, then dead code elimination should
> get rid of it anyway.

My experience (mainly in C, but not specific to C) is that this is not
sufficient in practice. For example, in a recent embedded system, I have:

#define ENABLE_CONTROL            1
#define ENABLE_HEATER             0
#define ENABLE_HEATER_ALARM       0
#define ENABLE_UV                 1
#define ENABLE_ANTISTATIC         1

and so on, for ~89 features.

This does not mean that there are 2^89 combinations of features that need
to be tested. The final program is going to have *all* remaining features
enabled, after any that don't work or are redundant have been stripped out.
A test with some features disabled is only intended to be a partial test.

There are two main reasons to disable a feature:

 - because it doesn't work. Sometimes this is because the associated
   hardware doesn't work yet, and sometimes the code doesn't compile or has
   known bugs that would interfere with testing the rest of the system.

 - because we want to replace it with a mock/stub implementation for testing
   on a development system rather than on the actual hardware. In some cases the
   code would not compile on the development system because a needed library
   is not implemented there.

Note that as well as stubbing out the code that implements it, disabling a
feature sometimes needs to change code that would use that feature in other
modules.

While I like the general idea of feature pseudo-functions, I think that to be
useful as a tool for testing parts of programs during development (which is
the main thing I use conditional compilation for), there must be support for
excluding code that doesn't compile.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>