OpenEuphoria

Re: ESL - where to put some routines

• Posted by D. Newhall <derek_newhall at yahoo.com> Jul 25, 2005
• 513 views

Jason Gade wrote:
> 
> Juergen Luethje wrote:
> > 
> > 
> > Hi all,
> > 
> > for ESL a separate file 'boolean.e' was proposed, that will contain the
> > constants TRUE, FALSE and the type boolean().
> > 
> > If we establish such a file, what shall we do with the remaining types
> > in <a
> > href="http://home.arcor.de/luethje/esl/types.htm">http://home.arcor.de/luethje/esl/types.htm</a>
> > ?
> > 
> > - routine_no(x)  or  rtnid(x)
> >   Returns TRUE if and only if x is a valid routine_id.
> > 
> > - file_no(x)
> >   Returns TRUE if and only if x is a valid file number.
> > 
> > And where shall we put the enum routines (maybe in 'seqops.e'), and
> > where the ignore() procedure (if we decide to implement it)?
> > 
> > Regards,
> >    Juergen
> > 
> 
> Although I hate planning as much as the next programmer, we need to 
> figure out an include hierarchy for ESL.
> 
> At the top level we should have ESL.e to include *everything*.
> 
> For constants we should have a constants.e for stuff like TRUE and FALSE 
> which is included in every include that requires it.
> 
> routine_number() and file_number() should be included with types.e with 
> lots of other types.
> 
> enum() and ignore() or VOID should be included with types.e.
> 
I disagree because when do you include everything from the include files that
come with Euphoria? Most people don't, they just include what they need. If
you're parsing test you only need get.e and wildcard.e whereas if you're writting
a game you'd use graphics.e. Also, just like the supplied Euphoria includes we
should only package the routines/types/constants by domain and not type. The
constants TRUE and FALSE only make sence when used alongside a boolean type (OK,
not particularly but for the most part it makes sence).

If we include a constants.e and a boolean.e this could happen: 
A programmer writting a ray tracer uses an include file submitted to the archive
that uses the Library. When he runs his program it crashes saying the constant
TRUE has already been defined. He searches through all his files and finds an
"include constants.e" statement placed in one of the include files he was using.
He replaces it with "include boolean.e" because he needs the boolean type. Now
when he runs it he gets an error saying constant FOO is not defined because it
was needed by the library and was defined in constants.e. Now he goes bakc to the
file and includes types.e (since all he types are in there) but, alas, when he
runs his program it crashes because he already defined his own point type that's
drastically different from the one used in math.e and types.e. He now has a
choice of rewritting his entire program to use the Library's point type or not
using the file submitted to the archive. Chances are he's not going to rewrite
his entire program to use a single file so now that file in the archive are
useless to him (and probably many others) because it redefined things in many
places.

I could *EASILY* see this happening to me as well as many other people.

Also, is writting a routine_no and file_no type even really possible? I
mentioned to Juergen that both are simply positive integers that are allocated
when routine_id() or open() is called; so to know what numbers are valid we'd
have to keep track of the number of times routine_id() and open() are called,
correct? This goes far above making a library into making what's essentially a
preprocessor or we could redefine routine_id() and open() but I really don't
think we want to do that...