1. Frozen sequences
<FontFamily><param>Courier New</param>I just got this idea, and I want to here
some
opinions about it.
<FontFamily><param>Times New Roman</param>I understand that one problem with
sequences is that they support
dynamical memory allocation even when this is not required or
even wanted, since it slows down things.
What about creating a 'freeze' feature which turns ordinary
sequences into variable structures with a fixed size and
shape? Eight bytes could be reserved for all atoms in the
sequence, to avoid the need for reallocation of memory
if for instance an integer turns into floating point.
Note that only the structure of the sequnce is frozen, not
the values of its atoms, which can be changed as usual.
Any attempt to append, prepend or redifine the frozen
sequence in any way would result in an error and the program
would be terminated.
Of course, the sequence could also be unfrozen when
dynamic shrinking and growing is required again.
Would this speed things up, and if so; how much?
Best regards,
Tor Bernhard Gausen.
<nofill>
2. Re: Frozen sequences
- Posted by Daniel Berstein <daber at PAIR.COM>
Jan 28, 1999
-
Last edited Jan 29, 1999
<html>
At 02:06 a.m. 29-01-99 +0000, you wrote: <br>
<font face="Courier New, Courier"><blockquote type=cite cite>I just got
this idea, and I want to here some opinions about it. <br>
<br>
</font><font face="Times New Roman, Times">I understand that one problem
with sequences is that they support <br>
dynamical memory allocation even when this is not required or <br>
even wanted, since it slows down things. <br>
<br>
What about creating a 'freeze' feature which turns ordinary <br>
sequences into variable structures with a fixed size and <br>
shape? Eight bytes could be reserved for all atoms in the <br>
sequence, to avoid the need for reallocation of memory <br>
if for instance an integer turns into floating point. <br>
<br>
Note that only the structure of the sequnce is frozen, not <br>
the values of its atoms, which can be changed as usual. <br>
<br>
Any attempt to append, prepend or redifine the frozen <br>
sequence in any way would result in an error and the program <br>
would be terminated. <br>
<br>
Of course, the sequence could also be unfrozen when <br>
dynamic shrinking and growing is required again. <br>
<br>
Would this speed things up, and if so; how much? </blockquote><br>
<br>
That's the whole point.<br>
<br>
What Ralf and others (me included) would like to see is a way to
have<br>
a static (fixed bounds) data object. This "freezed" sequence is
usually<br>
called an array on most programming languages. The
"unfreeze"<br>
funcitonality ain't required (and superflous), because then you get<br>
a standard Euphoria sequence. Each element of this freezed sequence<br>
can be either an Atom or a Sequence (or a freezed sequence).<br>
<br>
The namespace is the way the interpreter manages indentifiers
(constants,<br>
variables, function, types, etc..) and how they get in/out of
scope.<br>
Currently Euphoria namespace is very limited: your identifiers are<br>
confined to the routine/include they are defined or are global to the
whole<br>
application. In large proyects this guarantees name conflict.<br>
<br>
</font>
<BR>
<div>Regards,</div>
Berstein</div>
</html>
3. Re: Frozen sequences
Bernhard Gausen wrote:
> I just got this idea, and I want to here some opinions about it.
>
> I understand that one problem with sequences is that they support
> dynamical memory allocation even when this is not required or
> even wanted, since it slows down things.
Actually, it would only speed it up, if the 'freeze' routine was on the
top-level.
Why? Because only then, the interpreter can replace all slices in the
sequece, with direct memory addresses.
This is why I wanted arrays. The speed, but also the ability to define such
a common type, easily.
How often do we work wiht multi-dimensional sequences, of a fixed length for
every direction.
Often. Graphics, Text, etc.
Im not into changing any of the documentation. Im in favor of an alternative
way to define the structure of a sequence.
Sequences are still sequences. A structure is nothing more than sequences,
and constants pointing to elements of the structure. However, the amount of
work to write a type-check function, for even the most simply structure is
not worth the trouble.
Same with arrays. We often use them. I just want a quick way to do things as
they can already be done. But it will take 100 lines to do so, if you want
to maintain the same level of type-checking.
For a structure you currently need to:
You have to go through a sequence, test it length. Test all elements.
You have to setup the sequence, and initialize all the elements.
You have to setup constants to point to certain elements of the sequence.
You have to worry about namespace, because of all those constants.
Example:
Two structures, one is addres, other is friend.
addres has two entries:
Street .. a one dimensional sequence
House .. an integer number
Tel .. a one dimensional sequence
Friend has two entries:
name .. a one dimenisonal sequence
Tel .. a one dimensional sequence
? my_addres[TEL]
? my_friend[TEL]
In the case of my_friend, tel has to mean: 2.
In the case of addres, tel has to mean: 3
However, this wouldnt even work, because when you declare TEL for the
second time, an error occurs.
This is one of the namespace problems.
The other is: there is only one global namespace.
For any modular program this is a hell.
Example:
I have a font library using graphics.e
I myself am using neil.e (Pete's graphics library)
Both graphics.e and Neil.e have a display_image routine.
Currently, you cant use both at the same time, because those name
conflict.
Which is weird, because for any human it would be clear which one to
use when:
In font.e
include graphics.e
display_image (..... )
In program.ex
include font.e
include neil.e
display_image (...)
Display_image is not a routine of font.e
It is of Neil.e
That font.e loaded graphics.e is irrelevant for program.ex
If program.ex wanted to use display_image from graphics.e it would have
included graphics.e itself.
However, when you shroud a program or library. The namespace *does* work
ok. (it only keeps the global identifers from the file you shroud global.
The rest is made local.
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
4. Re: Frozen sequences
> However, when you shroud a program or library. The namespace *does* work
>ok. (it only keeps the global identifers from the file you shroud global.
>The rest is made local.
Unfortunatly that isn't a language characterist.. it's only available to
registeres
users of RDS Euphoria :(
Regards,
Daniel Berstein
daber at pair.com
