1. Include dir as built-in function
- Posted by Marco Achury <achury at c??tv.net>
Apr 28, 2008
-
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
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
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
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
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
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
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
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
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
-
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
