[erlang-questions] some language changes

[David Hopwood]

ok wrote:
> On 31 May 2007, at 1:51 am, Mats Cronqvist wrote:
> [1. simplify the language]
> [2. replace the preprocessor]
> 
>> conditional compilation should (i think) be
>>disallowed (rarely used and utterly horrible).
> 
> I have been saying "Delenda est preprocessor!" since it came out.
> I note, however, that there are 518 "-if[n]def(...)." occurrences
> in the R11B sources.
> 
> Quite a lot of those are protection against multiple includes:
> 	%% thingy_whatsit_gubbins.hrl
> 	-ifndef(THINGY_WHATSIT_GUBBINS_HRL).
> 	-define(THINGY_WHATSIT_GUBBINS_HRL, true).
> 	...
> 	-endif.
> To my astonishment, some of the files that do this contain nothing else!
> The answer is simple:  they are produced by some kind of tool that
> emits -record declarations, and for these files there happened to be
> none.  Some use a _HRL suffix; some use a -MIB suffix.
> 
> This usage accounts for 165 (32%) of the -ifs.  Either of two changes
> would eliminate them entirely.
> 
> (a) -require(File_Name).
>      would resolve the File_Name just like -include(File_Name),
>      then check a list of included files.  If the file was in that
>      last, -require would do nothing, otherwise it would act just
>      like -include.  -include (and thus -require) would add the
>      resolved file name to the list.

I bet that for essentially all current uses of -include, it is the semantics
of -require that is wanted. Including a file twice is only useful if
you're relying on macros being defined differently between the two includes,
which is precisely the sort of abuse of the preprocessor that we would like
to get rid of.

So my suggestion would be to change -include to work as -require is described
above. Although this is technically an incompatible change, it's very unlikely
that any code that was relying on multiple includes of the same file would
still compile -- so it is not a silent incompatibility.

-- 
David Hopwood <david.hopwood@REDACTED>