OpenEuphoria

Re: Standard Euphoria Library project

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

Christian Cuvier wrote:

>> From: "Juergen Luethje"

<snip>

>> 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'?
>
> math.e should be enough.

I also think so.

> I sent complex.e to you privately as a test
> (I'll had a few things and take into account your remarks berofre
> actually releasing it).

I hope I'll be ready to send you my comments this evening.

>>>> * 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?
>
> I had understood your idea as "to find some consistent exemaples of
> module contents, let's look at other established languafes". That's good.
> My point is that some Eu coders already did this. Let's examine their
> work also so as to determine the modules' contents, since they already
> waded into the interfaces of Ruby, Java, C# and others we don't know or
> master.

I see. But among the 1400+ user contributions, how can we find the files
that are (more or less) translations of Java, C#, etc. standard modules?

> Their code may have to be rewritten for a variety of reasons.
>
>>>> * 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 ...
>
> As far as readibility is concerned, I'd strongly object to this.
> find(what,where) appears to me more meaningful than find(x,s).

I agree. So this probably is a good reason to make an exception from
the rule. Then we should include something in the coding guidelines
such as:
"The names of routine parameters should be short words, which describe
their meaning for the routine.
I.e. it should be e.g. /find(what,where)/ rather than /find(x,s)/."

>> 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?
>
> Let's at least insist on maintaining as much consistency as possible
> between parameters names and order inside each module and if possible
> across the whole ESL.

Yes, of course. I also consider this important.
I was just meaning that it is hard to write down general abstract rules
regarding this issue. It's much easier, when there is concrete code, to
decide whether or not everything is consistent.

> Do you get the correct parameter order for mem_copy() right every time?

I think I never used mem_copy(). I often have this problem regarding
repeat(), though.

> If only we had basic's named parameters....

Named parameters would be cool.

Regards,
   Juergen