EEPEP

[Michael P.]

:-)

Can we shape this into something useful? or pluck out some things to shape others?

Some things may appear apparent. They are meant to activate passive knowledge. When asked about such, it does not evoke a feeling of 'Oh! I forgot.', but rather of 'Yeah! I know! Who do you think you are?' But passive knowledge (however obvious) does not affect action until reactivated.

My Hugin and Munin may roam quite clear a sky -- some might call it a bit too empty to steal people's time -- but I still have both my eyes. Today's omniscience is its own subset tomorrow. Odin may well be regretting his choice ....

The EEP description and EEP 33 try to put you on some rails, so this here might all sound a bit sermony as well, but:

    There are two kinds of things that are the way they are:
    Firstly those that simply are the way they are, like water being wet;
    secondly those that are being done or made the way they are.
    Those of the second kind are not the way they are.

    ~Michael


----8<----8<----eepep.md

Erlang Enhancement Process Enhancement Proposal^{*1}
=====================================================

Approach
---------

### 1) What's the problem?!
Without grabbing and holding this fast by its most private parts ....

EEPs are based on a template, thus, unfortunately they appear already quite formal. Ask for opinions and the heat is on ...

Now, so as not to clutter the EEP list, one could set up a PEEP --show-- list, for Preliminary EEPs. I have a feeling that such would be overkill, the mailing list might suffice ....

#### How did the problem come into being?
What change made the situation so bad, that it might need to be changed?
What was the reasoning behind that pre-problem and its solution?

### 2) What could be done about what causes the problem?
Why keep everyone and yourself busy mopping up the blood when you keep shooting yourself in your walking appendages?

Such can trash an EEP and require one to start again on 1) ... I think this should be clear before things turn into an EEP ....

### 3) Evolution, the solution or the certainty?
Being stuck holding the problem by ... What possible solutions can we come up with?

Currently, EEPs start about here, and might skip or miss some or all of the previous points.^{*2} In a discussion it might catch up on this, and end up rejected. But even if all that was recorded in it for future reference, it would contain different important things under a very narrow and somehow wrong heading.


Solution 1
------------

### Impact exclusion

All "areas" of Erlang should be covered here, however absurd. Making someone claim in writing even no more than 'Not affected.' causes second thoughts, and there is a claim others may challenge.

So nothing gets overlooked. There may be some safety in numbers, but what about next year? tomorrow? Record it! And having to write even "Not affected." makes ppl double-check.

Normally it is "claim first -- explain first". Should you claim something, consider me claiming the opposite, simply electromagically. Now explain!

Well, in a perfect world ... (go ask Costner ...). This list might become unpractically long?

#### Header files `.hrl`(?)
#### The `-record` mechanism
#### `-spec`
#### `-type`
#### Macroes (-define(...).)
#### -behavio(u)r
#### Match operator `=`
#### Scope
Module-level functions, fun, case, if, ...?
#### Nesting
Or somehow ...
#### Shadowing
#### Sneak-exports from case patterns
#### Limited pseudo-fun-literals: ets:fun2ms(...)
#### The confusingly named "match specs"
#### You name it ...

#### Possible consequences

One thing will often lead to another ...


Solution 2
-----------

Add a section like "Solution 1" to EEP 33? But the other steps should then be realised outside and "before" the EEP. At this time EEPs are similar to such a "solution". The required alternatives are belittled by the main title, though they may even be better. Such an EEP can be rejected and that alternative extracted into a new one. But then it is somehow two for one ...


Solution N
-----------

   ...


First directives
------------------

1) Never change a running system.
1) If in doubt -- leave it out.
1) The more people contribute to a project, the more its result approaches mediocrity.
1) Money's short / And time is tight
1) Watch your tongue!

The tongue one is for snappiness, and needs to be explained:
Many is the times that I have found bad phrasing to be a kind of "code smell". Do not take lightly things such as using one word for two things, or giving two names to one, or apparently contradictory phrasings. Though, of course, always "Everyone else knows what is meant."^{\trademark}


Opinion polls
--------------

When I have an opinion and I, or someone, gives me a reason: I dump it.
When I find a better reason, I change it.
When I find an even better reason, I invert it.
When I find one of more import, I revert it.
And when ... I dump it.
And when things change, they tend to, why not get it back?
And when I have an opinion ...

Even respecting that, everyone has an opinion on everything, resulting in a lot of data with little information. Should the EEP (which? guess.) intend to follow the PEP in this ... I do not get the PEP opinion polls (see?! see?! that was "o. p.", and I wondered what that would mean): +0/-0? Having no reason, the first directives rule: so it is at least -1. Now one might want [+2|+1|-1|-2], same number of symbols, double the meaning.


### Ask for specific effects and uses

There will be much less noise. More concise statements, that can more easily be extracted and gathered. Require at least one example for each, it is easier to understand than a general claim. Provide a list of critcal questions, show some reflection, and respect: when there are no questions, why bother to ask for opinion?

Be specific in describing uses (problem, solution) and effects, but try to be general as to implementation. The concept of a new operator (or annotation, etc.) does not depend on a later to be discussed representation. Try to not pour your preference in everyone's virgin mind.

This will not always (rarely?) be practical.

Then again, everything in here may be ignored, for a good reason ... possibly.


---------------

*1 See?! see?! Had it been EEPc and EEPp, or EEproc and EEprop, or EEProc and EEProp, it would be easier to read. Call them names! them things; different things -- different names.

*2 I do not think I will ever be able to put two spaces after a full stop. When I wanted holes in my text I would use something with a full metal-jacket. Leave you me that bit of childishness, will you?


----8<----8<----