1. built-ins and include files
- Posted by Bernie Ryan <bwryan at PCOM.NET> Feb 03, 2000
- 441 views
Why are some features implemented by using machine level constants. If there is a machine-level constant for a given feature then why isn't that feature just implemented as a built-in feature instead of requiring an include file and the use of overhead code in the include file. A good example is the seek command why is it necessary to implement that feature via the file.e include file. This requires the user to use some built-ins and some include files to do standard file i/o. This is only one example of a built-in being implemented via a include file, there are many others. dll.e, graphics.e, get.e, mouse.e, machine.e and etc. Using these machine-level constant does nothing to aid the user in using, modifying or extending the language. It only requires user to add more include files and causes more naming conflicts. If a function has a machine-level constant then It should be built-in and not implemented in a include file. The include files should only be should be used for user add-ons Bernie
2. Re: built-ins and include files
- Posted by Irv Mullins <irv at ELLIJAY.COM> Feb 03, 2000
- 403 views
On Thu, 03 Feb 2000, you wrote: > Why are some features implemented by using machine level > > constants. If there is a machine-level constant for a given feature > > then why isn't that feature just implemented as a built-in feature > > instead of requiring an include file and the use of overhead code in > > the include file. A good example is the seek command why is it necessary > > to implement that feature via the file.e include file. This requires > > the user to use some built-ins and some include files to do standard > > file i/o. This is only one example of a built-in being implemented > > via a include file, there are many others. dll.e, graphics.e, get.e, > > mouse.e, machine.e and etc. > > Using these machine-level constant does nothing to aid the user in > > using, modifying or extending the language. It only requires user to > > add more include files and causes more naming conflicts. > > If a function has a machine-level constant then It should be built-in > > and not implemented in a include file. The include files should only > > be should be used for user add-ons Because these are platform dependent. The code varies between DOS, Linux, and whatever comes next. Makes sense to keep all such things separate. DOS graphics aren't much use on Windows, for example, so why include them in the base run-time package? Irv
3. Re: built-ins and include files
- Posted by Bernie Ryan <bwryan at PCOM.NET> Feb 03, 2000
- 429 views
On Thu, 3 Feb 2000 14:40:19 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote: >Because these are platform dependent. The code varies between DOS, Linux, and >whatever comes next. >Makes sense to keep all such things separate. DOS graphics aren't much use on >Windows, for example, so why include them in the base run-time package? > Irv That only takes 1 constant CONSTANT PLATFORM = whateverplatform to turn on or change internal functions for various platforms. Bernie
4. Re: built-ins and include files
- Posted by Everett Williams <rett at GVTC.COM> Feb 03, 2000
- 408 views
Feeling a little spacey today, or are you just leaving room for disagreement? Couldn't resist One, some of them aren't very clean or complete, and two, some really are OS specific functions. Including them in the base would require a really sharp eye to common functionality for all platforms and OS's. Even though the code in the base would be different for each version, the functionality would have to be almost exactly the same. Maybe Rob needs to put in a "plugin" or "add in" interface for platform specific code to work with the base as if it were part of the base. Hmmmmmmmm...might solve a lot of other situations. IO is ugly in so many ways. Since Sun is releasing NFS, maybe all IO could be written to that interface. Not sure what that would entail, but it is a well established cross-platform IO standard. Another option would be a "bound" base which would be essentially indistinguishable from what you ask for except for the constants...that shouldn't be a problem after the next release, I hope. Everett L.(Rett) Williams rett at gvtc.com Bernie Ryan wrote: >Why are some features implemented by using machine level > > constants. If there is a machine-level constant for a given feature > > then why isn't that feature just implemented as a built-in feature > > instead of requiring an include file and the use of overhead code in > > the include file. A good example is the seek command why is it necessary > > to implement that feature via the file.e include file. This requires > > the user to use some built-ins and some include files to do standard > > file i/o. This is only one example of a built-in being implemented > > via a include file, there are many others. dll.e, graphics.e, get.e, > > mouse.e, machine.e and etc. > > Using these machine-level constant does nothing to aid the user in > > using, modifying or extending the language. It only requires user to > > add more include files and causes more naming conflicts. In a phrase, name spaces. > If a function has a machine-level constant then It should be built-in > > and not implemented in a include file. The include files should only > > be should be used for user add-ons > > Bernie
5. Re: built-ins and include files
- Posted by Robert Craig <rds at ATTCANADA.NET> Feb 04, 2000
- 400 views
Bernie Ryan writes: > Why are some features implemented by using machine level > constants. If there is a machine-level constant for a given feature > then why isn't that feature just implemented as a built-in feature > instead of requiring an include file and the use of overhead code > in the include file. 1. It cuts down on the number of pre-declared symbols that would interfere with names that you might want to use for your own variables and routines. i.e. it avoids "polluting the namespace" with lots of symbols that you don't need in all programs. As Euphoria grows there will be more standard include files and more symbols. 2. It saves some memory since built-in symbols need a symbol table entry that contains their name and a bunch of other information. 3. While the code to implement all of these machine functions is always present in the interpreter, at least the code to check the number and type of arguments can be eliminated since the machine functions are assumed to be called correctly. If you want to call a machine function directly to save the call overhead, go ahead, but you may see a crash if you pass incorrect arguments. In most cases where the overhead of the Euphoria call is going to matter, I've tried to make things into a built-in function. The overhead clearly won't matter if you are doing something like changing the graphics mode, changing the appearance of the cursor etc. People don't do those things a million times in a tight loop. Some routines, such as sort() and get() are written purely in Euphoria. In these cases you do save all of the memory required for the routine when you don't include it. These routines are written in Euphoria rather than being implemented as builtins because the performance seems adequate, and it saves space in the interpreter. It's also easier to code these things in Euphoria, and it may be educational for people to see how they are coded. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
6. Re: built-ins and include files
- Posted by Irv Mullins <irv at ELLIJAY.COM> Feb 03, 2000
- 404 views
On Thu, 03 Feb 2000, you wrote: > On Thu, 3 Feb 2000 14:40:19 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote: > > >Because these are platform dependent. The code varies between DOS, Linux, > and > >whatever comes next. > >Makes sense to keep all such things separate. DOS graphics aren't much use > on > >Windows, for example, so why include them in the base run-time package? > > > Irv > > That only takes 1 constant > > CONSTANT PLATFORM = whateverplatform > > to turn on or change internal functions for various platforms. If code for all the platforms is included in the interpreter - yes. Do you really want DOS / LiNUX / Windows graphics code in the Euphoria interpreter, along with DOS / LINUX / Windows interrupts for disk i/o, screen i/o, real-time clock, etc.etc... when you can never use more than one at a time? Irv
7. Re: built-ins and include files
- Posted by Bernie Ryan <bwryan at PCOM.NET> Feb 03, 2000
- 393 views
On Thu, 3 Feb 2000 16:32:20 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote: >If code for all the platforms is included in the interpreter - yes. >Do you really want DOS / LiNUX / Windows graphics code in the Euphoria >interpreter, along with DOS / LINUX / Windows interrupts for disk i/o, screen >i/o, real-time clock, etc.etc... when you can never use more than one at a time? Irv I would think that when a application was bound that any unsed function would be strip out. At least that is what should happen. Bernie
8. Re: built-ins and include files
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM> Feb 03, 2000
- 407 views
- Last edited Feb 04, 2000
Hello, > Irv > > I would think that when a application was bound that any unsed > > function would be strip out. At least that is what should happen. > > Bernie I like that idea but I don't believe that it is implimented (as of now). There might be a reason as well... like routine_id () and all kinds of invisible, internal optomizations that would be a hassle to work around. Lewis Townsend ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com