OpenEuphoria

Re: Standard Euphoria Library project

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 25, 2005
• 592 views

I'm very sorry for the late reply. I just got too many e-mails lately ...

Christian Cuvier wrote:

>> Subject: Re: Standard Euphoria Library project
>>
>>
>> posted by: Jason Gade <jaygade at yahoo.com>
>>
>> Juergen Luethje wrote:

<snip>

> I'm still online, but was busy with more rewarding activities than
> administering a project in a vegetative state :p
>
> I just read Juergen's papers.
>
> * I agree with the coding guidelines.
> * As for documentation format, there should be a stabdard tool. D.
> Newhall appears to be releasing one soon, so that's no longer an issue.

As far as I understood, there seems to be agreement on this point. Fine.

> * We'll have to specify scopes more precisely. For instance, "math
> routines" could be a small or humongous (set of) .e. Will it deal with
> permutations?linear algebra?group theory?FP analysis?rational
> approximation?complex numbers?arbitrary size/precision? (could go on
> for pages)

Yes, I see.
I think we could have files say 'combinatorics.e', 'group_theory.e' etc.,
and for very basic standard functions such as abs() and ceil() a file
'math.e'. Or should we call that file say 'stdmath.e'?

> * The text only mentions modules that were written in other languages.
> Writers of some Eu libs already did this work for us. Again, let's
> consider preexisting Eu libs as acceptable modules. They may have to be
> rewritten anyway, if only to accommodate the goding guidelines.

I'm a little confused. You suggested yourself that we should look how
things are done in other languages (IIRC you mentioned C++).
You probably mean something different here?

> * There should be some formal emphasis on naming and order consistency
> for routine parameters, as I find this one of the most problematic issue
> when using another language. Cross-module consistency issues will
> necessarily arise, as complete independence is not possible nor to be
> wished (if only to avoid 57 abs() functions).

Interesting point.
One rather simple thing would be to follow the RDS rules again.
'x' for an object, 's' for a sequence, 'a' for an atom, 'i' for an
integer. But I assume you are thinking of more ...

Concerning the order of parameters, the pattern that is used by find()
and match() comes to my mind as an example:
The first parameter contains the stuff that should be searched for, the
second parameter contains the "main" sequence.
But how can we write down things like that as general guidelines?

> Just some thoughts, I may have some more ideas (initially mistyped
> oddeas) later.



Regards,
   Juergen