Re: Lobbying
- Posted by "Fam. Nieuwenhuijsen" <nieuwen at XS4ALL.NL> Sep 05, 2000
- 367 views
>I am glad to see you getting back on the list recently. You had >sort of disappeared for a while. Well, I'm glad to be back .. the reason I have these little dissapearrances is usually either that I have nothing to say about a certain subject .. or .. that I'm not really much into euphoria at that moment .... About the no new syntax .. what I meant, was that the already available syntax would be used: include filea.e function geta (object x) return get (x) end function include fileb.e function getb (object x) return get (x) end function print (1, geta(sd)) -- calls geta () .. which calls from filea.e print (1, get(sd)) -- from fileb.e print (1, getb(sd) -- calls getb() .. which calls from fileb.e See, no new syntax ? However, there *is* new functionality. You are free to overload, and including a file which was already included, puts the file on top of the search priority. I think you were assuming I also meant NO new syntax, NO new solution, which was not the case. > - Add (built-in or not) routines that offer dynamical >include files. This dynamic approach should allow for the more >powerfull usages of include files. Such as mixing include files, >alter the code, calling routines with error trapping, etc. It has >the following advantages: >And, a huge amount of management overhead on the programmers part, >along with a surfeit of includes upon includes upon includes. Why? There are a number of features that many people seem to want, however, everyone wants them in a different form. Some need dynamic includes, some need to be able to have the interpreter execute custom made code, many want error trapping and some want to be able to change/alter the namespace of some includes. (make include filea use fileb against its own will .. sort of) ... so many different features, for specialized situations ? why not just have a built-in function to execute and/or shroud euphoria code ? With a few functions it gives all the acces everybody wants, and they can shape it like they want, without making euphoria too complex. >Your approach requires that the programmer have intimate >knowledge of the internals of every include, or over-use includes >out of self defence. The whole point of using other people's >includes is to leverage their knowledge and work. If I have to >know everything that they knew to write the include, what have >I gained. In addition, at some point in this process, some of the >authors are likely to start shrouding their includes. Then, your >technique will really be vulnerable. Well, it won't be vulnerable, but for some situations shrouded files are useless (enforcing routine overloading, etc.) but I feel in the future we're already going to a situation where the interpreter needs to take on the shroud-problems such as conflicting names. Keeping all the routine names in tact will do much good. > - full run time control (very powerfull) >Dynamic includes cannot be allowed without allowing the >interpreter to be dynamically called. Their is nothing simple >about that thought. If we are to get some dynamic control of the >interpreter, that will mean huge changes in the language. I >actually am for some of those changes. I consider the compiler a >shortsighted abomination that does very little for the language. >Dynamic access to the interpreter could make this a direct AI >language like LISP. If you have ever seen the IBM language, now >available independently, called REXX, you would understand the >kind of power that this would mean in a typed language such as >Euphoria. Indeed, extremely powerfull .. program A writes the code of program B and has it executed in real time. Perhaps its a real chalange for Robert, but if we all consider Euphoria to be that good, why not aim for the top .. adjusting the interpreter to allow multiple instances in this way, is nothing more than keeping track of a stack list .. how do you think recursion works currently ? No big thing. > - takes the new compiler into account (dynamically >included routines are off course never compiled, but always >interpreted) >You seem to be contradicting yourself here. What do you mean? If you compile a program that uses dynamic includes, the dynamic includes are not compiled off course. When a routine from a dynamic include is called, it will still be interpretered the old style. No big thing as well, the interpreter's code is for 90% in the c-lib its providing .. I only foresee problems with enforcing the public domain-version. Perhaps compiled programs that use dynamic include files can only be an option for registered users because they aren't allowed to distribute the c-lib alone. Perhaps things a little bit more clear now ? Ralf N.