[eeps] New - EEP 44: Additional preprocessor directives

[Björn Gustavsson]

Seems that I will have to add some clarifications to the next
draft of the EEP.

On Tue, Oct 13, 2015 at 4:35 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> Questions:
>
> - How will OTP_RELEASE behave on releases custom-built, not from the
> standard OTP distribution?

The intention is that OTP_RELEASE should tell what the
minimum capabilities of the Erlang system are. So assuming
that OTP_RELEASE had existing in OTP 17, by testing the
release number you would have known that the map
syntax was supported. Similarly, if the release was 18,
maps with variable keys was supported.

>  I have always felt we are doing it wrong with these things when the  point
> is really to find the capacity required for some functionality.   OTP
> releases are just a shortcut for it, and mostly for transitions in  terms of
> compatibility.
>
> - the `-if' and `-elif' values themselves appear to be at risk of not
> working across versions (such as using is_map(...)).

As currently implemented, the programmer must take care
to only guard tests that are available in all targeted OTP
releases.

>  Will the error in such a case be a compile failure, or a guard  execution
> failure that leads to an inline check? I.e. if I want to  check for map
> support, should I:
>
>    -if is_map(false) orelse true.
>

If is_map/1 is not a supported guard BIF, there will
be a "badly formed 'if'" compilation error.

I might reconsider this decision. Perhaps calls to unknown
functions should be allowed, but generate an exception,
causing the clause to fail.

>  Which would, in a guard, raise an exception and fail both clauses if  it
> doesn't exist, and otherwise succeed, it just fails and I have to  just
> call:
>
>    -if is_exported(erlang, is_map, 1).
>
>  which would work anyway, but I'm interested in semantics there.

Yes, that will work.

> - is_module(Mod) is ambiguous. Does it require the module to be in the  path
> and compiled, loaded, or just as a source, to succeed? And where  in the
> path? The OTP root lib, ERL_LIBS, current path, or any  arguments passed to
> the compiler?  This can have somewhat important  impacts on build tools,
> again.

It must be compiled and in the code path. The code path is
defined using the usual mechanisms that you mentioned.

> - is_version(App) is wrong. The types in the App file are strings, and  can
> support a non-triple format. For example, anyone subscribing to  semver can
> run with version "1.0.0-x.7.z.92".
>
>  How is this being translated? Is it even translated at all, or  defaults to
> {0,0,0} ?

It will be translated to {1,0,0}.

>  I understand the triple is interesting for sorting purposes, but it
> excludes a bunch of schemes, and OTP's own old schemes (say  "R15B03-2")
> would not have been representable by this scheme.

Yes, being able to do a greater than or equal test
was the reason I chose this format.

Do you have any suggestion for how version should be
handled? Should version() always return a string? Should
we have different variants of version(), one that returns
a triple and one that returns the string?


>  It is also inconsistent with existing formats.
>
> - The EEP mentions that the compiler can currently skip things it  doesn't
> understand in the form of -if...-endif construction

Yes, it can skip -ifs that occur in the failing branch of
an -if...-else...-endif construction.

>  However, testing reveals that `-if' and `-error Expr' currently both  fail.
> This means that any backwards-compatible code is now forced to  do this
> implicit dance of
>
>  -ifndef(OTP_RELEASE). %% assume 18 or older, hope no app defines this
>  ...
>  -else. % we're okay
>  ...
>  -end.

Yes. I don't see any other way to support OTP 18 at all. Do you?

>  Also, choices such as:
>
>  -error("This is an error").
>
>  Would instead allow backwards-compatible definitions rather than one  that
> breaks.  It appears the forms for -if and -elif were already  reserved,
> though, and I can't think of a good way not to make this a  pain in the ass.
>

Having the parenthesis will in fact work, but the parenthesis
will be printed in the error message:

t.erl:4: -error ( "This is an error" ).

/Björn

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