1. Re: a (not so) elegant solution, but could do
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.
