OpenEuphoria

Re: Ideas for next Eu

• Posted by Everett Williams <rett at GVTC.COM> Nov 10, 1999
• 803 views

On Tue, 9 Nov 1999 16:40:10 -0800, David Cuny <dcuny at LANSET.COM> wrote:

>Gabriel Boehme wrote:
>
>>  {line, column} = get_position()
>
>Yes!
>
>-- David Cuny

Isn't this just the latest thread of the namespace, structure discussion, just
an
elaborate dance around the need for structure naming? If "line" and "column"
are part of something that is 40 or 50 or a hundred items in size and I would
like to refer to them by name rather than by x[23] and x[77], maybe with x.line
and x.column, don't we need to be able to? Defining them individually and then
including them in a temporary sequence won't really work either, because they may
be an atom in sequence one, an integer in sequence two, and another sequence in
sequence three. And then, we really get into the variable
initialization problem with a vengeance. Though I am no expert in C, I think
that
is what stimulated the "void" definitions. Nothing in the world should keep the
current Euphoria definition from working, but I would like to add this to it.

null sequence xxxx{
                       atom x = 0,
                       atom line = 0,
                       sequence y = "Hello World",
integer {this, that,theother} = 1, -- to preserve current
                       syntax
-- and to
                                                                     easily define more
-- more
                                                                     than one at a time
                       atom column = 0,
                       atom z = 2}

Note the temporary sequence used as shorthand. By your rules, this would
result in a temporary seqence that looks like this.

       {x,line,y,this,that,theother,column,z} = procx(mumble)

to be used once and thrown away and to be recoded each time I need to store
the results of procx(). Ugh! Now I can do something of the order of this:

  -- use void definition from above
sequence yyyy instance xxxx -- which would create and initialize the seqence
sequence zzzz instance xxxx -- another sequence created and initialized
 yyyy = procx(virtual_screen1)
 zzzz = procx(virtual_screen2)

if yyyy.line != zzzz.line then
            .... we are not synchronized ...etc..etc.
       elseif yyyy.column = zzzz.column then
          .... we are synchronized...etc....etc.
       else
         ....... we are not synchronized....etc. etc.
end if

This is a stunningly bad example, because I have not coded much recently,
but I think the flavor is there to partake of. The obvious extension of this is
to
allow variables to be declared and defined in one step by borrowing the syntax
I have used above, or something similar.

When Euphoria really grows up and finds some way to deal with externally defined
data structures, then we will get some kind of bit, byte, and double
byte definitions to work with. By allowing named structures with these data
types, and enforcing their use, we can isolate Euphoria from the worst of their
effects. For example, Euphoria can force assignment of bits, bytes and double
bytes to atoms, integers, etc. before they can be used elsewhere in code in
the same way that variables are forced to be initialized before they are used.
Maybe something of the form of "null external sequence zzzz{....}" will do with
same basic syntax of above and the extra data types allowed only in
assignment statements that would do automatic conversion based on the
platform type. Only a single external data type variable would be allowed as
the source of an assignment with no other operations allowed. When
assigning to an external type variable, things would proceed normally.

In this process, we will get rid of a host of clumsy work arounds and allow
Euphoria to go out and play with the big boys on an even footing.

Everett L.(Rett) Williams
rett at gvtc.com