Re: What's holding Euphoria back?
>Irv Mullins writes:
>> 1. Lack of structures
>
>This has been discussed at length. There might be some
>support eventually, but it has to be something elegant and powerful.
>I don't want to keep adding "missing" features until Euphoria
>becomes "C++ with sequences".
Robert, is your goal to create a good language or to create something that
is the opposite of C ?
C has got little to do with such a discussion except for an example, but I
would prefer if you stick to 'euphoric' examples, since they are the only
ones that actually apply. No offense, but these kind of arguments are not
convincing.
>> 2. Name space problems
>
>I consider name space issues to be very high priority for
>the next major release. I did not want to open this
>issue just before this release, as it impacts several different
>things in Euphoria, such as binding, tracing and routine_id(),
>in addition to normal symbol look-up. I want to do it right,
>not just a quick band-aid solution.
This on the other hand is a really strong argument. There were several
ideas, all with different impacts.
The three 'ideas' already suggested:
1) Allow some prefix. Like graphics.pixel ()
2) Have a different global name space for each include file, based upon
the files it actually includes.
3) Allow to define which globals want to use, and which name you want to
use for them. Something in the line of:
include graphics.e -- normal include. Point 2 assumed for this.
include misc.e do
routine platform as platform
constant PI as PI_VALUE
end include
-- All other identifers are not global.
-- You cant choose any identifer that is not global in the include
statement block.
This too is just a suggestion. You will reckognize where its from. Modula.
>> 3. Abysmal waste of disk space when writing data files.
>> ... We need to store single characters as one byte on
>> disk, not two, three or more
>
>When you write one or more characters to disk using
>puts(), they *are* stored as one byte each. If you think
>that print() to disk is wasteful, don't use it.
Yes, we can do it ourselves. We always can. For graphics, mouse routines,
structures, etc. etc.
We can always do it ourselves, so why are their huge libraries linked for
graphics, mouse support, file IO with cashing, etc. ?
They should either be really good and powerfull or not linked to the
interpreter at all. I mean, file IO could have been coded (at simerlar
speed) using 100% Euphoria routines.
Like that, graphics libraries have also shown us, we need not to 'link'
those huge watcom libraries.
And I believe, your initial choice was to include powerfull libraries. You
gave support for VESA modes, had IO support with cache, etc. All signs to
show you wanted powerfull support for these things. Lets keep up with the
present. There are now faster and much more powerfull graphics libraries,
powerfull mouse routines that also work in VESA modes, powerfull IO routines
of Jaques Deschenes, etc.
It would be a waste, if in the end 9 out 10 programs use their own graphical
libraries, their own mouse routines, their own file io routines, etc. Yet
still half of the interpreters size (although its even compressed) is prolly
due to watcom libraries that enable the native euphoria support for these
things.
My point is, what is your choice on these things nowadays ?
Minimum-just-the-bare or powerfull-all-the-way ? But, please, not something
in between. I can understand Irv's problems with these things. Does euphoria
want powerfull IO support, or just he bare ? Powerfull graphics support or
just the bare tools ? And: do they need to be linked to the interpreter, or
be machine code inside Euphoria libraries ?
Ralf
|
Not Categorized, Please Help
|
|
