1. Standard Euphoria Library project
Jason Gade wrote:
> I'll look at the OpenEU docs for ideas. I think many features requested in
> the language
> could be implemented in a new standard library.
>
> What needs to be done is look at what kinds of things users need, what kind of
> facilities
> exist in other languages (either in their library or as a standard part of the
> language)
> and figure out how the library should be structured.
>
> Find which parts of the library are already written and in the archive, and
> include
> them as needed. (strtok, win32lib or wxeuphoria, etc.)
>
> I think one of the "gotchas" in doing it would be interdependencies between
> functional
> areas of the library.
>
> One idea is to reference Win32lib in order to see how a good library is
> written and
> structured.
>
> I'm willing but my experience is low. I can't guarantee that I won't lose
> interest
> but I would like to try. I think it will require much research and planning
> before
> any lines of code are written.
I see the opposite ends of the spectrum of solutions for this project as:
Red: Just start writing/collecting the "features" that you want the
library to have, implement them more or less as individual "standalone"
language solutions and worry about the interdepndencies later.
Blue: Consider at great length some overarching standards for the
architecture of the library, spend ages drafting a specification for it
and then try to reconfigure the available libraries to comply with it
(or write loads of brand new code from scratch).
I would propose the following compromise ...
Focus initially on a small group of ibrary modules that are most urgently
needed and concentrate effort on making each of these consistent within
itself. If you can make each library module consistent with the other
modules as far as pssible, all the better, but if not, live with it and
document the inconsistencies between modules as "to-do's" for the
subsequent releases.
I would focus on core language needs first, since higher level things will
be built upon them and if they are robust and mature, the higher level
stuff will be as well.
One obvious example would be a Euphoria "Collections" module to extend
the functionality of sequences in some much needed areas. Mirroring
the excellent Java "Collections" class, this module could implement
associative arrays (HashTables), sets, indexed arrays etc. etc. This
alone would would be an invaluable start to the library.
Other things ... keep RDS in the loop so that unnecessary effort is not
wasted creating features that the next version of Euphoria will implement,
and also for feedback (nobody knows more than they do about the behavior
of the language). Solicit help, make allies. Release fast, release often.
Best
Gordon
2. Re: Standard Euphoria Library project
Gordon Webster wrote:
<snip>
> I would propose the following compromise ...
>
> Focus initially on a small group of ibrary modules that are most urgently
> needed and concentrate effort on making each of these consistent within
> itself. If you can make each library module consistent with the other
> modules as far as pssible, all the better, but if not, live with it and
> document the inconsistencies between modules as "to-do's" for the
> subsequent releases.
>
> I would focus on core language needs first, since higher level things will
> be built upon them and if they are robust and mature, the higher level
> stuff will be as well.
>
> One obvious example would be a Euphoria "Collections" module to extend
> the functionality of sequences in some much needed areas. Mirroring
> the excellent Java "Collections" class, this module could implement
> associative arrays (HashTables), sets, indexed arrays etc. etc. This
> alone would would be an invaluable start to the library.
>
> Other things ... keep RDS in the loop so that unnecessary effort is not
> wasted creating features that the next version of Euphoria will implement,
> and also for feedback (nobody knows more than they do about the behavior
> of the language). Solicit help, make allies. Release fast, release often.
I agree. 
Regards,
Juergen
3. Re: Standard Euphoria Library project
Juergen Luethje wrote:
>
> Gordon Webster wrote:
>
> <snip>
>
> > I would propose the following compromise ...
> >
> > Focus initially on a small group of ibrary modules that are most urgently
> > needed and concentrate effort on making each of these consistent within
> > itself. If you can make each library module consistent with the other
> > modules as far as pssible, all the better, but if not, live with it and
> > document the inconsistencies between modules as "to-do's" for the
> > subsequent releases.
> >
> > I would focus on core language needs first, since higher level things will
> > be built upon them and if they are robust and mature, the higher level
> > stuff will be as well.
> >
> > One obvious example would be a Euphoria "Collections" module to extend
> > the functionality of sequences in some much needed areas. Mirroring
> > the excellent Java "Collections" class, this module could implement
> > associative arrays (HashTables), sets, indexed arrays etc. etc. This
> > alone would would be an invaluable start to the library.
> >
> > Other things ... keep RDS in the loop so that unnecessary effort is not
> > wasted creating features that the next version of Euphoria will implement,
> > and also for feedback (nobody knows more than they do about the behavior
> > of the language). Solicit help, make allies. Release fast, release often.
>
> I agree.
>
> Regards,
> Juergen
>
>
For the most part my quick and unscientific survey finds that a lot of "standard
library" functionality exists in the archive. I think that it is just a question
of pulling it all together and then finding out and adding whatever is still
missing.
=====================================
Too many freaks, not enough circuses.
j.
4. Re: Standard Euphoria Library project
Christian Cuvier wrote:
> From: "Juergen Luethje"
>
>> Christian Cuvier wrote: <snip>
>>
>>>> The Standard Euphoria Library project on Sourceforge is dead.
>>>> The OpenEuphoria group, which is the one you're referring to, is dead as
>>>> well.
>>>> Its homepage is at oedoc.free.fr actually.
>>>>
>>>
>>>>>> Now I wouldn't want to organize such a thing because I am not an
>>>>>> experienced
>>>>>> developer. But I would want to contribute ideas, documentation, or
>>>>>> code..
>>>
>>>>
>>>> I was originally the doc manager for OpnEU. I wound up docig sequences
>>>> in C++ when the group imploded. Now I'm admin of a souceforge defunct
>>>> project. Wanna get in?
>>
>>
>> I'd like to join the Standard Euphoria Library project.
>>
>
> I just checked out on sf: that project doesn't even show up in the
> search results for "Euphoria". It appears to have produced no file at
> all last time I had checked (possibly 1 year ago). I'd pronounce it dead
> and buried.
>
> Otherwise, sourceforge.net/projects/peu hosts the same specs as you'd
> find on my website.
I visited your site <http://oedoc.free.fr/>, looked at the "Original
mission statement for OpenEuphoria" which is linked there, and
downloaded "OEdoc_v1_4.zip". I'm impressd, you guys did a considerable
amount of work!
But I think most of this can't be used for the Standard Euphoria Library
project, because it's a different beast. We need a new "Mission
statement", maybe that's the first thing we should create.
Then maybe we should write down some internal standards, i.e. an
internal naming convention, and a standdard for the way we create the
modules of our library. We could use the text that Derek posted here
recently as guideline.
Just some more thoughts:
- Build one module after the other.
- When one module is finished, release a new version.
- For a new module, first someone writes the specs.
- The specs are discussed in the project group.
- Then one (ore more) person(s) write(s) the code for the module.
- Then at least 2 persons -- and only persons who didn't write the
code -- check whether the code meets the specification independently
of each other. One of these "peer reviewers" should be an IT
professional.
( Well, how much of them participate in the project? )
- The documentation should be written (or at least be "polished") by
native English speakers.
Regards,
Juergen
5. Re: Standard Euphoria Library project
Jason Gade wrote:
> Juergen Luethje wrote:
>
>> Christian Cuvier wrote:
>>
>> <snip>
>>
>>> The Standard Euphoria Library project on Sourceforge is dead.
>>> The OpenEuphoria group, which is the one you're referring to, is dead as
>>> well.
>>> Its homepage is at oedoc.free.fr actually.
>>>
>>>> Now I wouldn't want to organize such a thing because I am not an
>>>> experienced
>>>> developer. But I would want to contribute ideas, documentation, or code.
>>>
>>> I was originally the doc manager for OpnEU. I wound up docig sequences
>>> in C++ when the group imploded. Now I'm admin of a souceforge defunct
>>> project. Wanna get in?
>>
>> I'd like to join the Standard Euphoria Library project.
>
> I'll look at the OpenEU docs for ideas. I think many features
> requested in the language could be implemented in a new standard
> library.
>
> What needs to be done is look at what kinds of things users need, what
> kind of facilities exist in other languages
Yes, that is one of the meanings of the term "standard". There are
several functions -- such as abs(), ceil(), min(), max() -- that
exist in many other languages. Those functions should be contained in
our Standard Euphoria Library.
> (either in their library or as a standard part of the language) and
> figure out how the library should be structured.
>
> Find which parts of the library are already written and in the archive,
> and include them as needed. (strtok, win32lib or wxeuphoria, etc.)
IMHO win32lib or wxeuphoria or any other GUI library should *not* be
integrated in the Standard Euphoria Library. At least not yet, maybe in
version 10.0 or so.
IMHO the Standard Euphoria Library should be modular with a great
granularity, and it also should be 100% cross-platform for all
platforms supported by Euphoria.
We should make a plan and consider some things, but in order to avoid
what happened to the OpenEu project, we should not discuss too long, and
try to release rather soon a first simple version. Like all other people,
we'll need a feeling of success now and then.
Includeing a GUI library is rather complex, and will take much too long
time.
But important would be IMHO to *supplement* one or more GUI libraries.
E.g. AFAIK Win32lib does not only contain GUI routines, but also file
handling routines.
It would be very good, if our Standard Euphoria Library would contain
some standard (sic!) file handling routines, which can be (and hopefully
will be!) used by Win32lib, ARWEN, etc.
So another meaning of the term "standard" is: Suited to the needs of
other programs and libraries, and accepted by their authors, so that the
authers don't see a need for duplicating the code. Not each GUI library
needs its own file handling routines. Trying to avoid things like that
should IMHO be one goal of a Standard Euphoria Library project.
> I think one of the "gotchas" in doing it would be interdependencies
> between functional areas of the library.
I also think so. We should start with simple routines with only a few
interdependencies. The granularity of the library should be great.
For instance we could start with a 'math.e' file that contains some
general well defined functions -- mathematicians tend to define their
"stuff" very well -- such as abs(), ceil() etc., and a 'sets.e' file
( the existing 'sets.e'file in the archives is not very good ), and say
2 or 3 more .e files, and a good HTML documentation.
> One idea is to reference Win32lib in order to see how a good library is
> written and structured.
As far as I know Win32lib is one "monolithic" library. That is what I
certainly do not want a Standard Euphoria Library to be. IMHO it should
consist of several include files, which are as independent as possaible
from each other. A better model IMHO are the official RDS include files
that are contained in the Euphoria distribution.
> I'm willing but my experience is low. I can't guarantee that I won't
> lose interest but I would like to try. I think it will require much
> research and planning before any lines of code are written.
We should'nt wait too long until the first release. It is necessary to
establish the project. Currently, even someone else has taken the name
"Standard Euphoria Library" for his own project. I hope he will change
the name soon, and leave the name where it belongs.
But this shows, how important it is to actually *create* a project, and
not only to talk about it.
Regards,
Juergen
6. Re: Standard Euphoria Library project
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> > Juergen Luethje wrote:
> >
> >> Christian Cuvier wrote:
> >>
> >> <snip>
> >>
> >>> The Standard Euphoria Library project on Sourceforge is dead.
> >>> The OpenEuphoria group, which is the one you're referring to, is dead as
> >>> well.
> >>> Its homepage is at oedoc.free.fr actually.
> >>>
> >>>> Now I wouldn't want to organize such a thing because I am not an
> >>>> experienced
> >>>> developer. But I would want to contribute ideas, documentation, or code.
> >>>
> >>> I was originally the doc manager for OpnEU. I wound up docig sequences
> >>> in C++ when the group imploded. Now I'm admin of a souceforge defunct
> >>> project. Wanna get in?
> >>
> >> I'd like to join the Standard Euphoria Library project.
> >
> > I'll look at the OpenEU docs for ideas. I think many features
> > requested in the language could be implemented in a new standard
> > library.
> >
> > What needs to be done is look at what kinds of things users need, what
> > kind of facilities exist in other languages
>
> Yes, that is one of the meanings of the term "standard". There are
> several functions -- such as abs(), ceil(), min(), max() -- that
> exist in many other languages. Those functions should be contained in
> our Standard Euphoria Library.
>
> > (either in their library or as a standard part of the language) and
> > figure out how the library should be structured.
> >
> > Find which parts of the library are already written and in the archive,
> > and include them as needed. (strtok, win32lib or wxeuphoria, etc.)
>
> IMHO win32lib or wxeuphoria or any other GUI library should *not* be
> integrated in the Standard Euphoria Library. At least not yet, maybe in
> version 10.0 or so.
You quoted me, but I didn't mean what I said ;^) I did only want to include
standard utilities and leave GUI stuff until later if at all.
>
> IMHO the Standard Euphoria Library should be modular with a great
> granularity, and it also should be 100% cross-platform for all
> platforms supported by Euphoria.
Agreed. It would be useless without being cross-platform. Even standard
file-handling routines should check platform() and operate accordingly.
>
> We should make a plan and consider some things, but in order to avoid
> what happened to the OpenEu project, we should not discuss too long, and
> try to release rather soon a first simple version. Like all other people,
> we'll need a feeling of success now and then.
> Includeing a GUI library is rather complex, and will take much too long
> time.
> But important would be IMHO to *supplement* one or more GUI libraries.
> E.g. AFAIK Win32lib does not only contain GUI routines, but also file
> handling routines.
> It would be very good, if our Standard Euphoria Library would contain
> some standard (sic!) file handling routines, which can be (and hopefully
> will be!) used by Win32lib, ARWEN, etc.
Yes. The API should be the same to the using program. The library should check
its platform and the using program shouldn't have to in order to use the proper
routines.
> So another meaning of the term "standard" is: Suited to the needs of
> other programs and libraries, and accepted by their authors, so that the
> authers don't see a need for duplicating the code. Not each GUI library
> needs its own file handling routines. Trying to avoid things like that
> should IMHO be one goal of a Standard Euphoria Library project.
>
> > I think one of the "gotchas" in doing it would be interdependencies
> > between functional areas of the library.
>
> I also think so. We should start with simple routines with only a few
> interdependencies. The granularity of the library should be great.
> For instance we could start with a 'math.e' file that contains some
> general well defined functions -- mathematicians tend to define their
> "stuff" very well -- such as abs(), ceil() etc., and a 'sets.e' file
> ( the existing 'sets.e'file in the archives is not very good ), and say
> 2 or 3 more .e files, and a good HTML documentation.
I'll check the archive for math routines. Another good place to start is with
string/sequence handling routines that people have already referenced or posted
to this thread.
>
> > One idea is to reference Win32lib in order to see how a good library is
> > written and structured.
>
> > I'm willing but my experience is low. I can't guarantee that I won't
> > lose interest but I would like to try. I think it will require much
> > research and planning before any lines of code are written.
>
> We should'nt wait too long until the first release. It is necessary to
> establish the project. Currently, even someone else has taken the name
> "Standard Euphoria Library" for his own project. I hope he will change
> the name soon, and leave the name where it belongs.
> But this shows, how important it is to actually *create* a project, and
> not only to talk about it.
Agreed. I want to start working on an etypes.e library that will cover some of
the types requested in the OpenEU document.
I want it to cover strings, various integers, structures, arrays, etc.
>
> Regards,
> Juergen
>
>
=====================================
Too many freaks, not enough circuses.
j.
7. Re: Standard Euphoria Library project
Jason Gade wrote:
> For the most part my quick and unscientific survey finds that a lot of
> "standard library" functionality exists in the archive.
Well, partly ...
I'm sorry that I must say that, but several of the user contributions
are incomplete, buggy, written in a style almost unreadable by others
etc.
E.g. what "standard" operations can be done with sets? There are only a
few of those operations, which we'll find in math textbooks.
Or we can look e.g. at <http://www.brpreiss.com/books/opus4/>, or we can
e.g. look what routines other, *very popular* languages have implemented,
such as Python.
We have a "sets.e" contribution in the archives. Does this contribution
cover these basic functions? No, it doesn't. But a "Standard Library"
that deserves that name certainly should do so! The same is with Fuzzy
Sets, and ... These are only some examples which I know from memory.
> I think that it is just a question of pulling it all together and
> then finding out and adding whatever is still missing.
"Standard" should also mean IMHO, that we'll have some internal
standards concerning the way *how* the library is created. That will
make a big difference to all the "private" contributions.
Regards,
Juergen
8. Re: Standard Euphoria Library project
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> > For the most part my quick and unscientific survey finds that a lot of
> > "standard library" functionality exists in the archive.
>
> Well, partly ...
>
> I'm sorry that I must say that, but several of the user contributions
> are incomplete, buggy, written in a style almost unreadable by others
> etc.
>
> E.g. what "standard" operations can be done with sets? There are only a
> few of those operations, which we'll find in math textbooks.
> Or we can look e.g. at <<a
> href="http://www.brpreiss.com/books/opus4/">http://www.brpreiss.com/books/opus4/</a>>,
> or we can
> e.g. look what routines other, *very popular* languages have implemented,
> such as Python.
> We have a "sets.e" contribution in the archives. Does this contribution
> cover these basic functions? No, it doesn't. But a "Standard Library"
> that deserves that name certainly should do so! The same is with Fuzzy
> Sets, and ... These are only some examples which I know from memory.
>
Yes, we should look at what and how other popular languages include in their
standard libraries, even C/C++. That is very important. But we must also take
into account what Euphoria already has built-in or in the RDS library so we don't
duplicate effort.
> > I think that it is just a question of pulling it all together and
> > then finding out and adding whatever is still missing.
>
> "Standard" should also mean IMHO, that we'll have some internal
> standards concerning the way *how* the library is created. That will
> make a big difference to all the "private" contributions.
>
> Regards,
> Juergen
Various libraries in the archive contain useful routines. Sometimes it is
better to re-package them and sometimes it is better to rewrite them to meet the
"how" part of the library.
=====================================
Too many freaks, not enough circuses.
j.
9. Re: Standard Euphoria Library project
> Date: Thu, 07 Jul 2005 17:16:07 +0200
> From: "Juergen Luethje" <j.lue at gmx.de>
> Subject: Re: Standard Euphoria Library project
>
>
> Christian Cuvier wrote:
>
>
>>> From: "Juergen Luethje"
>>>
>>
>>>>> Christian Cuvier wrote: <snip>
>>>>>
>>>
>>>>>>>>> The Standard Euphoria Library project on Sourceforge is dead.
>>>>>>>>> The OpenEuphoria group, which is the one you're referring to, is dead
>>>>>>>>> as
>>>>>>>>> well.
>>>>>>>>> Its homepage is at oedoc.free.fr actually.
>>>>>>>>>
>>>>
>>>>>>>>>>>>> Now I wouldn't want to organize such a thing because I am not an
>>>>>>>>>>>>> experienced
>>>>>>>>>>>>> developer. But I would want to contribute ideas, documentation,
>>>>>>>>>>>>> or code..
>>>>
>>>>>>>
>>>>>>>>> I was originally the doc manager for OpnEU. I wound up docig sequences
>>>>>>>>> in C++ when the group imploded. Now I'm admin of a souceforge defunct
>>>>>>>>> project. Wanna get in?
>>>
>>>>>
>>>>> I'd like to join the Standard Euphoria Library project.
>>>>>
>>
>>> I just checked out on sf: that project doesn't even show up in the
>>> search results for "Euphoria". It appears to have produced no file at
>>> all last time I had checked (possibly 1 year ago). I'd pronounce it dead
>>> and buried.
>>>
>>> Otherwise, sourceforge.net/projects/peu hosts the same specs as you'd
>>> find on my website.
>
>
> I visited your site <http://oedoc.free.fr/>, looked at the "Original
> mission statement for OpenEuphoria" which is linked there, and
> downloaded "OEdoc_v1_4.zip". I'm impressd, you guys did a considerable
> amount of work!
>
> But I think most of this can't be used for the Standard Euphoria Library
> project, because it's a different beast. We need a new "Mission
> statement", maybe that's the first thing we should create.
>
Agreed. The aim of OpenEuphoria was to incorporate features that are not
feasible using external libraries, or feasible only at a hefty
performance penalty.
> Then maybe we should write down some internal standards, i.e. an
> internal naming convention, and a standdard for the way we create the
> modules of our library. We could use the text that Derek posted here
> recently as guideline.
>
> Just some more thoughts:
> - Build one module after the other.
> - When one module is finished, release a new version.
> - For a new module, first someone writes the specs.
> - The specs are discussed in the project group.
> - Then one (ore more) person(s) write(s) the code for the module.
> - Then at least 2 persons -- and only persons who didn't write the
> code -- check whether the code meets the specification independently
> of each other. One of these "peer reviewers" should be an IT
> professional.
> ( Well, how much of them participate in the project? )
> - The documentation should be written (or at least be "polished") by
> native English speakers.
>
On the principle, I agree again with all points. However, we can make
things much simpler as follows:
C++ provides a Standard Temlate Library which is remarkably
well-thought, and whose design was polished by hundreds of qualified
persons. Why reinvent the wheel?
Let's start from the public specifications for this "library", and the
only job left, apart from coding, will be to define which areas won't be
implemented (mostly because of the limitations Eu has). Docs already
exist, they'll have to be translated into the framework of Euphoria (for
instance, Eu has no pointers...). Again, the idea is not to start from
scratch.
Another thought: specs are good, but the end user generally can't use
them. There will be a need for an User Guide to supplement the specs.
That User Guide should be written by people not involved n writing the
specs. It will be organised around the users' needs (tasks to perform),
showing how the tools in the library can be used for completing these
tasks. The fine technical points will be covered either in the specs or
in specific release notes, according to their being more or less structural.
Regards
CChris
> Regards,
> Juergen
10. Re: Standard Euphoria Library project
Christian Cuvier wrote:
>
> > Date: Thu, 07 Jul 2005 17:16:07 +0200
> > From: "Juergen Luethje" <j.lue at gmx.de>
> > Subject: Re: Standard Euphoria Library project
> >
> >
> > Christian Cuvier wrote:
> >
> >
> >>> From: "Juergen Luethje"
> >>>
> >>
> >>>>> Christian Cuvier wrote: <snip>
> >>>>>
> >>>
> >>>>>>>>> The Standard Euphoria Library project on Sourceforge is dead.
> >>>>>>>>> The OpenEuphoria group, which is the one you're referring to, is
> >>>>>>>>> dead as
> >>>>>>>>> well.
> >>>>>>>>> Its homepage is at oedoc.free.fr actually.
> >>>>>>>>>
> >>>>
> >>>>>>>>>>>>> Now I wouldn't want to organize such a thing because I am not an
> >>>>>>>>>>>>> experienced
> >>>>>>>>>>>>> developer. But I would want to contribute ideas, documentation,
> >>>>>>>>>>>>> or code..
> >>>>
> >>>>>>>
> >>>>>>>>> I was originally the doc manager for OpnEU. I wound up docig
> >>>>>>>>> sequences
> >>>>>>>>> in C++ when the group imploded. Now I'm admin of a souceforge
> >>>>>>>>> defunct
> >>>>>>>>> project. Wanna get in?
> >>>
> >>>>>
> >>>>> I'd like to join the Standard Euphoria Library project.
> >>>>>
> >>
> >>> I just checked out on sf: that project doesn't even show up in the
> >>> search results for "Euphoria". It appears to have produced no file at
> >>> all last time I had checked (possibly 1 year ago). I'd pronounce it dead
> >>> and buried.
> >>>
> >>> Otherwise, sourceforge.net/projects/peu hosts the same specs as you'd
> >>> find on my website.
> >
> >
> > I visited your site <<a
> > href="http://oedoc.free.fr/">http://oedoc.free.fr/</a>>, looked at the "Original
> > mission statement for OpenEuphoria" which is linked there, and
> > downloaded "OEdoc_v1_4.zip". I'm impressd, you guys did a considerable
> > amount of work!
> >
> > But I think most of this can't be used for the Standard Euphoria Library
> > project, because it's a different beast. We need a new "Mission
> > statement", maybe that's the first thing we should create.
> >
>
> Agreed. The aim of OpenEuphoria was to incorporate features that are not
> feasible using external libraries, or feasible only at a hefty
> performance penalty.
>
> > Then maybe we should write down some internal standards, i.e. an
> > internal naming convention, and a standdard for the way we create the
> > modules of our library. We could use the text that Derek posted here
> > recently as guideline.
> >
> > Just some more thoughts:
> > - Build one module after the other.
> > - When one module is finished, release a new version.
> > - For a new module, first someone writes the specs.
> > - The specs are discussed in the project group.
> > - Then one (ore more) person(s) write(s) the code for the module.
> > - Then at least 2 persons -- and only persons who didn't write the
> > code -- check whether the code meets the specification independently
> > of each other. One of these "peer reviewers" should be an IT
> > professional.
> > ( Well, how much of them participate in the project? )
> > - The documentation should be written (or at least be "polished") by
> > native English speakers.
> >
>
> On the principle, I agree again with all points. However, we can make
> things much simpler as follows:
>
> C++ provides a Standard Temlate Library which is remarkably
> well-thought, and whose design was polished by hundreds of qualified
> persons. Why reinvent the wheel?
> Let's start from the public specifications for this "library", and the
> only job left, apart from coding, will be to define which areas won't be
> implemented (mostly because of the limitations Eu has). Docs already
> exist, they'll have to be translated into the framework of Euphoria (for
> instance, Eu has no pointers...). Again, the idea is not to start from
> scratch.
Isn't the STL mostly or all container classes? Many of those wouldn't apply to
Euphoria because of the existence of sequences. The ones that do could easily be
done in libraries.
> Another thought: specs are good, but the end user generally can't use
> them. There will be a need for an User Guide to supplement the specs.
> That User Guide should be written by people not involved n writing the
> specs. It will be organised around the users' needs (tasks to perform),
> showing how the tools in the library can be used for completing these
> tasks. The fine technical points will be covered either in the specs or
> in specific release notes, according to their being more or less structural.
Use the Makedoc from win32lib and document the library properly...
> Regards
> CChris
> > Regards,
> > Juergen
>
>
=====================================
Too many freaks, not enough circuses.
j.
11. Re: Standard Euphoria Library project
I'm sorry for the delay in replying. I was a little distracted.
Jason Gade wrote:
> Christian Cuvier wrote:
>>
>> From: "Juergen Luethje"
<snip>
>>> Then maybe we should write down some internal standards, i.e. an
>>> internal naming convention, and a standdard for the way we create the
>>> modules of our library. We could use the text that Derek posted here
>>> recently as guideline.
>>>
>>> Just some more thoughts:
>>> - Build one module after the other.
>>> - When one module is finished, release a new version.
>>> - For a new module, first someone writes the specs.
>>> - The specs are discussed in the project group.
>>> - Then one (ore more) person(s) write(s) the code for the module.
>>> - Then at least 2 persons -- and only persons who didn't write the
>>> code -- check whether the code meets the specification independently
>>> of each other. One of these "peer reviewers" should be an IT
>>> professional.
>>> ( Well, how much of them participate in the project? )
>>> - The documentation should be written (or at least be "polished") by
>>> native English speakers.
>>>
>>
>> On the principle, I agree again with all points. However, we can make
>> things much simpler as follows:
>>
>> C++ provides a Standard Temlate Library which is remarkably
>> well-thought, and whose design was polished by hundreds of qualified
>> persons. Why reinvent the wheel?
I agree. I just didn't see the wood for the trees.
>> Let's start from the public specifications for this "library", and the
>> only job left, apart from coding, will be to define which areas won't be
>> implemented (mostly because of the limitations Eu has). Docs already
>> exist, they'll have to be translated into the framework of Euphoria (for
>> instance, Eu has no pointers...). Again, the idea is not to start from
>> scratch.
>
> Isn't the STL mostly or all container classes? Many of those wouldn't
> apply to Euphoria because of the existence of sequences. The ones that
> do could easily be done in libraries.
I know almost nothing about C++. I have a little book about C and C++,
but after reading the 3 pages about templates, I'm none the wise.
Many pages in the book are dealing with the C runtime library. Maby we
should take that as model? C is a procedural language like Euphoria,
while C++ is object-oriented. So I think C is closer to Euphoria, isn't it?
>> Another thought: specs are good, but the end user generally can't use
>> them. There will be a need for an User Guide to supplement the specs.
>> That User Guide should be written by people not involved n writing the
>> specs. It will be organised around the users' needs (tasks to perform),
>> showing how the tools in the library can be used for completing these
>> tasks. The fine technical points will be covered either in the specs or
>> in specific release notes, according to their being more or less structural.
>
> Use the Makedoc from win32lib and document the library properly...
I'll have a look at it. I'll also again have look at Tommy's Kanarie, to
see how good it might be suited for this task.
So what do we need to start:
o Some pages on the web.
- Christian's site, my site, SourceForge?
o There we'll write down
- A mission statement
- Coding guidelines
- A list of say 3 to 5 .e files that should be contained in the first
release.
- A list of contributers (Who will do what?)
...
I don't have any experience with organizing such a project.
Regards,
Juergen
12. Re: Standard Euphoria Library project
Juergen Luethje wrote:
>
> I'm sorry for the delay in replying. I was a little distracted.
>
> I'll have a look at it. I'll also again have look at Tommy's Kanarie, to
> see how good it might be suited for this task.
>
> So what do we need to start:
>
> o Some pages on the web.
> - Christian's site, my site, SourceForge?
Totally agree. I think we need to get a website up with information and contact
info so people know what's going on, what we need, and how to contribute.
> o There we'll write down
> - A mission statement
> - Coding guidelines
As for coding guidelines, this could be a bit problematic... We certainly need
them but everyone has their own idea of what is "right". I'd suggest keeping the
guidlines as close to Rob's code as possible. While many people might like the
"aVal is an atom, cVal is a constant, etc." style I think keeping the libraries
as close to "standard" as can be is a good idea and so far all we really have is
Rob's code.
Here is what some of these guidelines would be:
Constant names are all written in all capital letters.
ex. constant TRUE = 1
Global variables start with a capital letter.
(NOTE: Not Rob's coding style but many people do this and I think it works
very well)
(ALSO NOTE: global could mean global in the file or global as in exported)
ex. integer Debug_switch
Local variables are written in all lowercase letters.
ex. integer index
All routines and types are written in all lowercase letters.
ex. function get()
Varaible names are written in a "block" style.
ex. constant A = "A",
BC = "bc",
DEF = "def"
Comments should have at least one space after the "--", if there isn't one
it's commented out code
ex. -- This is a comment, below is a line of code commented out
--line = "commented out"
All code blocks whould be indented with 4 spaces like ed does.
ex. if x = 5 then
do_crap()
end if
If the next line is run off from a previous use 2 space indent.
ex. If a = 5 and b = 4
and c = 3 then
For the most part, constants and routines should not be abbreviations. (Only
local variables)
ex. integer pos
procedure position()
> - A list of say 3 to 5 .e files that should be contained in the first
> release.
string.e -- String handling
cgi.e -- CGI routines
math.e -- Math functions
system.e -- File system commands (move_file(), delete_file(), etc.)
I also have a list of routines that should be written for each.
> - A list of contributers (Who will do what?)
I'll gladly contribute code (I have tons of libraries for my own use) and I'm
sure other people will once the ball gets rolling.
> I don't have any experience with organizing such a project.
>
> Regards,
> Juergen
13. Re: Standard Euphoria Library project
D. Newhall wrote:
>
> Juergen Luethje wrote:
> >
> > I'm sorry for the delay in replying. I was a little distracted.
> >
> > I'll have a look at it. I'll also again have look at Tommy's Kanarie, to
> > see how good it might be suited for this task.
> >
> > So what do we need to start:
> >
> > o Some pages on the web.
> > - Christian's site, my site, SourceForge?
>
> Totally agree. I think we need to get a website up with information and
> contact info
> so people know what's going on, what we need, and how to contribute.
>
> > o There we'll write down
> > - A mission statement
> > - Coding guidelines
>
> As for coding guidelines, this could be a bit problematic... We certainly need
> them
> but everyone has their own idea of what is "right". I'd suggest keeping the
> guidlines
> as close to Rob's code as possible. While many people might like the "aVal is
> an atom,
> cVal is a constant, etc." style I think keeping the libraries as close to
> "standard"
> as can be is a good idea and so far all we really have is Rob's code.
>
> Here is what some of these guidelines would be:
> Constant names are all written in all capital letters.
> ex. constant TRUE = 1
> Global variables start with a capital letter.
> (NOTE: Not Rob's coding style but many people do this and I think it
> works very
> well)
> (ALSO NOTE: global could mean global in the file or global as in
> exported)
> ex. integer Debug_switch
> Local variables are written in all lowercase letters.
> ex. integer index
> All routines and types are written in all lowercase letters.
> ex. function get()
> Varaible names are written in a "block" style.
> ex. constant A = "A",
> BC = "bc",
> DEF = "def"
> Comments should have at least one space after the "--", if there isn't one
> it's
> commented out code
> ex. -- This is a comment, below is a line of code commented out
> --line = "commented out"
> All code blocks whould be indented with 4 spaces like ed does.
> ex. if x = 5 then
> do_crap()
> end if
> If the next line is run off from a previous use 2 space indent.
> ex. If a = 5 and b = 4
> and c = 3 then
> For the most part, constants and routines should not be abbreviations.
> (Only local
> variables)
> ex. integer pos
> procedure position()
>
> > - A list of say 3 to 5 .e files that should be contained in the first
> > release.
>
> string.e -- String handling
> cgi.e -- CGI routines
> math.e -- Math functions
> system.e -- File system commands (move_file(), delete_file(), etc.)
>
> I also have a list of routines that should be written for each.
>
> > - A list of contributers (Who will do what?)
>
> I'll gladly contribute code (I have tons of libraries for my own use) and I'm
> sure
> other people will once the ball gets rolling.
>
> > I don't have any experience with organizing such a project.
> >
> > Regards,
> > Juergen
>
One place to look before writing a bunch of new code is Derek Parnell's tk
routines http://www.rapideuphoria.com/toolkits.zip and other submissions to the
archive
http://www.rapideuphoria.com/cgi-bin/asearch.exu?gen=on&keywords=Parnell
for some very good ideas.
Also Bernie Ryan's Utility Library http://www.rapideuphoria.com/mixedlib.zip
Much of the C standard library can be found, especially in Derek's toolkit
routines.
=====================================
Too many freaks, not enough circuses.
j.
14. Re: Standard Euphoria Library project
D. Newhall wrote:
> Juergen Luethje wrote:
>>
>> I'm sorry for the delay in replying. I was a little distracted.
>>
>> I'll have a look at it. I'll also again have look at Tommy's Kanarie, to
>> see how good it might be suited for this task.
>>
>> So what do we need to start:
>>
>> o Some pages on the web.
>> - Christian's site, my site, SourceForge?
>
> Totally agree. I think we need to get a website up with information and
> contact info so people know what's going on, what we need, and how to
> contribute.
>
>> o There we'll write down
>> - A mission statement
>> - Coding guidelines
>
> As for coding guidelines, this could be a bit problematic... We
> certainly need them but everyone has their own idea of what is "right".
> I'd suggest keeping the guidlines as close to Rob's code as possible.
I'd also prefer that.
> While many people might like the "aVal is an atom, cVal is a constant,
> etc." style I think keeping the libraries as close to "standard" as
> can be is a good idea and so far all we really have is Rob's code.
>
> Here is what some of these guidelines would be:
Huuu.. that's already rather specific stuff. For me very fine in general
-- especially since my private coding habits are very similar .
Too strict for anyone?
> Constant names are all written in all capital letters.
> ex. constant TRUE = 1
> Global variables start with a capital letter.
> (NOTE: Not Rob's coding style but many people do this and I think it
> works very well)
> (ALSO NOTE: global could mean global in the file or global as in
> exported)
> ex. integer Debug_switch
> Local variables are written in all lowercase letters.
> ex. integer index
> All routines and types are written in all lowercase letters.
> ex. function get()
> Varaible names are written in a "block" style.
> ex. constant A = "A",
> BC = "bc",
> DEF = "def"
> Comments should have at least one space after the "--",
... and IMHO before the "--", too.
> if there isn't one it's commented out code
IMHO we should mark commented out code more clearly. Maybe with ++ or
something at the beginning, so that it can easily be found using the
search function of an editor, and with a short note why it was commented
out?
> ex. -- This is a comment, below is a line of code commented out
> --line = "commented out"
> All code blocks whould be indented with 4 spaces like ed does.
> ex. if x = 5 then
> do_crap()
> end if
> If the next line is run off from a previous use 2 space indent.
> ex. If a = 5 and b = 4
> and c = 3 then
> For the most part, constants and routines should not be abbreviations.
> (Only local variables)
> ex. integer pos
> procedure position()
>
>> - A list of say 3 to 5 .e files that should be contained in the first
>> release.
>
> string.e -- String handling
> cgi.e -- CGI routines
> math.e -- Math functions
> system.e -- File system commands (move_file(), delete_file(), etc.)
>
> I also have a list of routines that should be written for each.
>
>> - A list of contributers (Who will do what?)
>
> I'll gladly contribute code (I have tons of libraries for my own use)
> and I'm sure other people will once the ball gets rolling.
That's what I think, too.
>> I don't have any experience with organizing such a project.
... but I think for instance Christian has from the OpenEu project.
However, he currently seems to be busy or isn't online or ...
For my personal feeling time had come to collect all the good ideas that
have been posted here recently, and to write them down in order (more or
less). So you'll now find two files concerning the Euphoria Standard Library
on my website
- http://home.arcor.de/luethje/esl/index.htm
- http://home.arcor.de/luethje/esl/esl_paper01.htm
I hope this is OK for everyone. The files can stay on my website, or we
can put them anywhere else -- it doesn't matter for me. We just should
not have more than one place, where the documents are.
The "papers" are only drafts which will have to be revised, of course.
Regards,
Juergen
15. Re: Standard Euphoria Library project
Jason Gade wrote:
> D. Newhall wrote:
>>
>> Juergen Luethje wrote:
<big snip>
> One place to look before writing a bunch of new code is Derek Parnell's
> tk routines http://www.rapideuphoria.com/toolkits.zip and other
> submissions to the archive
> http://www.rapideuphoria.com/cgi-bin/asearch.exu?gen=on&keywords=Parnell
> for some very good ideas.
>
> Also Bernie Ryan's Utility Library http://www.rapideuphoria.com/mixedlib.zip
>
> Much of the C standard library can be found, especially in Derek's toolkit
> routines.
Also let's not forget Ricardo Forno's General Functions library, and
more ... No doubt that there are many "diamonds" among more than 1400
contributions.
However I think we should not look at all those valuable contributions,
and then consider what will be the best way to put them all together.
IMHO we should go the different way: Let's build a solid framework first,
and then fill that framework with contents.
Furthermore, please see
- http://home.arcor.de/luethje/esl/index.htm
- http://home.arcor.de/luethje/esl/esl_paper01.htm
Regards,
Juergen
16. Re: Standard Euphoria Library project
- Posted by Gordon Webster <gwalias-bb at yahoo.com>
Jul 17, 2005
-
Last edited Jul 18, 2005
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> > D. Newhall wrote:
> >>
> >> Juergen Luethje wrote:
>
> <big snip>
>
> > One place to look before writing a bunch of new code is Derek Parnell's
> > tk routines <a
> > href="http://www.rapideuphoria.com/toolkits.zip">http://www.rapideuphoria.com/toolkits.zip</a>
> > and other
> > submissions to the archive
> > <a
> > href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?gen=on&keywords=Parnell">http://www.rapideuphoria.com/cgi-bin/asearch.exu?gen=on&keywords=Parnell</a>
> > for some very good ideas.
> >
> > Also Bernie Ryan's Utility Library <a
> > href="http://www.rapideuphoria.com/mixedlib.zip">http://www.rapideuphoria.com/mixedlib.zip</a>
> >
> > Much of the C standard library can be found, especially in Derek's toolkit
> > routines.
>
> Also let's not forget Ricardo Forno's General Functions library, and
> more ... No doubt that there are many "diamonds" among more than 1400
> contributions.
>
> However I think we should not look at all those valuable contributions,
> and then consider what will be the best way to put them all together.
> IMHO we should go the different way: Let's build a solid framework first,
> and then fill that framework with contents.
>
> Furthermore, please see
> - <a
> href="http://home.arcor.de/luethje/esl/index.htm">http://home.arcor.de/luethje/esl/index.htm</a>
> - <a
> href="http://home.arcor.de/luethje/esl/esl_paper01.htm">http://home.arcor.de/luethje/esl/esl_paper01.htm</a>
>
> Regards,
> Juergen
>
Wow Juergen, I checked out the links to your website. What a great start!!
I think your draft description of the library really encapsulates pretty much
everything we need to be thinking about and you've indicated where we might
want to fill in some of the finer details.
One question ... should we implement a really (really) simple self-documenting
system? I'm thinking of Python's system where the first block of comments
after the start of a module or procedure are treated as documentation for the
module or procedure itself and can be parsed out for documentation purposes.
We might even have a little tag for the lines that should be parsed so that
authors could have some control to distinguish "doc" lines and other comments.
Here's an example of how it might look ...
-- Module: SimpleHashTables.e
-- Part of the Euphoria Standard Library
-- Contributed by Joe Coder, July 2005
--start-eudoc
-- SimpleHashTables.e
-- Hashtables of key/value pairs. Keys and values can be any Euphoria Object
-- Duplicate keys and the removal of duplicates are now also supported.
--end-eudoc
<some declarations and other code here>
function hashTableGet(integer hashtable, object key)
-- 21st July 2005, Joe Coder's fixed the bug that arose with duplicate keys
--start-eudoc
-- Function hashTableGet
-- Returns the object that is the 'value' in the key/value pair specified
-- by the supplied key. The constant HASHTABLENULL is returned in the event
-- that the specified key does not exist in the current table
--end-eudoc
<some function code here>
end function
This way, all the procedure signatures could be parsed out with their
documentation and turned into text or html.
If you wanted more detail, this model could easily be extended to be more
like 'javadoc' where authors and version dates etc. can also be specified.
I personally think this is overkill. When I'm looking for a description of
how to use a Java hash table, I don't normally care who wrote it or what
version number we're at as long as it's the current official release. Most
times I just want to know how to use that library's functionality in my
code. That more detailed stuff can (and should) be included in normal
comments for those who need it but kept out of the 'eudoc' blocks to make
the documentation more concise and readable.
What do you think?
Best
Gordon
17. Re: Standard Euphoria Library project
Gordon Webster wrote:
>
> One question ... should we implement a really (really) simple self-documenting
> system? I'm thinking of Python's system where the first block of comments
> after the start of a module or procedure are treated as documentation for the
> module or procedure itself and can be parsed out for documentation purposes.
> We might even have a little tag for the lines that should be parsed so that
> authors could have some control to distinguish "doc" lines and other comments.
>
snip
>
> This way, all the procedure signatures could be parsed out with their
> documentation and turned into text or html.
>
snip
>
> What do you think?
I had the same idea a while ago so I started a program to do that. Oddly enough
I just started working on it again and it should be availabel soon. It produces
html files that look like the official Euphoria library routine documentation.
Here's how it works (taken from the opening comments to the program (named
eudoc.ex)):
-- Name: EuDoc - Euphoria documentation program
-- Author: D. Newhall
-- License: Mozilla
-- Date: Feb-7-2005
-- Updated: Feb-14-2005
-- Updated: Jul-13-2005
-- Intro:
-- EuDoc is a program for automatically creating documentation
-- for Euphoria libraries. The file created has the same visual
-- appearance as the library routines list in the official Euphoria
-- documentation. It can also be used to document programs but in a
-- more limited scope.
--
-- For EuDoc to work you first need to document your program using these tags.
-- The tags are case insensitive and need not be in any order but it's highly
-- recommended that you use the capitalization scheme and order shown for
-- better clarity.
--
-- File secriptor tags:
--
-- Name: Name of library/program. Required
-- Author: Author's name
-- Date: Date file was created
-- Updated: Date file was updated
-- License: License library's source code is released under
-- Requires: Other files the library requires
-- Intro: Introduction comments about the library
--
-- Routine descriptor tags:
--
-- Routine: Name of the routine. Required
-- Author: Aurthor of the routine
-- Date: Date routine was created
-- Updated: Date routine was updated
-- Platform: Platform the routine runs on
-- (General, WIN32, DOS32, Linux, FreeBSD)
-- Syntax: An illustration of the usage syntax
-- Description: A description of what the routine does
-- Comments: Extra comments about the routine
-- Example: A more example to illustrate usage
-- Example Program: The name/location of an example program if such
-- a program exists
-- See Also: Lists other related routines in the library
So for the upper() funtion in wildcard.e you'd type:
--------------------------------------------------------------
-- Routine: upper
--
-- Description:
-- Convert an atom or sequence to upper case.
--
-- Example:
--
-- s = upper("Euphoria")
-- -- s is "EUPHORIA"
--
-- a = upper('g')
-- -- a is 'G'
--
-- s = upper({"Euphoria", "Programming"})
-- -- s is {"EUPHORIA", "PROGRAMMING"}
--
-- See Also: lower
--------------------------------------------------------------
global function upper(object x)
return x - (x >= 'a' and x <= 'z') * TO_LOWER
end function
and from this you'd get documentation that looks exactly like the official
library documentation (in theory). Whitespace/formatting is ignored where
unimportant.
18. Re: Standard Euphoria Library project
D. Newhall wrote:
>
> I had the same idea a while ago so I started a program to do that. Oddly
> enough I just
> started working on it again and it should be availabel soon. It produces html
> files
> that look like the official Euphoria library routine documentation.
>
> Here's how it works (taken from the opening comments to the program (named
> eudoc.ex)):
>
> -- Name: EuDoc - Euphoria documentation program
> -- Author: D. Newhall
> -- License: Mozilla
> -- Date: Feb-7-2005
> -- Updated: Feb-14-2005
> -- Updated: Jul-13-2005
> -- Intro:
> -- EuDoc is a program for automatically creating documentation
> -- for Euphoria libraries. The file created has the same visual
> -- appearance as the library routines list in the official Euphoria
> -- documentation. It can also be used to document programs but in a
> -- more limited scope.
> --
> -- For EuDoc to work you first need to document your program using these
> tags.
> -- The tags are case insensitive and need not be in any order but it's highly
> -- recommended that you use the capitalization scheme and order shown for
> -- better clarity.
> --
> -- File secriptor tags:
> --
> -- Name: Name of library/program. Required
> -- Author: Author's name
> -- Date: Date file was created
> -- Updated: Date file was updated
> -- License: License library's source code is released under
> -- Requires: Other files the library requires
> -- Intro: Introduction comments about the library
> --
> -- Routine descriptor tags:
> --
> -- Routine: Name of the routine. Required
> -- Author: Aurthor of the routine
> -- Date: Date routine was created
> -- Updated: Date routine was updated
> -- Platform: Platform the routine runs on
> -- (General, WIN32, DOS32, Linux, FreeBSD)
> -- Syntax: An illustration of the usage syntax
> -- Description: A description of what the routine does
> -- Comments: Extra comments about the routine
> -- Example: A more example to illustrate usage
> -- Example Program: The name/location of an example program if such
> -- a program exists
> -- See Also: Lists other related routines in the library
>
>
> So for the upper() funtion in wildcard.e you'd type:
>
> --------------------------------------------------------------
> -- Routine: upper
> --
> -- Description:
> -- Convert an atom or sequence to upper case.
> --
> -- Example:
> --
> -- s = upper("Euphoria")
> -- -- s is "EUPHORIA"
> --
> -- a = upper('g')
> -- -- a is 'G'
> --
> -- s = upper({"Euphoria", "Programming"})
> -- -- s is {"EUPHORIA", "PROGRAMMING"}
> --
> -- See Also: lower
> --------------------------------------------------------------
> global function upper(object x)
> return x - (x >= 'a' and x <= 'z') * TO_LOWER
> end function
>
> and from this you'd get documentation that looks exactly like the official
> library
> documentation (in theory). Whitespace/formatting is ignored where unimportant.
>
I look forward to seeing this program posted soon! :) :) :)
-- Hope that it will be truly "generic" and not one of those
DOS/Windows only programs.
Regards,
Ken Rhodes
100% MicroSoft Free!
19. Re: Standard Euphoria Library project
Kenneth Rhodes wrote:
>
> I look forward to seeing this program posted soon! :) :) :)
> -- Hope that it will be truly "generic" and not one of those
> DOS/Windows only programs.
Nope, actually a good portion was done at my work where my lab uses Linux. Since
it's just a string manipulation program it should work with all versions of
Euphoria.
20. Re: Standard Euphoria Library project
Gordon Webster wrote:
>
> One question ... should we implement a really (really) simple self-documenting
> system?
>
> -- Module: SimpleHashTables.e
> -- Part of the Euphoria Standard Library
> -- Contributed by Joe Coder, July 2005
> --start-eudoc
> -- SimpleHashTables.e
> -- Hashtables of key/value pairs. Keys and values can be any Euphoria Object
> -- Duplicate keys and the removal of duplicates are now also supported.
> --end-eudoc
Without enclosed comments (like /* comments [newline] more comments */, this
kind of documenting would be horribly inefficient. Having to manually manage
all the line breaks? Imagine inserting or deleting text. We need multi-line
commenting before this would be viable.
Please note my paragraph is perfectly justified. :D
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
21. Re: Standard Euphoria Library project
cklester wrote:
>
> Gordon Webster wrote:
> >
> > One question ... should we implement a really (really) simple
> > self-documenting
> > system?
> >
> > -- Module: SimpleHashTables.e
> > -- Part of the Euphoria Standard Library
> > -- Contributed by Joe Coder, July 2005
> > --start-eudoc
> > -- SimpleHashTables.e
> > -- Hashtables of key/value pairs. Keys and values can be any Euphoria Object
> > -- Duplicate keys and the removal of duplicates are now also supported.
> > --end-eudoc
>
> Without enclosed comments (like /* comments [newline] more comments */, this
> kind of documenting would be horribly inefficient. Having to manually manage
> all the line breaks? Imagine inserting or deleting text. We need multi-line
> commenting before this would be viable.
Hmmm... not so sure about that. I've been using this style of documention in
Win32lib for years now and I've not had problems.
> Please note my paragraph is perfectly justified. :D
But is it justifiable? 
--
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria
22. Re: Standard Euphoria Library project
Juergen Luethje wrote:
> For my personal feeling time had come to collect all the good ideas that
> have been posted here recently, and to write them down in order (more or
> less). So you'll now find two files concerning the Euphoria Standard Library
> on my website
> - <a
> href="http://home.arcor.de/luethje/esl/index.htm">http://home.arcor.de/luethje/esl/index.htm</a>
> - <a
> href="http://home.arcor.de/luethje/esl/esl_paper01.htm">http://home.arcor.de/luethje/esl/esl_paper01.htm</a>
>
> I hope this is OK for everyone. The files can stay on my website, or we
> can put them anywhere else -- it doesn't matter for me. We just should
> not have more than one place, where the documents are.
>
> The "papers" are only drafts which will have to be revised, of course.
>
> Regards,
> Juergen
>
Looks good at first glance, I'll read it more in-depth tomorrow.
FWIW, I like Derek Parnell's variable naming method for a coding standard. It
is simple enough to be understood. If you're not aware of it, please search the
EUforum archive, its in there.
=====================================
Too many freaks, not enough circuses.
j.
23. Re: Standard Euphoria Library project
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> > D. Newhall wrote:
> >>
> >> Juergen Luethje wrote:
>
> <big snip>
>
> > One place to look before writing a bunch of new code is Derek Parnell's
> > tk routines <a
> > href="http://www.rapideuphoria.com/toolkits.zip">http://www.rapideuphoria.com/toolkits.zip</a>
> > and other
> > submissions to the archive
> > <a
> > href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?gen=on&keywords=Parnell">http://www.rapideuphoria.com/cgi-bin/asearch.exu?gen=on&keywords=Parnell</a>
> > for some very good ideas.
> >
> > Also Bernie Ryan's Utility Library <a
> > href="http://www.rapideuphoria.com/mixedlib.zip">http://www.rapideuphoria.com/mixedlib.zip</a>
> >
> > Much of the C standard library can be found, especially in Derek's toolkit
> > routines.
>
> Also let's not forget Ricardo Forno's General Functions library, and
> more ... No doubt that there are many "diamonds" among more than 1400
> contributions.
>
> However I think we should not look at all those valuable contributions,
> and then consider what will be the best way to put them all together.
> IMHO we should go the different way: Let's build a solid framework first,
> and then fill that framework with contents.
True. I just think that we should not discount them completely either. There
is something to be said for idea *and* code reuse.
> Furthermore, please see
> - <a
> href="http://home.arcor.de/luethje/esl/index.htm">http://home.arcor.de/luethje/esl/index.htm</a>
> - <a
> href="http://home.arcor.de/luethje/esl/esl_paper01.htm">http://home.arcor.de/luethje/esl/esl_paper01.htm</a>
>
> Regards,
> Juergen
>
=====================================
Too many freaks, not enough circuses.
j.
24. Re: Standard Euphoria Library project
Derek Parnell wrote:
> cklester wrote:
> > Gordon Webster wrote:
> > > One question ... should we implement a really (really) simple
> > > self-documenting
> > > system?
> > >
> > > -- Module: SimpleHashTables.e
> > > -- Part of the Euphoria Standard Library
> > > -- Contributed by Joe Coder, July 2005
> > > --start-eudoc
> > > -- SimpleHashTables.e
> > > -- Hashtables of key/value pairs. Keys and values can be any Euphoria
> > > Object
> > > -- Duplicate keys and the removal of duplicates are now also supported.
> > > --end-eudoc
> >
> > Without enclosed comments (like /* comments [newline] more comments */, this
> > kind of documenting would be horribly inefficient. Having to manually manage
> > all the line breaks? Imagine inserting or deleting text. We need multi-line
> > commenting before this would be viable.
>
> Hmmm... not so sure about that. I've been using this style of documention in
> Win32lib
> for years now and I've not had problems.
That's because you're weird!!! :D
I'm much more for this:
;
Okay, now I can do whatever I want here... I don't have to worry about those
stupid dashes at the beginning of each line. Later, if I need to make revisions,
I don't have to worry about manual line breaks. This is only a concern because
I've done it for in-house projects and I don't do it anymore. :/
--/ -- new end-of-lines-of-comments marker, with current method on this line,
too.
than this:
-- Okay, now I can do whatever I want here... I don't have to worry about those
-- stupid dashes at the beginning of each line. Later, if I need to make
revisions,
-- I don't have to worry about manual line breaks. This is only a concern
because
-- I've done it for in-house projects and I don't do it anymore. :/
especially when it comes time to update the paragraph and insert a sentence
or remove some words.
> > Please note my paragraph is perfectly justified. :D
>
> But is it justifiable?
Demonstrably.
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
25. Re: Standard Euphoria Library project
cklester wrote:
>
> Derek Parnell wrote:
> > cklester wrote:
> > > Gordon Webster wrote:
> > > > One question ... should we implement a really (really) simple
> > > > self-documenting
> > > > system?
> > > >
> > > > -- Module: SimpleHashTables.e
> > > > -- Part of the Euphoria Standard Library
> > > > -- Contributed by Joe Coder, July 2005
> > > > --start-eudoc
> > > > -- SimpleHashTables.e
> > > > -- Hashtables of key/value pairs. Keys and values can be any Euphoria
> > > > Object
> > > > -- Duplicate keys and the removal of duplicates are now also supported.
> > > > --end-eudoc
> > >
> > > Without enclosed comments (like /* comments [newline] more comments */,
> > > this
> > > kind of documenting would be horribly inefficient. Having to manually
> > > manage
> > > all the line breaks? Imagine inserting or deleting text. We need
> > > multi-line
> > > commenting before this would be viable.
> >
> > Hmmm... not so sure about that. I've been using this style of documention in
> > Win32lib
> > for years now and I've not had problems.
>
> That's because you're weird!!! :D
>
> I'm much more for this:
>
> /-- new start of lines of comments marker
> Okay, now I can do whatever I want here... I don't have to worry about those
> stupid dashes at the beginning of each line. Later, if I need to make
> revisions,
> I don't have to worry about manual line breaks. This is only a concern because
> I've done it for in-house projects and I don't do it anymore. :/
> --/ -- new end-of-lines-of-comments marker, with current method on this line,
> too.
>
> than this:
>
> -- Okay, now I can do whatever I want here... I don't have to worry about
> those
> -- stupid dashes at the beginning of each line. Later, if I need to make
> revisions,
> -- I don't have to worry about manual line breaks. This is only a concern
> because
> -- I've done it for in-house projects and I don't do it anymore. :/
>
> especially when it comes time to update the paragraph and insert a sentence
> or remove some words.
>
I use a tool to format the text into presentable reading format, the source code
documentation is not meant to be the the finished product. I update paragraphs
and add/delete words all the time but the formatter makes it all pretty again for
me.
--
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria
26. Re: Standard Euphoria Library project
- Posted by Gordon Webster <gwalias-bb at yahoo.com>
Jul 18, 2005
-
Last edited Jul 19, 2005
cklester wrote:
>
> Derek Parnell wrote:
> > cklester wrote:
> > > Gordon Webster wrote:
> > > > One question ... should we implement a really (really) simple
> > > > self-documenting
> > > > system?
> > > >
> > > > -- Module: SimpleHashTables.e
> > > > -- Part of the Euphoria Standard Library
> > > > -- Contributed by Joe Coder, July 2005
> > > > --start-eudoc
> > > > -- SimpleHashTables.e
> > > > -- Hashtables of key/value pairs. Keys and values can be any Euphoria
> > > > Object
> > > > -- Duplicate keys and the removal of duplicates are now also supported.
> > > > --end-eudoc
> > >
> > > Without enclosed comments (like /* comments [newline] more comments */,
> > > this
> > > kind of documenting would be horribly inefficient. Having to manually
> > > manage
> > > all the line breaks? Imagine inserting or deleting text. We need
> > > multi-line
> > > commenting before this would be viable.
> >
> > Hmmm... not so sure about that. I've been using this style of documention in
> > Win32lib
> > for years now and I've not had problems.
>
> That's because you're weird!!! :D
>
> I'm much more for this:
>
> /-- new start of lines of comments marker
> Okay, now I can do whatever I want here... I don't have to worry about those
> stupid dashes at the beginning of each line. Later, if I need to make
> revisions,
> I don't have to worry about manual line breaks. This is only a concern because
> I've done it for in-house projects and I don't do it anymore. :/
> --/ -- new end-of-lines-of-comments marker, with current method on this line,
> too.
>
> than this:
>
> -- Okay, now I can do whatever I want here... I don't have to worry about
> those
> -- stupid dashes at the beginning of each line. Later, if I need to make
> revisions,
> -- I don't have to worry about manual line breaks. This is only a concern
> because
> -- I've done it for in-house projects and I don't do it anymore. :/
>
> especially when it comes time to update the paragraph and insert a sentence
> or remove some words.
>
> > > Please note my paragraph is perfectly justified. :D
> >
> > But is it justifiable?
>
> Demonstrably.
>
> -=ck
> "Programming in a state of EUPHORIA."
> <a
> href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>
>
Multi-line comments might be nice, but they're not valid Eu syntax
at the moment and therefore moot.
Anyway, I don't think that the dashed lines are so bad ...
they make it easy to see what's compiled and what's not and since
they are what we have to work with right now, I would propose that
we must stick with them.
... and please, please, please, nobody suggest code preprocessors!
The standard library modules must be VANILLA euphoria that compiles
right out of the box without dependencies on any other language
"bolt-ons" that will only add complexity.
It seems like many of us here love the almost zen-like brevity and
simplicity of Euphoria or we'd be using other, uglier languages. I
feel strongly that we should strive for this same brevity and
simplicity in the standard library. If this documentation idea is
going to detract from that, I would say let's scrap it - but if we do
decide to go with it, let's keep it really (really (really)) simple.
Best
Gordon
27. Re: Standard Euphoria Library project
- Posted by Vincent <darkvincentdude at yahoo.com>
Jul 18, 2005
-
Last edited Jul 19, 2005
Gordon Webster wrote:
> Multi-line comments might be nice, but they're not valid Eu syntax
> at the moment and therefore moot.
VEEU supports multi-line comments using the "-[", and "-]" delimeters.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
28. Re: Standard Euphoria Library project
- Posted by Gordon Webster <gwalias-bb at yahoo.com>
Jul 18, 2005
-
Last edited Jul 19, 2005
Vincent wrote:
>
> Gordon Webster wrote:
>
> > Multi-line comments might be nice, but they're not valid Eu syntax
> > at the moment and therefore moot.
>
> VEEU supports multi-line comments using the "-[", and "-]" delimeters.
>
I presume by "VEEU" you mean Visual Euphoria?
Maybe I misunderstood, but I thought that the Standard Library Project
would be based upon the official releases of Euphoria from RDS.
Gordon
29. Re: Standard Euphoria Library project
- Posted by D. Newhall <derek_newhall at yahoo.com>
Jul 18, 2005
-
Last edited Jul 19, 2005
Gordon Webster wrote:
>
> Vincent wrote:
snip
> > VEEU supports multi-line comments using the "-[", and "-]" delimeters.
> >
> I presume by "VEEU" you mean Visual Euphoria?
>
> Maybe I misunderstood, but I thought that the Standard Library Project
> would be based upon the official releases of Euphoria from RDS.
>
VEEU is Vincents Enhanced Euphoria. It's Vincent's attempt to "fix" Euphoria and
add all the stuff we constantly request Rob to do. And yes, the Euphoria Standard
Library should be using the standard interpreter.
30. Re: Standard Euphoria Library project
cklester wrote:
>
> Derek Parnell wrote:
> >
> > Hmmm... not so sure about that. I've been using this style of documention in
> > Win32lib
> > for years now and I've not had problems.
>
> That's because you're weird!!! :D
>
> I'm much more for this:
>
> /-- new start of lines of comments marker
> Okay, now I can do whatever I want here... I don't have to worry about those
> stupid dashes at the beginning of each line. Later, if I need to make
> revisions,
> I don't have to worry about manual line breaks. This is only a concern because
> I've done it for in-house projects and I don't do it anymore. :/
> --/ -- new end-of-lines-of-comments marker, with current method on this line,
> too.
>
> than this:
>
> -- Okay, now I can do whatever I want here... I don't have to worry about
> those
> -- stupid dashes at the beginning of each line. Later, if I need to make
> revisions,
> -- I don't have to worry about manual line breaks. This is only a concern
> because
> -- I've done it for in-house projects and I don't do it anymore. :/
>
> especially when it comes time to update the paragraph and insert a sentence
> or remove some words.
>
I use the same style as Derek. My editor allows me to comment and uncomment
multiple lines, so it's pretty easy to revise some comments.
Matt Lewis
31. Re: Standard Euphoria Library project
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
32. Re: Standard Euphoria Library project
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Jul 25, 2005
-
Last edited Jul 26, 2005
Jason Gade wrote:
<snip>
> FWIW, I like Derek Parnell's variable naming method for a coding
> standard. It is simple enough to be understood. If you're not aware
> of it, please search the EUforum archive, its in there.
I personally know Derek (P.)'s method.
There has been some discussion of this point, no?
I'm sorry, I have lost track of it. Has there been an agreement?
Regards,
Juergen
33. Re: Standard Euphoria Library project
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Jul 25, 2005
-
Last edited Jul 26, 2005
I'm very sorry for the late reply.
Gordon Webster wrote:
> One question ... should we implement a really (really) simple self-documenting
> system? I'm thinking of Python's system where the first block of comments
> after the start of a module or procedure are treated as documentation for the
> module or procedure itself and can be parsed out for documentation purposes.
> We might even have a little tag for the lines that should be parsed so that
> authors could have some control to distinguish "doc" lines and other comments.
>
> Here's an example of how it might look ...
>
> -- Module: SimpleHashTables.e
> -- Part of the Euphoria Standard Library
> -- Contributed by Joe Coder, July 2005
> --start-eudoc
> -- SimpleHashTables.e
> -- Hashtables of key/value pairs. Keys and values can be any Euphoria Object
> -- Duplicate keys and the removal of duplicates are now also supported.
> --end-eudoc
>
> <some declarations and other code here>
>
> function hashTableGet(integer hashtable, object key)
> -- 21st July 2005, Joe Coder's fixed the bug that arose with duplicate keys
> --start-eudoc
> -- Function hashTableGet
> -- Returns the object that is the 'value' in the key/value pair specified
> -- by the supplied key. The constant HASHTABLENULL is returned in the event
> -- that the specified key does not exist in the current table
> --end-eudoc
> <some function code here>
> end function
>
> This way, all the procedure signatures could be parsed out with their
> documentation and turned into text or html.
>
> If you wanted more detail, this model could easily be extended to be more
> like 'javadoc' where authors and version dates etc. can also be specified.
> I personally think this is overkill. When I'm looking for a description of
> how to use a Java hash table, I don't normally care who wrote it or what
> version number we're at as long as it's the current official release. Most
> times I just want to know how to use that library's functionality in my
> code. That more detailed stuff can (and should) be included in normal
> comments for those who need it but kept out of the 'eudoc' blocks to make
> the documentation more concise and readable.
>
> What do you think?
I like it, and there seems to be agreement here, right?
I've added a corresponding note to
<http://home.arcor.de/luethje/esl/road_map.htm#doc>.
Maybe that note should be more detailed?
Regards,
Juergen
34. Re: Standard Euphoria Library project
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> <snip>
>
> > FWIW, I like Derek Parnell's variable naming method for a coding
> > standard. It is simple enough to be understood. If you're not aware
> > of it, please search the EUforum archive, its in there.
>
> I personally know Derek (P.)'s method.
> There has been some discussion of this point, no?
> I'm sorry, I have lost track of it. Has there been an agreement?
>
> Regards,
> Juergen
I think the result was that we were going to keep it based close to Rob's method
of coding instead. This is for uniformity with the official include files
released with the interpreter. However, the possiblity of using different coding
styles inside of routines where no one would see them was discussed but I think
it was thought to break coding conformity enough to be confusing to maintainers.
35. 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
36. Re: Standard Euphoria Library project
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
