1. ESL - where to put some routines
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 http://home.arcor.de/luethje/esl/types.htm ?
- 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
--
Have you read a good program lately?
2. Re: ESL - where to put some routines
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 http://home.arcor.de/luethje/esl/types.htm ?
>
> - 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.
--
==============================
Too many freaks, not enough circuses.
j.
3. Re: ESL - where to put some routines
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...
4. Re: ESL - where to put some routines
D. Newhall wrote:
<snip>
> 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...
Pete (Lomax) had written:
| global type rtnid(object r)
| return not equal(r,-1)
| end type
|
| ...
|
| PS the type above should be part of the new standard library.
In %EUDIR%\demo\langwar\sched.e it reads:
| type valid_routine_id(integer id)
| return id >= 0 and id <= 1000
| end type
I am thinking of something along these lines.
Regards,
Juergen
5. Re: ESL - where to put some routines
Juergen Luethje wrote:
>
> D. Newhall wrote:
>
> <snip>
>
> Pete (Lomax) had written:
>
> | global type rtnid(object r)
> | return not equal(r,-1)
> | end type
> |
> | ...
> |
> | PS the type above should be part of the new standard library.
>
>
> In %EUDIR%\demo\langwar\sched.e it reads:
>
> | type valid_routine_id(integer id)
> | return id >= 0 and id <= 1000
> | end type
>
>
> I am thinking of something along these lines.
Ah, OK. That could work but it wouldn't really be for valid routine ids because
you could pass 649 or something and have no routine using that id and it'd still
be "valid". Also, there's no real difference between that and positive_integer.
6. Re: ESL - where to put some routines
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Jul 25, 2005
-
Last edited Jul 26, 2005
On Mon, 25 Jul 2005 08:21:19 -0700, "D. Newhall"
<guest at RapidEuphoria.com> wrote:
>Ah, OK. That could work but it wouldn't really be for valid routine
>ids because you could pass 649 or something and have no routine using
>that id and it'd still be "valid".
Yes.
>Also, there's no real difference between that and positive_integer.
There is however a world of difference between
positive_integer rFunc
and
routine_number rFunc
Pete
