[fpc-devel] Macro Processing

[Martin]

On 17/05/2011 12:19, Joerg Schuelke wrote:
> Am Mon, 16 May 2011 15:35:24 +0100
> schrieb Martin<fpc at mfriebe.de>:
>
>> {$EXPAND ProcFoo(1)}
>> // the code in thr try finally block
>> {$EXPAND ProcFooEnd}
>>
>> I can see that happen very easy?
>> And there we are, Pascal would be down to where C is now.
> There is no answer for that, you know. But you can always decide not to
> accept any code inside rtl, packages,tools, whatever which contains
> macros. Easy. If it compiles with warning, back to sender.
1) The point is, one may not be able to reject it.
If I used a 3rd party package (open source) for a long time, heavily 
relaying on it. And the add it, and I need a bug fix, that requires me 
to update....

2) the example itself is beside the point.
All our examples are beside the point. Mine, yours, any

I think we can easily agree on the following:
1) It is possible to find examples that some people may want to use 
(never mind if alternatives exist)
2) It is always possible to find examples of (lack of a better word): 
"abuse"

As for 1, you made yourself a statement: It will be a few people only in 
some rare cases. I can try to find your emails.
As for 2, it is mostly there problem, so why bother? Except for if such 
code gets into the public domain, as described above

Any way, I feel neither of those 2 statements can be argued (with the 
hope of success). I think that can be concluded,  after about 85 mails, 
trying to find the ultimate example for either side, and no-one any 
closer to "proving their point"...

-----

Or at least they can not be argued, unless we answer this question:

Should the compiler protect people from doing potentially dangerous 
thinks (knowing this is never a 100% protection anyway)

C obviously doesn't give a damm what people do to themself.
Pascal is supposed to care about it?

If that care is wanted, then the bad examples may gain some importance....

------
To me that leaves one other remaining questions. But feel free to add 
other points...

Looking at it as a potential feature. How does one evaluate if a feature 
should be added.
After all adding features has always been a selective process. this is 
not new for this case....

1) Is there a need for this feature => We apparently have trouble to 
agree on this point. There may be a need for some
2) Does the cost/benefit equation work out

We need to define "need (for feature)", "cost" and "benefit" (benefit is 
somewhat coupled to need)

For you as an individual, there is a need, and the benefit is bigger 
than the cost.
For me as individual, it is the opposite.

To get a fairer measure we can (in my opinion) only base this on average 
values. If you take the entire community, and (in lack of better data 
take a guess how many people need it, how many may use it, and how many 
may be affected. And assume some averages based on this.

The definition of the terms below, are not solely meant for "macro 
feature" => they apply to every feature (past/future/accepted/rejected)
- every feature shares the same risks, and provides benefits, and for 
every feature this cost/benefit can be calculated

"need"
  => The amount of people that want this feature to be implemented (in 
this case feature means the extension from what it currently already is)
  => It should not matter "why" they want it (because we tried that 
discussionm without success), but only "if" they want it.

"cost"
=> side-effects of the feature
- This can be the above described undesired exposure to the use of the 
feature by others (in the case that use of the code of the other can not 
be avoided). Probably low risk.
- this can be any side effect it has on the compiler.  (all those are 
potential / the may or may not apply, the may pose a very small, or not 
so small risk...)
    Bugs intruduced (now or in future)
    Resource usage, memory, cpu time (potential slow down)
    Effects on future features / making it harder to add other features 
(which may be wanted by a bigger amount of people, provide greater benefits
    Maintenance cost of the code itself

"benefit"
- objective benefits: like the ability to write code that by some 
definition is better/cleaner
- subjective benefits: the ability for some individuals,to use the 
feature, for whatever perceived gain


As for the need/benefit => It is not known how many people would be 
affected.
But you said yourself several times, probably only a few, and only in 
few cases

As for cost, we do not know how many risks will actually turn into 
reality (so maintenance cost for example will exist). But if any risk 
happens to come true, it affects every one.

Based on this. The question is does the benefits really outweigh the cost ?