[eeps] New - EEP 44: Additional preprocessor directives

[Richard A. O'Keefe]

(1) One parenthesis: "(".
    Two parentheses: "()".
    (Just like crisis/crises, thesis/theses, basis/bases, arsis/arses.)

(2) I am forcibly struck by how much we are influenced by
    other programming languages, in this case C.  For example,
    Unisys PLUS has conditional compilation, but it uses

	INCLUDE(condition);
	...
	RESUME;

    and

        COPY('other*source.file');

(3) A central weirdness in the preprocessor remains.
    It is sort of coupled to Erlang syntax, but in a bad (limiting) way.
    This proposal does nothing to address the limitation that you
    cannot conditionally accept *some* of the clauses of a function,
    only the whole thing; nor can you conditionally accept *some* of
    the alternatives of a type, only the whole type.
    This is precisely one of the things the preprocessor gets used for
    in Haskell.  For example, one change coming up is

    class Applicative m => Module m where
        (>>=)  :: m a -> (a -> m b) -> m b
        (>>)   :: ma -> m b -> m b
        p >> q = p >>= \_ -> q
        fail   :: String -> m a
        fail s = error s

    # if VERSION < TBD
        return :: a -> m a
        return = pure             {- it's a default -}
    # else
    return = pure                 {- you can't override it -}
    # endif

    where the point is that 'return' used to be a part of Monad
    that you would define, but then Monad was made a subclass of
    Applicative, so return = pure (lifting a value of type a to
    a value of type m a) was made a default, but you could still
    override it, but that means that pure and return could be
    redefined to be *different*, which is a bad idea, so they'll
    be moving 'return' out.  Nobody would want to make two copies
    of the whole thing just because one *part* is changing.

(4) I'm still very concerned about the *context* in which the
    argument of -if is evaluated.  The Java modules proposal is
    putting a lot of effort into trying to make sure that
    compile time decisions based on the visibility of modules
    either remain valid at load time or produce error messages.

    This suggests that -if and its relatives should leave some
    sort of trace in the .beam file about what properties of the
    compile-time context they depended on.  (Anyone remember
    "dependency-directed backtracking"?  AMORD?)

    I have used a system where the compile time and load time
    environments could disagree *without notice* and never want
    to have that experience again.

    Of course this is not an issue for the C preprocessor,
    amongst other reasons because the C preprocessor is very
    explicitly independent of the run time environment, to the
    point of not necessarily using the same arithmetic.
    
    Again I find myself wondering whether imitating the
    *syntax* of CPP if we don't copy the *semantics* is a good idea.

(5) Existing homebrew pretty-printers/formatters for Erlang are
    likely to cope with -if(...) as just another attribute,
    which of course it isn't.  Allowing -if ... will force some
    changes.  (Hint: I have an Erlang reformatter that will
    probably need patching.  I'm not sharing the code because it
    is not *worth* sharing, but I get some use out of it.)