1. Rob Idea for dynamic include
- Posted by Bernie Ryan <LockCityData at CS.COM> Feb 27, 2000
- 494 views
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
- 431 views
- 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
- 432 views
- 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
- 457 views
- 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
- 458 views
- 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
- Posted by Bernie Ryan <LockCityData at CS.COM> Feb 28, 2000
- 446 views
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
- 432 views
- 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
- 439 views
- 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
- Posted by Colin Taylor <ctaylor at ACCESS.INET.CO.TH> Feb 29, 2000
- 452 views
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
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Feb 29, 2000
- 449 views
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
- Posted by Everett Williams <rett at GVTC.COM> Feb 29, 2000
- 442 views
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
- 429 views
- 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 >