[eeps] New - EEP 44: Additional preprocessor directives

[Fred Hebert]

On 10/13, Raimo Niskanen wrote:
>New - EEP 44: Additional preprocessor directives
>
>    http://www.erlang.org/eeps/eep-0044.html
>    https://github.com/erlang/eep/blob/master/eeps/eep-0044.md
>

Questions:

- How will OTP_RELEASE behave on releases custom-built, not from the 
  standard OTP distribution?

  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(...)).

  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.

  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.

- 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.

- 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} ?

  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.

  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

  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.

  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.


Regards,
Fred.