OpenEuphoria

Re: a (not so) elegant solution, but could do

• Posted by jguy <jguy at ALPHALINK.COM.AU> Feb 03, 1999
• 460 views

Ralf Nieuwenhuijsen wrote:
>

[...]
> This ends up my mail. A short summery:
>
>     - structures
>         - are like sequence: however initialized from the beginning, and
> provided as types
>         - constants local to a type
>         - free to manipulate in any way you want
>     - arrays
>         - fixed number of dimensions and optionally a fixed length in each
> dimension.
>         - free to manipulate in any way you want

> Thats it. Now.. can any one find any reason not to add the above features ?
> Any reason that is relevant to *this* implementation of structures, rather
> than to *other* implementations used in other languages ?

In fact, local constants would be quite enough. With them you can build
your own structures, and objects. Thus for instance, instead of
wasting my fingertips typing:

    HDR =1,
        ,hdrTRACK=1 -- "TERANG"
        ,hdrDATE=2  -- {19998,09,04}
        ,hdrRACENO=3 -- 1
        ,hdrRACENAME=4 -- "Eat Well- Live Well Mdn Pltr"
        ,hdrDISTANCE=5 -- 1400
        ,hdrRACETYPE=6 -- "Maiden"
        ,hdrPURSE=7    -- "5500"
        ,hdrCANCLAIM=8 -- 1 -- (true)
        ,hdrLIMIT=9     -- also string, e.g. "SetWeight"
    ,FIELDSIZE =2      -- 12
    ,FLD=3 -- field, listed
        ,fldTABNO=1
        ,fldNAME=2
        ,fldJOCKEY=3
        ,fldPOST=4,
        ,fldHCP=5
        ,fldHCP2=6
        ,fldWON=7

I could make do with something much, much easier, like this:

records
    entrant =
    {TABNO, NAME, JOCKEY, POST, HANDICAP, ALLOWANCE, AMOUNTWON}

    race_form=
    {HEADER =
            {TRACK,
             DATE = {YEAR, MONTH, DAY},
             RACENO,....
            },
     FIELDSIZE, -- number of entrants
     FIELD -- {entrant, entrant, ...}
     -- etc, etc.
     }

end records

No initialization there, and no type-checking, apart from the length
of each sequence, which is made fixed by using symbolic indexing.
They could be provided like this for instance:

entrant =
    {integer TABNO =-1,
     string NAME ="", JOCKEY="",
     integer POST=-1, HANDICAP=-1, ALLOWANCE=-1, AMOUNTWON=-1}

Not that I do not find it very useful in the above example, but
initialization would be useful for implementing objects:

records
   point = { sequence COORDINATES,
             integer DRAW = routine_id("draw_point")
           }
end  records

It still remains a kludge, since you have to
pass the point as an argument:

    call_proc( mypoint[DRAW],{mypoint} )

But that is much better than having to initialize
the "draw" method of every point manually as you
would without record initialization.

The point (!) remains that

1. If such local constants are to be implemented,
   they must be for everything: functions,
   procedures.
2. If initialization is to be implemented, it
   ought to be provided for all variables, not
   only those in records.
3. To allow for type-checking one needs at
   least one new reserved word to distinguish
   routine id's from plainn integers.

See how I left "COORDINATES" above undefined,
apart from being a sequence? That was on
purpose. Even with records (structures) implemented,
there is no need to go all the way, making
everything of fixed length. Some points may
live in two dimensions, some in four, and,
why not, why should a coordinate not be
allowed to be a sequence? Thus this point,
which exists simultaneously in two places
in a 2D space: {{2,612}, 122}

At any rate, to use a more pedestrian example,
if I want to define a dictionary structure, the
number of  its entries cannot be fixed in advance.
Likewise in that racing database: the number of
entrants in a race is not fixed; the number of
past races recorded for each horse and jockey
is not fixed.
So one still often needs proper Euphoria sequences,
even in structures (records,  objects, classes...).
And initialization and type-checking should NOT
be compulsory

As for arrays... I can't see any need at all. This is one:

function NOOP()
   return {1}
end function

sequence command
integer noop
sequence status

noop=routine_id("NOOP")
command=repeat(400,repeat(400,noop))

That is a perfectly good array, 400x400. I cannot
see anything worth gaining in allowing for something
like:

array command[400][400]

or whatever.