[erlang-questions] Fourth draft of EEP 44 - Additional preprocessor directives

[Björn Gustavsson]

On Mon, Nov 2, 2015 at 4:13 AM, Richard A. O'Keefe <ok@REDACTED> wrote:
[...]
> In fact this proposal *still* does not give us a way to
> skip one or more clauses that *would* be syntactically
> incorrect in some context.
>
> There is a very simple change to Erlang that would make
> this possible:  allow '.' between function clauses as
> well as ';'.
>
> That would also enable us to paste a function together
> out of pieces held in separate files:
>
> % Define f/3
> -include("old_f.hrl").
> -include("new_f.hrl").
>

That change to the language should be described
in a separate EEP. It can be implemented independently
of any changes to the preprocessor.

[...]
> I do accept that 'supported' is something that can well be
> added in a later EEP, and I would not take the clunkiness
> of OTP_RELEASE as a show-stopper.  But the documentation
> should insist that anyone using OTP_RELEASE write an
> explicit comment clearly stating what they are really
> testing for.

Yes, I think supported/1 is sufficiently complex that
it will need its own EEP.

I have not written any user documentation for any
of the features in this EEP. Obviously the user
documentation should contain disclaimers and
warnings about the traps and pitfalls of the
preprocessor, and examples of best practices
when you have no other choice than to use
the preprocessor.

[...]
> There is a way to test if a *header* exists (is_header/1),
> which looks in the header search path.
> There is a way to test if a (compiled) *module* exists
> (is_module/1), which looks in the module search path.
> I am convinced that these are good ideas.  If only C had them!
>
> But there is no way to test if a *data file* exists.

Do you have a concrete use case? I have
tried to find real-world use cases for all
built-in 'if' functions and avoided to add functions
that are just "nice to have".

/Björn

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB