Re: Standard Euphoria Library project
> Date: Mon, 25 Jul 2005 21:15:39 +0200
> From: "Juergen Luethje" <j.lue at gmx.de>
> Subject: Re: Standard Euphoria Library project
>
>
> I'm very sorry for the late reply. I just got too many e-mails lately ...
>
You mentioned it earlier, no problem there.
> 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'?
>
math.e should be enough. 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).
>
>>> * 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. 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).
> 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. Do you get the correct parameter order for
mem_copy() right every time? If only we had basic's named parameters....
CChris
>
>>> Just some thoughts, I may have some more ideas (initially mistyped
>>> oddeas) later.
>
>
> 
>
> Regards,
> Juergen
|
Not Categorized, Please Help
|
|
