Re: Changes in the ESL papers
On Fri, 22 Jul 2005 00:05:39 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
>I have recently "tweaked" the existing HTML files, and added several new
Looking good.
<snip>
> lowercase letter l,
At first I misread that. It should be "uppercase letter i or lowercase
letter L which can both be confused with 1."
>
>I still have (at least) the following questions:
>- With what Eu versions should the library be compatible?
If a function can provably take advantage of eg $, it should.
If timing tests indicate no difference, make it compatible with 2.4.
I personally still use 2.4 more than 2.5, so if necessary/possible I
would like a seqops24.e as well as the main seqops.e (assuming there
is some code difference), but I don't think backward compatibility is
a good reason to slow anyone down, nor do I think the library authors
should start worrying about a[i]+= etc which have since been fixed.
Maybe if there is a seqops24.e it would be "not officially supported".
>- Should the library have a global error handling function?
> If so, it would probably be the best to implement it for the
> first version.
A standard library should never offer user dialog (and as you said,
the standard library should not have any GUI components).
>- What shall functions return in case of an error?
I think that has to be a guideline at most. Failing to open (or copy)
a file might be an error in some applications, or just an indication
that it is time to create it in others. Where possible, I prefer to
use boolean values of 0 and 1 to indicate success or failure, but
there are many cases where that is not appropriate.
>- Should we have one file that contains (almost) all global types
> (I vote for this), or should the global types be included in the
> respective modules?
Decentralize where you can.
The complex type, for example, is probably only needed in/if you use
maths.e. If you can write maths.e such that it does not need to
include types.e, without duplicating anything, then you should.
Otoh, a boolean, is probably needed most places, so you need types.e
I don't think this is a particularly critical point, though.
>- Is it sufficient that 1 person checks whether the code meets the
> specification, or should that be double-checked by an additional
> person?
I think it is sufficient; one person writes the docs, code, and tests
suggested while writing the code (which should be kept!). A second
person reviews the docs and writes some more tests from that, then
reviews the code and where appropriate writes a few more tests.
I assume each routine will have a list, by date, of who has approved
it and any mods made, so it is clear if any mods have been made after
approval, plus where the test script can be found?
Regards,
Pete
|
Not Categorized, Please Help
|
|
