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.
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
