OpenEuphoria

Re: REVOLUTION!

• Posted by Jeffrey Fielding <JJProg at CYBERBURY.NET> Jan 30, 1999
• 476 views

> 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/