1. Include dir as built-in function
- Posted by Marco Achury <achury at c??tv.net> Apr 28, 2008
- 649 views
- Last edited Apr 29, 2008
There are some some simple functions at file.e, I thing may be included as built-in, they are simple calls to machine procedure: dir() current_dir() chdir() check_break() Also will be great to have: copy_file() ren_file() mv_file() In the Archive there is a code from AKU to make these things at Windows. +-+-+-+-+-+-+-+ Marco A. Achury Caracas, Venezuela
2. Re: Include dir as built-in function
- Posted by Michael J. Sabal <m_sabal at ?a?oo.com> Apr 29, 2008
- 624 views
Marco Achury wrote: > > > There are some some simple > functions at file.e, I thing > may be included as built-in, > they are simple calls to > machine procedure: > > dir() > current_dir() > chdir() > check_break() > > Also will be great to have: > copy_file() > ren_file() > mv_file() > > In the Archive there is a code > from AKU to make these things > at Windows. > > > +-+-+-+-+-+-+-+ > Marco A. Achury > Caracas, Venezuela No, no, no. Keep the core minimal. File manipulation routines should be an include file, as it is now. By all means improve the cross-platform compatibility, but keep anything that doesn't absolutely need to be part of the core out of it. That's one of the key points that makes Euphoria different and better than other languages.
3. Re: Include dir as built-in function
- Posted by Michael J. Sabal <m_sabal at yah?o.?om> Apr 29, 2008
- 640 views
Marco Achury wrote: > > > There are some some simple > functions at file.e, I thing > may be included as built-in, > they are simple calls to > machine procedure: > > dir() > current_dir() > chdir() > check_break() > > Also will be great to have: > copy_file() > ren_file() > mv_file() > > In the Archive there is a code > from AKU to make these things > at Windows. > > > +-+-+-+-+-+-+-+ > Marco A. Achury > Caracas, Venezuela No, no, no. Keep the core minimal. File manipulation routines should be an include file, as it is now. By all means improve the cross-platform compatibility, but keep anything that doesn't absolutely need to be part of the core out of it. That's one of the key points that makes Euphoria different and better than other languages.
4. Re: Include dir as built-in function
- Posted by Marco Achury <achury at can?v.?et> Apr 29, 2008
- 636 views
I understand that is important to keep the interpreter small. But I don't understand why there are a lot of function at include as: global function dir(sequence name) -- returns directory information, given the name -- of a file or directory. Format returned is: -- { -- {"name1", attributes, size, year, month, day, hour, minute, second}, -- {"name2", ... }, -- } return machine_func(M_DIR, name) end function The function is really just one line of code. M_DIR is a constant with value 22. The include files are plenty of this kind of functions. ¿How big is the effect on interpreter speed/size if some of this functions become internals. Another example is function wait_key(), this is strongly used on text mode apps, like ED.EX. global function wait_key() -- Get the next key pressed by the user. -- Wait until a key is pressed. return machine_func(M_WAIT_KEY, 0) end function M_WAIT_KEY is a constant = 26 What gives better performance? As built-in or as include? +-+-+-+-+-+-+-+ Marco A. Achury Caracas, Venezuela
5. Re: Include dir as built-in function
- Posted by Jason Gade <jaygade at ?ahoo.co?> Apr 29, 2008
- 630 views
Marco Achury wrote: > > I understand that is important to keep the interpreter small. > > But I don't understand why there are a lot of function at include as: > > global function dir(sequence name) > -- returns directory information, given the name > -- of a file or directory. Format returned is: > -- { > -- {"name1", attributes, size, year, month, day, hour, minute, second}, > -- {"name2", ... }, > -- } > return machine_func(M_DIR, name) > end function > > The function is really just one line of code. M_DIR is a constant > with value 22. > > The include files are plenty of this kind of functions. > ¿How big is the effect on interpreter speed/size if some > of this functions become internals. > > Another example is function wait_key(), this is strongly used on > text mode apps, like ED.EX. > > global function wait_key() > -- Get the next key pressed by the user. > -- Wait until a key is pressed. > return machine_func(M_WAIT_KEY, 0) > end function > M_WAIT_KEY is a constant = 26 > > What gives better performance? As built-in > or as include? > > +-+-+-+-+-+-+-+ > Marco A. Achury > Caracas, Venezuela Those functions are internal (hence the machine_func() call). The reason is to avoid polluting the namespace and also probably to keep the actual reserved words in the parser relatively small. I think. Someone else could probably explain it better. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
6. Re: Include dir as built-in function
- Posted by Julio C. Galaret Viera <galaret at ad?net.co?.uy> Apr 29, 2008
- 634 views
Michael J. Sabal wrote: > > Marco Achury wrote: > > > > > > There are some some simple > > functions at file.e, I thing > > may be included as built-in, > > they are simple calls to > > machine procedure: > > > > dir() > > current_dir() > > chdir() > > check_break() > > > > Also will be great to have: > > copy_file() > > ren_file() > > mv_file() > > > > In the Archive there is a code > > from AKU to make these things > > at Windows. > > > > > > +-+-+-+-+-+-+-+ > > Marco A. Achury > > Caracas, Venezuela > > No, no, no. Keep the core minimal. File manipulation routines should be > an include file, as it is now. By all means improve the cross-platform > compatibility, but keep anything that doesn't absolutely need to be part of > the core out of it. That's one of the key points that makes Euphoria > different and better than other languages. I would add... not popular. JG
7. Re: Include dir as built-in function
- Posted by CChris <christian.cuvier at agricul?ur?.gouv.fr> Apr 29, 2008
- 655 views
Michael J. Sabal wrote: > > Marco Achury wrote: > > > > > > There are some some simple > > functions at file.e, I thing > > may be included as built-in, > > they are simple calls to > > machine procedure: > > > > dir() > > current_dir() > > chdir() > > check_break() > > > > Also will be great to have: > > copy_file() > > ren_file() > > mv_file() > > > > In the Archive there is a code > > from AKU to make these things > > at Windows. > > > > > > +-+-+-+-+-+-+-+ > > Marco A. Achury > > Caracas, Venezuela > > No, no, no. Keep the core minimal. File manipulation routines should be > an include file, as it is now. By all means improve the cross-platform > compatibility, but keep anything that doesn't absolutely need to be part of > the core out of it. That's one of the key points that makes Euphoria > different and better than other languages. And less easy to use. CChris
8. Re: Include dir as built-in function
- Posted by Michael J. Sabal <m_sabal at y?hoo.c?m> Apr 29, 2008
- 632 views
CChris wrote: > > > And less easy to use. > > CChris If Euphoria is so difficult, why aren't you sticking with C, C++, or BASIC? Not every program requires file manipulation. In fact, far more of my programs use date manipulation than file manipulation by a factor of 4. Does that mean we should include datetime in the core? I don't think so. I have no problem expanding the language to 10 gigabytes if need be, as long as the code I distribute at the end of the day still runs as fast as it does today, takes me no longer to code, doesn't break my existing set of libraries, and still binds to less than 1 megabyte. Changes to the core will have an impact on that, changes to standard includes won't.
9. Re: Include dir as built-in function
- Posted by CChris <christian.cuvier at agricultur?.?ouv.fr> Apr 29, 2008
- 655 views
Michael J. Sabal wrote: > > CChris wrote: > > > > > > And less easy to use. > > > > CChris > > If Euphoria is so difficult, why aren't you sticking with C, C++, or BASIC? I have just done that. You may notice that I haven't contributed anything substantial for a long time. My still being around is because of win32lib, because of the way and timing of the release of 70.1. > Not every program requires file manipulation. In fact, far more of my > programs use date manipulation than file manipulation by a factor of 4. Does > that mean we should include datetime in the core? I don't think so. > Both datetime.e and a boosted file.e should be there, to cater for both. > I have no problem expanding the language to 10 gigabytes if need be, as long > as the code I distribute at the end of the day still Now is the interesting part: > runs as fast as it does > today, Changes in the core that reduce the emitted IL will not only do that, but speed up things. > takes me no longer to code, The less the languege provides, the more coding and, worse, debugging time it takes. > doesn't break my existing set of libraries, Then archive he current version with which they were built, for 100% safety, if you really require this level. > and still binds to less than 1 megabyte. Doesn't this depend on source size? I don't understand. > Changes to the core will have an > impact on that, changes to standard includes won't. Completely wrong. Actually, it is often the other way round: * because builtins are faster and more efficient, * because it is easier to override builtins than global symbols in include files; * because the binder removes all symbols that are not used, so that the generated executable has the same size regardless. And if the language was providing proper packaging, you could protect your libs against any name clashes. CChris
10. Re: Include dir as built-in function
- Posted by Matt Lewis <matthewwalkerlewis at ?mail.?om> Apr 29, 2008
- 656 views
- Last edited Apr 30, 2008
CChris wrote: > > And if the language was providing proper packaging, you could protect your > libs against any name clashes. Except that we already have all of the tools needed to protect against name clashes, for whatever definition of proper packaging you like. Matt