OpenEuphoria

An elegant solution?

• Posted by Michael Sabal <mjs at OSA.ATT.NE.JP> Feb 02, 1999
• 483 views

OK, some people want structures or records or whatever, but implementing =
them would break code.  Let's try this on for size, taking inspiration =
from routine_id.  Every sequence, whether top level or sublevel, has at =
least one attribute flag for the length of the sequence.  Let's add =
another flag called "locked".  This flag is boolean, so it won't really =
use any significant memory.  Whenever a sequence is created, locked =3D =
false.  So far, everything is backwards compatible.  Now, we add two new =
procedures and two functions to the internal library.  For example:

sequence point3D


This sets the locked attribute to true and initializes the three =
positions to garbage (or 0).  Now, in append, prepend, &, and left-value =
of point3D, the change fails, generating an error.  If you set an atom =
as "Hello", you get an error, so this would appear as the same.  So,

point3D =3D {24,44,49} -- this is OK
point3D =3D {24,44,49,40} -- checks if sequence - OK; check if locked - =
yes; check locked length - 3;
-- check if assignment is the right length - NO, so error.  If yes, then =
check if each element is the right
-- type.  If no, then type-check error.
point3D =3D {24,44} -- no good, same as above.
point3D[2] =3D 44 -- this is OK
point3D[3] =3D 44.5 -- generates a type-check failure after checking for =
locked status.
point3D =3D append(point3D,...)=20
point3D =3D prepend(point3D,...)
point3D =3D point3D & ...
-- All these generate errors for trying to change the length of a locked =
sequence.

To unlock the sequence and return it to normal operations,
unlock_sequence(point3D)

To check its locked status,
if is_locked(point3D) then
...
end if

And to check the validity of elements of a sequence of locked sequences, =
we would have to use
if equals_sequence(point3Dgrid[1],{"integer","integer","integer"}) then
... -- returns 1 if true, 0 if false
end if

Would this be an acceptable / elegant solution?  It would not define any =
new types, shouldn't break existing code, and would allow a Euphorized =
structure syntax.  Ideas?

Michael J. Sabal
mjs at osa.att.ne.jp
http://home.att.ne.jp/gold/mjs/index.html