Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agricu?t?re.gouv.fr> Aug 13, 2007
- 665 views
Pete Lomax wrote: > > Robert Craig wrote: > > > > This reminds me of a proposed extension to the type system > > that various people, including myself, have thought about before. > > It would be intuitively clear, and somewhat useful, to allow > > type declarations such as: > > }}} <eucode> > > sequence of integer x > > sequence of object x > > sequence of sequence x > > sequence of sequence of atom x > > sequence of my_user_defined_type x > > etc. > > </eucode> {{{ > > > When I last thought about this, I came to the conclusion that the above was > wrong. Specifically, > }}} <eucode> > sequence of sequence of atom z > </eucode> {{{ > has two problems: > 1) minimal semantic meaning Your comment has minimal semantic meaning. > 2) no way to perform the manual type check, unless you plan to allow: > }}} <eucode> > if sequence of sequence of atom(z) then > </eucode> {{{ > As far as my logic got, I figured the *ONLY* place an "of" should be valid > is in a user defined type definition: > }}} <eucode> > type set(sequence of atom s) > return 1 > end type > type set_table(sequence of set st) > return 1 > end type > </eucode> {{{ > Limiting the number of times that "of" can be used to *ONE* should help solve > both the problems mentioned above, and allow sensibly typed work vars when > playing > with individual elements of these things. > I must be having a nightmare. So you never had to deal with sequences of strings, which would translate to
sequence of sequence of printable
? assuming printable is a subtype of atom, presumably checking for range 32..255 unless some UTF-16/32 encodings are to be accounted for. As the very frequent case above shows, the number should be raised to two at the very, very minimum. And giving any explicit limit is a kludge barely squaring with the otherwise dynamic nature of structures in Eu - there is no limit to the depth of a sequence. The docs may warn against too high a level for obvious performance reasons, but that should be all. Otherwise, I'd say that limiting the use of "of" to UDT declarations makes sense. > While I somehow doubt this will gain much in the way of popular support, I > remain > convinced it is far superior while still achieving all the benefits you > outlined. > > Also, "sequence of object" should imo be an outright compilation error. > That is what "sequence" already is and I see no reason to either perform a > squillion > isObj() tests or permit the expression then optimise it away. Optimize away the expression first, then perform the tests. Why raising an error? > > > I spent a lot of time thinking about this a few years ago. > Did you leave any design notes lying around? > > > * Newbies might be confused, and put off by all this, > > thinking it was somehow necessary to provide full and proper > > types for everything. > Maybe not. It has been a while now, but on re-reading: > "To augment the predefined types, you can create user-defined types." > "For many programs, there is little advantage in defining new types" > "However, for larger programs, strict type definitions can aid debugging" > > I probably mentally skipped that section on first reading anyway, but was glad > to know it was there. > > It is usually a good idea to drum up the doc changes first of all, and I feel > sure you can find the words to reassure the newbie that they can keep it > simple. > > Regards, > Pete Do we have any database of sorts of what newbies like, don't like or barely grasp? I have read this sort of comment repeatedly, while failing to see any objective evidence backing the opinions stated on behalf of the newbies by non newbies. Which makes those opinions rather dubious. CChris