Re: Type - Start Again
Peter Robinson wrote:
>
> Hi
>
> These seem to me to be variations that deserve consideration. The general
> domain
> is approaches to constraining data internal to sequences in the same way that
> Euphoria allows typing of data external to an object. I deliberately
> restricted
> the cases to syntax within a type block. The aliasing idea is separate -
> excluded
> here.
>
> Case 1: Fixed heterogeneous sequences - typical entity objects, like the
> customer
> object discussed. I've also omitted any implementation-specific syntax that
> was discussed.
>
> Salix assumed that my example like:-
>
> type customer( sequence x )
> integer x[1] id
> sequence x[2] name
> sequence x[3] address
> end type
>
> implied length(x) = 3. It's a reasonable asumption, but I actually didn't
> intend
> it one way or the other.
>
It looks like we'd need an extra keyword to mean "no other field may follow" or
"other fields may follow". My own preference would be for a terminal "stop"
keyword to mean that the sequence should only contain the fields listed above.
Perhaps "end all_fields" is better than "stop end fields". I have very weak
preferences there, but something should probably be added.
> Discussion between Pete and CChris, including aliasing, suggested that the
> x[num]
> part is superfluous, since the index is implied by ordering.
>
> Comment1: If you don't want to alias the subscripts, you're left with no
> identifier
> at all. Looks odd / unclear / ambiguous to me.
The idea I had was to make declaring fields as close as possible from declaring
a variable. Hence each field must have a name, since each variable must have a
name. Since aliases may collide between different structures, then, inside an
index specification:
* If the sequence is of a fielded type, and the unqualified alias is a known
field, use this binding, else error;
* If the field name is prefixed by a type name and a dot, then use the binding
if the alias is known for the type of the conaining sequence, or if it has a
unique offset, else error;
* If an unqualified field name is used in conjunction with a sequence not of a
fielded type, then use the common value if there's any, else error.
Since a field declaration is syntactically identical to a local variable
declaration, it needs some kind of block separation to differentiate. There may
be either fields or local variables, or both.
> Comment 2: If you leave out the index number, the number is implied, but may
> be hard for the eye to pick up if the sequence has several members.
Is it easier to read an index or to follow a list of "type name" lines? imho the
latter. Note that numeric indexes are allowed, though not recommended.
> Comment 3: Is "field" a good Euphorian word?
What is the loose evaluation function to be used to tag a keyword as more
euphorian than another? I thought being short and expressive helped. "fields"
looks good, why not "items" or "parts". What would you advocate?
>
> Case 2: Homogenous sequences
> Sequence of uniform type in n dimensions. Goal to avoid / simplify looping
> syntax.I
> suggested:-
>
> -- 1-dimensional sequence, all integers i.e. sequence of integer
> type list( sequence x )
> integer x[]
> end type
>
> -- This is a more Euphorian alternative, but doesn't generalise well to > 1
> dimension
> type list( sequence x )
> integer x[1..$]
> end type
>
> -- which suggests
> type semi_loose_entity( sequence x )
> integer x[1]
> sequence x[2..$]
> end type
>
> -- > 2-dimensions - highlighting visual hierarchy idea
> type matrix( sequence x )
> sequence x[] -- 1st dimension all sequences
> integer x[][] -- 2nd dimension all integers
> end type
>
> I think that gives the picture. It didn't look to me that all these variations
> were considered. Maybe some were rejected out of hand.
>
I'm afraid that anything that looks too clearly like C will be rejected out of
hand. I am not among the C haters, and have learned to appreciate C as I get more
frustrated with the verrbosity and rigidity of EUphoria in some areas. But there
are some on this list.
> Since I started all this, I'm happy to do any documentation of any outcome or
> assist otherwise if I can, but I can't devote time to studying the interpreter
> code in depth.
>
> Cheers
> Peter Robinson
CChris
|
Not Categorized, Please Help
|
|
