1. Rob Idea for dynamic include
Rob:
I have an idea of how to implement a simple conditional
include in your Euphoria Interpreter.
Add a new keyword called IGNORE ( or what ever you want to call it )
Then I do something like the following:
if IWANTTOINCLUDETHIS then
IGNORE
end if
-- include thisfile.e
Then when your interperter sees the keyword "IGNORE" and It skips
over the first -- comment operator that it sees and continues on
parsing the program in the normal way.
This would only require that you added a additional keyword and a
a little code to bypass the -- comment operator
Bernie
2. Re: Rob Idea for dynamic include
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Feb 27, 2000
-
Last edited Feb 28, 2000
On Sun, 27 Feb 2000, Bernie wrote:
> Rob:
> I have an idea of how to implement a simple conditional
> include in your Euphoria Interpreter.
> Add a new keyword called IGNORE ( or what ever you want to call it )
> Then I do something like the following:
>
> if IWANTTOINCLUDETHIS then
> IGNORE
> end if
>
> -- include thisfile.e
>
> Then when your interperter sees the keyword "IGNORE" and It skips
> over the first -- comment operator that it sees and continues on
> parsing the program in the normal way.
Wouldn't it be clearer to just allow us to use:
if CONDITION then
include thisfile.e
end if
Irv
3. Re: Rob Idea for dynamic include
- Posted by Kat <gertie at ZEBRA.NET>
Feb 27, 2000
-
Last edited Feb 28, 2000
----- Original Message -----
From: "Irv Mullins" <irv at ELLIJAY.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, February 27, 2000 7:00 PM
Subject: Re: Rob Idea for dynamic include
> On Sun, 27 Feb 2000, Bernie wrote:
> > Rob:
> > I have an idea of how to implement a simple conditional
> > include in your Euphoria Interpreter.
> > Add a new keyword called IGNORE ( or what ever you want to call it )
> > Then I do something like the following:
> >
> > if IWANTTOINCLUDETHIS then
> > IGNORE
> > end if
> >
> > -- include thisfile.e
> >
> > Then when your interperter sees the keyword "IGNORE" and It skips
> > over the first -- comment operator that it sees and continues on
> > parsing the program in the normal way.
>
> Wouldn't it be clearer to just allow us to use:
> if CONDITION then
> include thisfile.e
> end if
Errrr,, i didn't try this, but i assumed this could be done already.
Kat
4. Re: Rob Idea for dynamic include
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Feb 27, 2000
-
Last edited Feb 28, 2000
On Sun, 27 Feb 2000, Kat wrote:
> "Irv Mullins" wrote:
> >
> > Wouldn't it be clearer to just allow us to use:
> > if CONDITION then
> > include thisfile.e
> > end if
>
> Errrr,, i didn't try this, but i assumed this could be done already.
Unfortunately, no. I can't understand why it shouldn't work, but this is
considered an error by the interpreter.
Irv
5. Re: Rob Idea for dynamic include
- Posted by Everett Williams <rett at GVTC.COM>
Feb 27, 2000
-
Last edited Feb 28, 2000
Bernie Ryan wrote:
>Rob:
> I have an idea of how to implement a simple conditional
>
> include in your Euphoria Interpreter.
>
>
> Add a new keyword called IGNORE ( or what ever you want to call it )
>
> Then I do something like the following:
>
> if IWANTTOINCLUDETHIS then
> IGNORE
> end if
>
> -- include thisfile.e
>
> Then when your interperter sees the keyword "IGNORE" and It skips
> over the first -- comment operator that it sees and continues on
> parsing the program in the normal way.
>
> This would only require that you added a additional keyword and a
> a little code to bypass the -- comment operator
>
> Bernie
How does this make the include dynamic. It would make it switchable, but
dynamic to me means something that is alterable at the time of execution
as in "include xxx" where xxx is a variable. Besides, at the moment, all
comments are completely ignored/thrown away. Since includes are only
found in the main line of the code, what would change that would cause
the item to be included/not included since the main line of code does not
repeat itself. I see the need for dynamic includes, but I'd like to know what
this is intended to accomplish. I'm sure there is something obvious here
that I am missing...unfortunately I can't figure out what 
Everett L.(Rett) Williams
rett at gvtc.com
6. Re: Rob Idea for dynamic include
On Sun, 27 Feb 2000 20:00:53 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>Wouldn't it be clearer to just allow us to use:
>if CONDITION then
> include thisfile.e
>end if
>
Irv:
The idea that I was trying to get across was the fact that
it would take a minuimal amount of effort and code by ROB to
implement the feature in Euphoria. The keyword allows the
interpreter to by-pass 1 comment operator and that is all.
It does not break any old code and does not require a lot
of parsing code.
PS: Did you try sending a PAINT message to your listbox
Also rett it is not necessary to send the same message to the user
and the list, most of us monitor the list.
Bernie
7. Re: Rob Idea for dynamic include
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Feb 28, 2000
-
Last edited Feb 29, 2000
I would rather say it was a choice of Robert not to implement dynamic
includes.
There a few down sides .. really.
First of all .. you would need to make a little effort in the error handling
part.
Conditional includes would only make sense when routine overloading is
enabled and a condtionally included file can only *overload* global
routines, not add any new ones.
Imagine the confusion when you have compile time errors that appear on
'some' of the runs .. wouldn't that be .. like asking for trouble ?
Ralf N>
----- Oorspronkelijk bericht -----
Van: Bernie Ryan <LockCityData at CS.COM>
Aan: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Verzonden: maandag 28 februari 2000 15:37
Onderwerp: Re: Rob Idea for dynamic include
> On Sun, 27 Feb 2000 20:00:53 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>
> >Wouldn't it be clearer to just allow us to use:
> >if CONDITION then
> > include thisfile.e
> >end if
> >
>
> Irv:
> The idea that I was trying to get across was the fact that
> it would take a minuimal amount of effort and code by ROB to
> implement the feature in Euphoria. The keyword allows the
> interpreter to by-pass 1 comment operator and that is all.
> It does not break any old code and does not require a lot
> of parsing code.
>
> PS: Did you try sending a PAINT message to your listbox
>
> Also rett it is not necessary to send the same message to the user
> and the list, most of us monitor the list.
>
> Bernie
>
8. Re: Rob Idea for dynamic include
- Posted by Everett Williams <rett at GVTC.COM>
Feb 28, 2000
-
Last edited Feb 29, 2000
Ralf Nieuwenhuijsen wrote:
>I would rather say it was a choice of Robert not to implement dynamic
>includes.
>There a few down sides .. really.
>
>First of all .. you would need to make a little effort in the error handling
>part.
>Conditional includes would only make sense when routine overloading is
>enabled and a condtionally included file can only *overload* global
>routines, not add any new ones.
>
>Imagine the confusion when you have compile time errors that appear on
>'some' of the runs .. wouldn't that be .. like asking for trouble ?
>
>Ralf N>
Power equals danger. If I did dynamic includes, I would expect dynamic
errors...surprise Dynamic includes could be triggered by environmental
conditions or data input. They need not be limited to overloading as they
may have code as well as procedures and functions. Actually, dynamic
includes could cascade, including separately differently named procedures
and functions, followed by an include that will make use of those functions
and procedures. The major objection that I can see to dynamic includes from
the viewpoint of current practice is the need to call the interpreter again at
the resolution of the include. I would love to be able to trigger the
interpreter
in several forms of controllable situation, but there has been no indication of
any willingness to implement anything of the sort.
The most useful reasonably simple one would be an evaluate statement.
The most powerful would be inline functions. A possible compromise would
be a direct call of the interpreter with several options...reevaluate a section
of code and do a dynamic include. Those would both attempt to make the
output of the pass of the interpreter fit with current code. The other use of
such an item might be a way to true modularity of Euphoria code. Call the
interpreter with a separate module of Euphoria code and then pass certain
things to that new module with possible return...that is to say, a native
Euphoria call. Voila, instant modularity with separate development.
Everett L.(Rett) Williams
rett at gvtc.com
9. Re: Rob Idea for dynamic include
Dynamic includes sound pretty hairy. I think that most of us would be very
happy with the ability to do conditional includes at "compile" time (without
having to resort to fancy work-arounds). This would widen the possibility
of the same program running on different operating systems, by selectively
including the appropriate graphics support, etc.
- Colin Taylor
Everett Williams wrote:
> Power equals danger. If I did dynamic includes, I would expect dynamic
> errors...surprise Dynamic includes could be triggered by environmental
> conditions or data input. They need not be limited to overloading as they
> may have code as well as procedures and functions. Actually, dynamic
> includes could cascade, including separately differently named procedures
> and functions, followed by an include that will make use of those
functions
> and procedures. The major objection that I can see to dynamic includes
from
> the viewpoint of current practice is the need to call the interpreter
again at
> the resolution of the include. I would love to be able to trigger the
interpreter
> in several forms of controllable situation, but there has been no
indication of
> any willingness to implement anything of the sort.
>
> The most useful reasonably simple one would be an evaluate statement.
> The most powerful would be inline functions. A possible compromise would
> be a direct call of the interpreter with several options...reevaluate a
section
> of code and do a dynamic include. Those would both attempt to make the
> output of the pass of the interpreter fit with current code. The other use
of
> such an item might be a way to true modularity of Euphoria code. Call the
> interpreter with a separate module of Euphoria code and then pass certain
> things to that new module with possible return...that is to say, a native
> Euphoria call. Voila, instant modularity with separate development.
10. Re: Rob Idea for dynamic include
I disagree with this. Technically there are no difficulties to allow
conditional includes at the top level. It would be no different from how the
interpreter is handling include files now.
However, due to the possible 'problems' I would suggest a different from of
inclusion. For example an 'overload file.ext' which is allowed to be
conditionally included and excluded at the top level. However, this would be
like adding another feature. Doesn't feel right .. so what i left ?
The ability to really dynamically add code: [which is possible!, the code is
append at the end of the current code stack] .. however, this should still
be allowed at the top level only. (to not mess with the normal program flow.
For example:
run_file ("thisfile.ex")
Or
run_file ("thisfile.e")
Which would be allowed at the top level, but it shouldn't be allowed to
really be included .. it can however use any routines already declared. The
only limitation is that all identifers it adds are cleared when the file is
proccesed.
This would keep everything safe, sound, implementable without breaking the
usage, yet maintaining the strictness and program flow order.
Robert, how do you feel about this feature ? Given the limitations here:
- identifer stack is cleared afterwards
- only on the top level. [although this isn't really nessecary]
.....
Ralf N.
nieuwen at xs4all.nl
11. Re: Rob Idea for dynamic include
Colin Taylor wrote:
>Dynamic includes sound pretty hairy. I think that most of us would be very
>happy with the ability to do conditional includes at "compile" time (without
>having to resort to fancy work-arounds). This would widen the possibility
>of the same program running on different operating systems, by selectively
>including the appropriate graphics support, etc.
>
>- Colin Taylor
I would say that this is what we are most likely to get, and it certainly should
help with multienvironment programs. This is what I think Ralf means when
he talks about overloading. What I really want are named includes
implementing prefixing of some sort so that we can quit colliding includes
except when we really mean to.
The dynamic "calls" thing is a completely separate issue and would be
an approach to modularity and separate development within Euphoria. It
could be accomplished by allowing separate copies of the interpreter to
run and call each other or by making the current program serially
reusable or reentrant.
Everett L.(Rett) Williams
rett at gvtc.com
12. Re: Rob Idea for dynamic include
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Feb 29, 2000
-
Last edited Mar 01, 2000
> I would say that this is what we are most likely to get, and it certainly
should
> help with multienvironment programs. This is what I think Ralf means when
> he talks about overloading. What I really want are named includes
> implementing prefixing of some sort so that we can quit colliding includes
> except when we really mean to.
You're right, it was what I meant and you're also right that dynamic calls
would be a completely seperate issue, although it would make 'conditional'
includes, etc. pretty redunant.
Ralf N.
finally awoken from a long euphoric sleep
> The dynamic "calls" thing is a completely separate issue and would be
> an approach to modularity and separate development within Euphoria. It
> could be accomplished by allowing separate copies of the interpreter to
> run and call each other or by making the current program serially
> reusable or reentrant.
>
> Everett L.(Rett) Williams
> rett at gvtc.com
>
