1. To begin..
.. to begin the discussion, what criteria would count about inclusion and
exclusion of features as either includes or built-ins.
Which made me wonder, a feature can either be:
1) Part of an include-file
2) Built-in to the interpreter
3) Supplied as an DLL / Lib (linux) or Machine code (jak: dos)
This generates some ideas, we should be able to 'dynamically' link to
libraries in DOS32 as well.
Consider these attributes of platform related features:
1) They have to be fast and clean. No euphoria code. (or ?)
2) THey are bound to one version of the interpreter, or at least differ
amoung the different versions.
Why not kick such platform related features out of the interpreter and into
some library ?
The include files, such as 'graphics.e' would then load the appropiate
library and declare the routines, based upon the result of the platform ()
function.
Other than moving the code around, a mechanism should be available to
declare c-routines as built-in routines. Well, buitl-in, its not built-in,
but it isn't wrapped by an Euphoria routine, or called using some pointer
either. Pointers should still be available, and using the call_back ()
function, you could get a pointer to any type of routine, but we should also
be able to declare functions directly, inline.
Logically, this means, such declerations are only legal on the top-level.
There are many other benefits using such a mechanis as well:
1) The interpreters will become smaller
2) We can extend to the Euphoria language easily using fast machine code or
C.
3) We can use existing libraries
4) It will be easier to maintain for Robert.
Lastly, I do suggest that with each feature, it at least:
1) will be available on every platform *or* it really does not apply on that
platform
2) the number of routines minimized
3) the new global namespace solution (whatever it will be) should be taken
into account as well (if not be the top priority)
And about point one. Graphics do apply to windows and linux as well, for
example.
Robert, I understand you choice to not include a GUI library, however, I do
suggest you make sure, every feature a GUI would want to use (graphics,
mouse, text-output) is platform-independent. If the core tools are platform
independent, than a stable platform independent GUI is written with much
more ease and compatibility.
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
UIN: 9389920
[[ The elevator ]]
Http://www.xs4al.nl/~nieuwen
-- last updated 6th of August, 1999
