Euphoria 2.5 Features..... ??
Hello all, I'm back!
Allright, wanted to pass along a couple of ideas, and maybe run over a
idea like a rampid person, that tries to wear something out. And I do
seriously think these would be good Ideas for Euphoria 2.5
First off, The wearing out Idea/Problem. A String Type Variable.
Yeah Yeah, I realize we can do custom string type variables in Euphoria,
but there's still 1 major problem with it all. Even if it's a string
type variable, Euphoria still allocates 4 bytes of memory to store a
simple 0 to 255 (Or 0 to 255*2) character into memory. Now for little
baby strings, okay, that's kewl, no big loss. But when we get into big
files, like for example, Win32lib _BEFORE_ the breakup into seperate
libraries, and still somewhat now, we get a very big memory waste for
all of it. Now we all know, the interpreter doesn't allocate 4 bytes of
memory for each character, when reading the Plain Text euphoria code
into memory, for parsing, and execution. So my quesiton is, why should
we have to waste memory to read a file into memory, especially big
files, which could double, even triple in size, when loaded into a
simple Euphoria Sequence.
Now, yes, currently, Euphoria Slicing works beautifully on sequences,
but who says that said slicing can't be used on string variables as
well. It's not that much diffrent, only diffrence really, is that in
Sequences, there's embedding, but in strings, it is straight flat line,
nothing embedded within it. We would proabbly even get faster slicing
abilities on string type variables then we would on sequences, that just
had single byte characters in it. I'm not saying get rid of the
sequence, cause that's one of the things that makes Euphoria so
powerful, but to allocate 4 bytes of memory, to store a single character
seems to be just a plain waste of memory. But then again, that's just
my two cents.
Next, a actual new Idea:
Now, I noticed, when binding, it uses the Public Edition of Euphoria as
the base for it, which is all fine and dandy, cause you can remove the
source, and have the original Public Edition interpreter with no
problems. But, I see two major problems with this idea. One being the
file size. yes, considering what other interpreters have so far,
Euphoria is alot smaller, but there is allways room for improvement.
When Euphoria source code is bound to the interpreter, one specifically
isn't going to be removing the source code, to get the interpreter,
unless they know exactly how to do that, without destroying the
interpreter. Now, what I propose is, that you can proabbly loose about
100k or more on the Interpreter for binding, if you divide the
interpreter into two parts in the C code. Consider them if you would,
modules.
The two modules would be, 1 the reading of clear, un-objectized, plain
text euphoria code. This is really only needed for being a Interpreter,
not as a Bound Executable. The second module, would be the objectized,
shrouded code, which only Euphoria knows how to decipher for, weither it
be a external file, or bound to the file. Since the objectized code
would be more orientated to sort of a "Binary Script" file, which is
native only to Euphoria, it would grately enhance the load time, and
parsing time for bound Euphoria programs, in which strictly relies on
the source of the code, bound or not, to be purely objectized. Since
there is no need for the plain text module, this would proabbly reduce
the size of bound programs by another 100kb or more in size. This alone
would make Euphoria even more desirable, for the yet even smaller
executables then what other interpreters come out with.
These are only ideas, which I think would greatly enhance Euphoria, and
I hope some, if not all of you would agree with me on this. Sorry Rob,
Not trying to tell ya how to do your job, just giving my two cents in.
That's all for now.
L8ers,
EuMario
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mario Steele (EuMario)
Tuscan Chat Client
http://www.tuscanchat.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|
Not Categorized, Please Help
|
|
