Re: Homogeneous sequence

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu