1. built-ins and include files
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
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
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
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
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
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
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
-
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
