1. REVOLUTION!
- Posted by Tor Bernhard Gausen <tor.gausen at C2I.NET>
Jan 30, 1999
-
Last edited Jan 31, 1999
Greetings!
I asked the list some questions about structures and arrays in one letter,=
and about my innovative, original, brand new idea: frozen structures
(which of course turned out to be a very old idea... 
in another letter=
.
The reason why I wrote two messages was that I though they handled
different issues. I see now that they did not.
First of all: you have all convinced me that there is an urgent need for a=
more consequent and reliable way to handle big variable structures in
Euphoria. There may also be some speed to gain by adding arrays.
Bernie Ryan wrote something that I could have written only a few hours
ago:
=93-- Isn't this is a structure ????=94 (followed by some example code of =
a
typical now-a-days Euphoria structure).
It IS in fact a structure, but that=92s not the point. Bernie: Please read=
the
messages which answered my questions. Scott Murray gave a very good
illustration of the name spacing problem and Quality and Daniel Berstein
explained the problems with type checking. Check out the differences
between the Pascal code and the =91Euphoria equivalent=92!
Daniel Berstein also touched the problem with type checking of arrays
containing many variables of the same type:
type t_person_list (sequence person_list)
if length(person_list) =3D 0 then
return 1
end if
for i =3D 1 to length(person_list)
if not t_person(person_list[i]) then
return 0
end if
end for
return 1
end type
The thing which worries me the most with this example is not that it=92s
unnecessarily complicated or exhausting to write, but rather that it must
slow down the program enormously for no good reason. Imagine that:
length(person_list) =3D 1000
and that a loop scans through the person list:
for a=3D1 to length(person_list)
person_list(a)=3Dsomething
end for
Would the type function then be called a 1000 times ? In that case, the
loop would in effect be a nested loop, of totally 1000.000 nodes. Now
imagine that person_list contains 1000.000 names...
If the entire sequence person_list could be assigned a type, then the
inner loop would of course be made redundant.
Irv Mullins hopes that the problems with what he calls =93Abysmal waste
of disk space=94 and =93the lack of true randomaccess for files=94 would b=
oth
be solved with the introduction of fixed size elements (arrays and
structures). If this is a fact, then it=92s almost good enough reason in i=
tself
to include these new features in Euphoria.
Scott Murray kindly corrected my bad spelling, (I=92m infinatly grateful!)=
)
and wrote:
=93Euphoria allows you to create your own types of any complexity, or use
allocate() and free() to manipulate memory directly, etc., etc. So why not=
structures as well? Just like the other complex stuff, the beginner doesn=
't
have to mess with 'em until they're needed, and then they'd be there.=94
I basically agree, but I=92m just a bit uncomfortable with the way you
argument. It=92s like you say: =93Euphoria is already a little bit complic=
ated,
why not make it more complicated?=94
Yes, in Euphoria you can create complex types, but then the complexity
is added by the user, it=92s not the language which is complex. I feel the=
re=92s
a difference.
Neither is the ability to manipulate memory directly, call machine code
etc. in my opinion a good example of =93how complex Euphoria is=94, since
this is an absolute requirement in any general purpose programming
language, and is as such a very special example.
Euphoria ISN=92T complex, because it doesn=92t provide you with more than
a tiny few statements. I like that. There is for example only one way (tha=
t
I know of) to create a never-ending loop: the <while> statement. In
BASIC there are dozens. There=92s only one way to perform a conditional
branch; the<if> statement. In BASIC there are several. There is only one
way to comfortably store and retrieve lots of data in memory: the
sequence variable. In BASIC... well, you=92ve got the point...
When there is only one way, then everyone have to do it that way, and
therefore everybody program more or less in the same manner. It=92s much
more difficult for a programmer to develop =91bad habits=92, because the o=
nly
way must also be the right way.
When I programmed QBasic, I never used procedures or functions! I
never got used to it, because I was never forced to use it. Instead I used=
GOSUB, GOTO and many other silly commands. I looked at some of my
programs recently and found an asteroids clone where I had used RUN
to loop the program... I did it because QBasic gave me the choice...
But I DON=92T want the possibility to choose !!!
I don=92t want to start programming e.g. a database, and then face the
question: should I use arrays, since they are so fast, or sequences, which=
are more flexible, or structures which are more reliable ? Perhaps I would=
choose the speedy arrays (=93coz the program is sooo simple, I=92m not
gonna need anything more complex=94). Then, after 1001 lines of code I
find that: Oh dear, I should have used structures instead, now I must
change everything...
Instead, I want to be FORCED (no, I=92m not into S/M) to use the only
option available: sequences. My wish would be: If I prefer it, the
sequnces will behave like arrays, with fixed size etc. But if I change a f=
ew
declaration statements in the beginning of the program they are now
suddenly structures. Ralf Nieuwenhuijsen says: =93I=92m not into changing=
any of the documentation. I=92m in favor of an alternative way to define t=
he
structure of a sequence=94.
Exactly ! THAT is what I want too.
Daniel Berstein wrote: =93This "frozen" sequence is usually called an arra=
y
on most programming languages.=94 O.K. So it is an array. You see, I was
afraid you people wanted some sort of a QBasic DIM feature (yak!) in
Euphoria. Now I see that an array can also have a complex sequence-like
structure, and I=92m much relieved...
I=92m still a uncertain about many things: How exactly should structures
and arrays be implemented in Euphoria? What kind of new statements
and built-in functions would be necessary to handle these new features?
I guess I must accept arrays and structures to be defined as new types,
but then I also want to be somehow able to exchange and copy data
directly between them. Example:
structure STRUCTURE
sequence SEQUENCE
array ARRAY
ARRAY=3D{{1,2},{3,4},{5,6}}
SEQUNCE=3DARRAY+1
STRUCTURE=3DSEQUENCE + 2
ARRAY +=3D STRUCTURE
ETC.
Bernie has a good line near the end of his message:
=93My opinion is that we should look for new ways to use the language
and not try to find ways to change the language.=94
I=92m a bit weak for this argument. We must not sink back into our chairs
and expect Rob Craig to provide us with all the functions and features we
need in our programs. But in the end of the day, Euphoria is in fact not
perfect, and no programming language will ever be. There will always be
things that=92ll need to be changed.
As the fresh convert, from the evil anti-structure way of thinking to the
righteous pro-structure way, I now turn around, stretch out my hand to
Bernie and say: =93Come, follow me over to the bright side of the force=94
REVOLTUTION!
Best regards,
Tor Bernhard Gausen
2. Re: REVOLUTION!
> First of all: you have all convinced me that there is an urgent need for a
> more consequent and reliable way to handle big variable structures in
> Euphoria. There may also be some speed to gain by adding arrays.
>
> Bernie Ryan wrote something that I could have written only a few hours
> ago:
> “-- Isn't this is a structure ????” (followed by some example code of a
> typical now-a-days Euphoria structure).
>
> It IS in fact a structure, but that’s not the point. Bernie: Please read the
> messages which answered my questions. Scott Murray gave a very good
> illustration of the name spacing problem and Quality and Daniel Berstein
> explained the problems with type checking. Check out the differences
> between the Pascal code and the ‘Euphoria equivalent’!
>
> Daniel Berstein also touched the problem with type checking of arrays
> containing many variables of the same type:
>
> type t_person_list (sequence person_list)
> if length(person_list) = 0 then
> return 1
> end if
> for i = 1 to length(person_list)
> if not t_person(person_list[i]) then
> return 0
> end if
> end for
> return 1
> end type
>
> The thing which worries me the most with this example is not that it’s
> unnecessarily complicated or exhausting to write, but rather that it must
> slow down the program enormously for no good reason. Imagine that:
>
> length(person_list) = 1000
>
> and that a loop scans through the person list:
>
> for a=1 to length(person_list)
> person_list(a)=something
> end for
>
> Would the type function then be called a 1000 times ? In that case, the
> loop would in effect be a nested loop, of totally 1000.000 nodes. Now
> imagine that person_list contains 1000.000 names...
I strongly agree with this point, and structures would be very nice. I think
that
it would be possible to just optomize the existing Euphoria language a bit. I
traced this:
type person(sequence s)
trace(1)
for i = 1 to length(s) do
trace(1)
if not integer(s[i]) then
return 0
end if
end for
return 1
end type
type peopleList(sequence s)
trace(1)
for i = 1 to length(s) do
trace(1)
if not person(s[i]) then
return 0
end if
end for
return 1
end type
peopleList people
people = repeat("",10)
for i = 1 to 10 do
people[i] = sprintf("%d",i)
end for
and saw that each time people was changed at all, it was ran through the teidous
type checking process. There are several ways that the speed could be
signifigantly improved by changing the way the Euphoria interperter handles
this.
First, the inperperter could see that people is a list by examining the type
code. It could then easily optomize the repeat statement, seeing that "" is a
person, and that that won't change. Next, each time an individual person in the
list is changed, it could only check that name, not the entire sequence.
This would, however, be quite complex to implement in the interperter. What if
there were simply a few more keywords, or uses of keywords to spesify that:
* peopleList is a list
* person and peopleList will always return the same value for the same input
* person and peopleList don't nessicarily need to be called (they don't modify
any variables etc.)
This could, in fact, also be used to cache the return values of functions and
types, which could drastically optomize some programs. It would also maintain
Euphoria's flexibility and simplicity, and in some cases increase it's speed.
--
Jeffrey Fielding
JJProg at cyberbury.net
http://members.tripod.com/~JJProg/
